Frontend, Backend, and Shared APIs
This page lists APIs that commonly indicate where plugin code should live in a split architecture:
The lists are intentionally conservative. Treat them as placement defaults rather than an exhaustive type system. If a feature needs a different placement, review the specific API behavior and validate the result in Split Mode.
Inspection highlights inappropriate API usage.
See also Modular Plugins and Split Mode Feature Development Guideline.
Frontend APIs
The following APIs usually belong in the frontend module:
com.intellij.openapi.editor.toolbar.floating.FloatingToolbarProvidercom.intellij.codeInsight.editorActions.enter.EnterHandlerDelegatecom.intellij.codeInsight.editorActions.enter.EnterHandlerDelegateAdaptercom.intellij.openapi.fileEditor.FileEditorManager.getFocusedEditor()com.intellij.codeInsight.editorActions.CopyPastePostProcessorcom.intellij.openapi.editor.actionSystem.EditorActionHandlercom.intellij.openapi.actionSystem.PlatformDataKeys.TOOL_WINDOWcom.intellij.openapi.actionSystem.PlatformCoreDataKeys.SELECTED_ITEMcom.intellij.openapi.actionSystem.PlatformCoreDataKeys.SELECTED_ITEMScom.intellij.openapi.actionSystem.PlatformCoreDataKeys.CONTEXT_COMPONENT
Backend APIs
The following APIs usually belong in the backend module:
com.intellij.codeInsight.hints.declarative.InlayHintsProvidercom.jetbrains.jsonSchema.extension.JsonSchemaProviderFactorycom.intellij.platform.backend.workspace.WorkspaceModelChangeListenercom.intellij.openapi.actionSystem.PlatformCoreDataKeys.MODULEcom.intellij.openapi.actionSystem.LangDataKeys.MODULE_CONTEXTcom.intellij.openapi.actionSystem.LangDataKeys.MODIFIABLE_MODULE_MODEL
Shared APIs
The following APIs can be used in both frontend and backend modules.
This list currently includes two categories of APIs:
language support–related extensions
project/application lifecycle listeners
Language support should be implemented in the shared module so that PSI can be used on both sides. The frontend benefits from language support extensions because they enable a fast local editing experience and make it possible to build features on top of them. For example, a typing handler naturally belongs in the frontend, and it requires PSI for the file type it supports. The backend also benefits from language support because backend-specific extensions depend on it as well. For example, an inspection that naturally belongs in the backend requires PSI to traverse the file.
The other category consists of application and project lifecycle listeners. Since their implementations may produce arbitrary side effects, it is up to the plugin developer to decide whether those effects should run in the backend or the frontend. For example, if a plugin needs to install and run an external tool after a project is loaded, it should be registered in the backend. If it needs to display a survey UI with a feedback form after a user changes a registry key, it should run in the frontend.
Shared code should stay lightweight. If shared logic starts depending on frontend-only or backend-only APIs, it usually belongs in a dedicated content module instead.