github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-23 17:28:26 -04:00
Code Issues Projects Releases Packages Wiki Activity

Update kibana plugin, platform and package overview doc (#112894)

Browse source 
* udpate

* Update kibana_platform_plugin_intro.mdx

* Update kibana_platform_plugin_intro.mdx

* Update kibana_platform_plugin_intro.mdx

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
This commit is contained in:
Stacey Gammon 2021-10-05 10:02:46 -04:00 • committed by GitHub
parent 9902cbdc07
commit cc00f3f279
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 33 additions and 34 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
dev_docs/assets/1000_ft_arch.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 78 KiB

67
dev_docs/key_concepts/kibana_platform_plugin_intro.mdx
View file

@ -1,7 +1,7 @@
---
id: kibPlatformIntro
slug: /kibana-dev-docs/key-concepts/platform-intro
title: Plugins and the Kibana platform
title: Plugins, packages, and the platform
summary: An introduction to the Kibana platform and how to use it to build a plugin.
date: 2021-01-06
tags: ['kibana', 'onboarding', 'dev', 'architecture']
@ -19,28 +19,45 @@ developer tools. The Kibana platform is a blank canvas, just waiting for a devel
![Kibana personas](assets/kibana_platform_plugin_end_user.png)
## Platform services
## 1,000 foot view
Plugins have access to three kinds of public services:
At a super high-level, Kibana is composed of **plugins**, **core**, and **Kibana packages**.
- Platform services provided by `core` (<DocLink id="kibPlatformIntro" section="core-services" text="Core services"/>)
- Platform services provided by plugins (<DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>)
- Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils").
![Kibana 1000 ft arch](assets/1000_ft_arch.png)
The first two items are what make up "Platform services".
**Plugins** provide the majority of all functionality in Kibana. All applications and UIs are defined here.
<DocCallOut title="What is the difference between services provided by platform plugins, and those by core?">
**Core** provides the runtime and the most fundamental services.
We try to put only the most stable and fundamental code into `Core`, while more application focused functionality goes in a plugin, but the heuristic isn't
clear, and we haven't done a great job of sticking to it. For example, notifications and toasts are core services, but data and search are plugin services.
**@kbn packages** provide static utilities that can be imported anywhere in Kibana.
<DocAccordion buttonContent="(Internal only) FAQ: Should I put my code in a plugin or a package?" color="warning">
<DocCallOut color="warning">
If it's stateful, it has to go in a plugin, but packages are often a good choices for stateless utilities. Stateless code exported publicly from a plugin will increase the page load bundle size of _every single page_, even if none of those plugin's services are actually needed. With packages, however, only code that is needed for the current page is downloaded.
The downside however is that the packages folder is far away from the plugins folder so having a part of your code in a plugin and the rest in a package may make it hard to find, leading to duplication.
The Operations team hopes to resolve this conundrum by supporting co-located packages and plugins and automatically putting all stateless code inside a package. You can track this work by following [this issue](https://github.com/elastic/kibana/issues/112886).
Until then, consider whether it makes sense to logically separate the code, and consider the size of the exports, when determining whether you should put stateless public exports in a package or a plugin.
</DocCallOut>
</DocAccordion>
<DocAccordion buttonContent="FAQ: What is the difference between services provided by plugins and those by Core?" color="warning">
<DocCallOut >
We try to put only the most stable and fundamental code into `Core`, while optional add-ons, applications, and solution-oriented functionality goes in a plugin. Unfortunately, we haven't done a great job of sticking to that. For example, notifications and toasts are core services, but data and search are plugin services.
Today it looks something like this.
![Core vs platform plugins vs plugins](assets/platform_plugins_core.png)
<DocAccordion buttonContent="A bit of history">
When the Kibana platform and plugin infrastructure was built, we thought of two types of code: core services, and other plugin services. We planned to keep the most stable and fundamental
code needed to build plugins inside core.
"Platform plugins" provide core-like functionality, just outside of core, and their public APIs tend to be more volatile. Other plugins may still expose shared services, but they are intended only for usage by a small subset of specific plugins, and may not be generic or "platform-like".
**A bit of history**
When the Kibana platform and plugin infrastructure was built, we thought of two types of code: core services, and other plugin services. We planned to keep the most stable and fundamental code needed to build plugins inside core.
In reality, we ended up with many platform-like services living outside of core, with no (short term) intention of moving them. We highly encourage plugin developers to use
them, so we consider them part of platform services.
@ -49,36 +66,18 @@ When we built our platform system, we also thought we'd end up with only a handf
footprint and speed up Kibana.
In reality, our plugin model ended up being used like micro-services. Plugins are the only form of encapsulation we provide developers, and they liked it! However, we ended
up with a ton of small plugins, that developers never intended to be uninstallable, nor tested in this manner. We are considering ways to provide developers the ability to build services
with the encapsulation
they desire, without the need to build a plugin.
up with a ton of small plugins, that developers never intended to be uninstallable, nor tested in this manner. We are considering ways to provide developers the ability to build services with the encapsulation they desire, without the need to build a plugin.
Another side effect of having many small plugins is that common code often ends up extracted into another plugin. Use case specific utilities are exported,
that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of
every publically exposed service", but in today's world, that wouldn't be a very accurate picture.
every publicly exposed service", but in today's world, that wouldn't be a very accurate picture.
We recognize the need to better clarify the relationship between core functionality, platform-like plugin functionality, and functionality exposed by other plugins.
It's something we will be working on!
</DocAccordion>
We will continue to focus on adding clarity around these types of services and what developers can expect from each.
</DocCallOut>
### Core services
Sometimes referred to just as <DocLink id="kibServerAndCoreComponents" text="Core, Core services"/> provide the most basic and fundamental tools neccessary for building a plugin, like creating saved objects,
routing, application registration, notifications and <DocLink id="kibCoreLogging" text="logging"/>. The Core platform is not a plugin itself, although
there are some plugins that provide platform functionality. We call these <DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>.
### Platform plugins
Plugins that provide fundamental services and functionality to extend and customize Kibana, for example, the
<DocLink id="kibDataPlugin" text="data" /> plugin. There is no official way to tell if a plugin is a
platform plugin or not. Platform plugins are _usually_ plugins that are managed by the Platform Group,
but we are starting to see some exceptions.
</DocCallOut></DocAccordion>
## Plugins