* add architecture styleguide * be clearer about application architecture * define as plugin architecture and downplay the webpack alias and shims that are available * fix typo, simplify server description
2.1 KiB
2.1 KiB
Architecture Style Guide
Plugin Architecture
These are a collection of architectural styles to follow when building Kibana plugins. This includes applications meant to be accessed from the Kibana sidebar, as applications are simply one type of plugin.
File and Folder Structure
Kibana plugins, both in core and those developed independent of Kibana, should follow this basic file and folder structure:
plugin_root:
.
├── common/
├── public/
├── server/
└── index.js
- index.js
- The entry point to your application, this file is loaded when your code is being used in Kibana. This module should simply export a function that takes the
kibana
server object and initializes your application. This is where you define things like the id, any uiExports, dependencies on other plugins and applications, any configuration, any initialization code, and the location of the public folder. - public
- This folder is where you place client-side code for your application. Anything that is run in the browser belongs in here.
- NOTE: An alias for this folder is created at
plugins/{id}
, whereid
is what you defined in the plugin entry point. If your application'sid
isutile
, and you were trying to import a module frompublic/lib/formatter.js
, you could import the module asplugins/utile/lib/formatter
. - server
- This folder is where server code belongs. Things like custom routes, data models, or any other code that should only be executed on the server should go here.
- common
- This folder is where code that is useful on both the client and the server belongs. A consistent example of this is constants, but this could apply to helper modules as well.
- NOTE: If you'd like to avoid adding
../common
to your public code, you could use webpackShims to resolve the path without traversing backwards.