* Update the slugs to improve google analytics drilldown tracking * more slug updates * Fix some formatting issues in building blocks * update paths Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> # Conflicts: # dev_docs/key_concepts/persistable_state.mdx # legacy_rfcs/README.md
143 lines
8.1 KiB
Plaintext
143 lines
8.1 KiB
Plaintext
---
|
|
id: kibBuildingBlocks
|
|
slug: /kibana-dev-docs/key-concepts/building-blocks
|
|
title: Building blocks
|
|
summary: Consider these building blocks when developing your plugin.
|
|
date: 2021-02-24
|
|
tags: ['kibana', 'onboarding', 'dev', 'architecture']
|
|
---
|
|
|
|
When building a plugin in Kibana, there are a handful of architectural "building blocks" you can use. Some of these building blocks are "higher-level",
|
|
and some are "lower-level". High-level building blocks come
|
|
with many built-in capabilities, require less maintenance, and evolve new feature sets over time with little to no
|
|
impact on consumers. When developers use high-level building blocks, new features are exposed consistently, across all of Kibana, at the same time.
|
|
On the downside, they are not as flexible as our low-level building blocks.
|
|
|
|
Low-level building blocks
|
|
provide greater flexibility, but require more code to stitch them together into a meaningful UX. This results in higher maintenance cost for consumers and greater UI/UX variability
|
|
across Kibana.
|
|
|
|
For example, if an application is using <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/> and <DocLink id="kibBuildingBlocks" section="search-source" text="Search Source" />, their application would
|
|
automatically support runtime fields. If the app is instead using the lower-level <DocLink
|
|
id="kibBuildingBlocks"
|
|
section="search-strategy"
|
|
text="Search Strategy"
|
|
/>, additional work would be required.
|
|
|
|
Armed with this knowledge, you can choose what works best for your use case!
|
|
|
|
# Application building blocks
|
|
|
|
## UI components
|
|
|
|
The following high-level building blocks can be rendered directly into your application UI.
|
|
|
|
### Query Bar
|
|
|
|
The <DocLink id="kibDataPlugin" text="Data plugin"/> provides a high-level Query Bar component that comes with support for Lucene, KQL, Saved Queries,
|
|
and <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/>. If you would like to expose the ability to search and filter on Elasticsearch data, the Query Bar provided by the <DocLink id="kibDataPlugin" text="Data plugin" /> is your go-to building block.
|
|
|
|
**Github labels**: `Team:AppServices`, `Feature:QueryBar`
|
|
|
|
### Dashboard Embeddable
|
|
|
|
Add a Dashboard Embeddable directly inside your application to provide users with a set of visualizations and graphs that work seamlessly
|
|
with the <DocLink id="kibBuildingBlocks" section="query-bar" text="Query Bar"/>. Every feature that is added to a registered <DocLink id="kibBuildingBlocks" section="embeddables" text="Embeddable" /> (Lens, Maps, Saved Searches and more) will be available automatically, as well as any <DocLink id="kibBuildingBlocks" section="ui-actions--triggers" text="UI Actions" /> that are added to the Embeddable context menu panel (for example, drilldowns, custom panel time ranges, and "share to" features).
|
|
|
|
The Dashboard Embeddable is one of the highest-level UI components you can add to your application.
|
|
|
|
**Github labels**: `Team:Presentation`, `Feature:Dashboard`
|
|
|
|
### Lens Embeddable
|
|
|
|
Check out the Lens Embeddable if you wish to show users visualizations based on Elasticsearch data without worrying about query building and chart rendering. It's built on top of the <DocLink id="kibBuildingBlocks" section="expressions" text="Expression language" />, and integrates with <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns" /> and <DocLink id="kibBuildingBlocks" section="ui-actions--triggers" text="UI Actions" />. Using the same configuration, it's also possible to link to a prefilled Lens editor, allowing the user to drill deeper and explore their data.
|
|
|
|
**Github labels**: `Team:VisEditors`, `Feature:Lens`
|
|
|
|
### Map Embeddable
|
|
|
|
Check out the Map Embeddable if you wish to embed a map in your application.
|
|
|
|
**Github labels**: `Team:Geo`
|
|
|
|
### KibanaPageTemplate
|
|
|
|
All Kibana pages should use KibanaPageTemplate to setup their pages. It's a thin wrapper around [EuiPageTemplate](https://elastic.github.io/eui/#/layout/page) that makes setting up common types of Kibana pages quicker and easier while also adhering to any Kibana-specific requirements.
|
|
|
|
Check out <DocLink id="kibDevDocsKPTTutorial" text="the KibanaPageTemplate tutorial" /> for more implementation guidance.
|
|
|
|
**Github labels**: `EUI`
|
|
|
|
## Searching
|
|
|
|
### Index Patterns
|
|
|
|
<DocLink id="kibDataPlugin" section="index-patterns-api" text="Index Patterns" /> are a high-level, space-aware
|
|
abstraction layer that sits above Data Streams and Elasticsearch indices. Index Patterns provide users
|
|
the ability to define and customize the data they wish to search and filter on, on a per-space basis.
|
|
For example, users can specify a set of indices, and they can customize the field list with runtime fields,
|
|
formatting options and custom labels.
|
|
|
|
Index Patterns are used in many other high-level building blocks so we highly recommend you consider this building block for your search needs.
|
|
|
|
**Github labels**: `Team:AppServices`, `Feature:Index Patterns`
|
|
|
|
### Search Source
|
|
|
|
<DocLink id="kibDataPlugin" section="searchsource" text="Search Source" /> is a high-level search service
|
|
offered by the <DocLink id="kibDataPlugin" section="searchsource" text="Data plugin" />. It requires
|
|
an <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Pattern" />, and abstracts away
|
|
the raw ES DSL and search endpoint. Internally it uses the ES <DocLink
|
|
id="kibBuildingBlocks"
|
|
section="search-strategies"
|
|
text="Search Strategy"
|
|
/>
|
|
. Use Search Source if you need to query data from Elasticsearch, and you aren't already using one of
|
|
the high-level UI Components that handles this internally.
|
|
|
|
**Github labels**: `Team:AppServices`, `Feature:Search`
|
|
|
|
### Search Strategies
|
|
|
|
Search Strategies are a low-level building block that abstracts away search details, like what REST endpoint is being called. The ES Search Strategy
|
|
is a very lightweight abstraction layer that sits just above querying ES with the elasticsearch-js client. Other search stragies are offered for other
|
|
languages, like EQL and SQL. These are very low-level building blocks so expect a lot of glue work to make these work with the higher-level abstractions.
|
|
|
|
**Github labels**: `Team:AppServices`, `Feature:Search`
|
|
|
|
### Expressions
|
|
|
|
Expressions are a low-level building block that can be used if you have advanced search needs that requiring piping results into additional functionality, like
|
|
joining and manipulating data. Lens and Canvas are built on top of Expressions. Most developers should be able to use <DocLink id="kibBuildingBlocks" section="lens-embeddable" text="Lens" /> or <DocLink id="kibBuildingBlocks" section="search-source" text="Search Source" />, rather than need to
|
|
access the Expression language directly.{' '}
|
|
|
|
**Github labels**: `Team:AppServices`, `Feature:ExpressionLanguage`
|
|
|
|
## Saved Objects
|
|
|
|
<DocLink id="kibDevDocsSavedObjectsIntro" text="Saved Objects" /> should be used if you need to persist
|
|
application-level information. If you were building a TODO application, each TODO item would be a `Saved
|
|
Object`. Saved objects come pre-wired with support for bulk export/import, security features like space
|
|
sharing and space isolation, and tags.
|
|
|
|
**Github labels**: `Team:Core`, `Feature:Saved Objects`
|
|
|
|
# Integration building blocks
|
|
|
|
Use the following building blocks to create an inter-connected, cross-application, holistic Kibana experience. These building blocks allow you to expose functionality
|
|
that promotes your own application into other applications, as well as help developers of other applications integrate into your app.
|
|
|
|
## UI Actions & Triggers
|
|
|
|
Integrate custom actions into other applications by registering UI Actions attached to existing triggers. For example, the Maps
|
|
application could register a UI Action called "View in Maps" to appear any time the user clicked a geo field to filter on.
|
|
|
|
**Github labels**: `Team:AppServices`, `Feature:UIActions`
|
|
|
|
## Embeddables
|
|
|
|
Embeddables help you integrate your application with the Dashboard application. Register your custom UI Widget as an Embeddable and users will
|
|
be able to add it as a panel on a Dashboard. With a little extra work, it can also be exposed in Canvas workpads.
|
|
|
|
**Github labels**: `Team:AppServices`, `Feature:Embeddables`
|