maxmustermann/kibana
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
kibana/src/core
History
Mikhail Shustov 88359b742a
Improve ui settings performance (#84513) 
* remove unused parameter in "read" function

* add cache for uiSettings client

* add tests for ui_settings client caching

* address comments

* do not mutate ui_settings_client cache
2020-12-02 20:15:25 +01:00
..
public Changes UI links for drilldowns (#83971) 2020-12-01 12:39:42 -06:00
server Improve ui settings performance (#84513) 2020-12-02 20:15:25 +01:00
test_helpers [dev/cli] detect worker type using env, not cluster module (#83977) 2020-11-25 08:03:47 -07:00
types [Advanced Settings] Introducing telemetry (#82860) 2020-11-12 14:38:07 +00:00
utils Change left nav category name to Analytics (#83132) 2020-11-11 09:55:15 -06:00
CONVENTIONS.md Update documentation/examples of deprecated namespaceAgnostic field (#68039) 2020-06-03 12:40:11 -07:00
CORE_CONVENTIONS.md [skip-ci] Core conventions (#52397) 2020-01-15 14:29:50 +01:00
index.ts
PRINCIPLES.md [NP] add platform main principles (#53866) 2020-01-24 07:54:06 +01:00
README.md [docs] Convert migration guide to asciidoc (#82600) 2020-11-24 09:46:19 +01:00
TESTING.md Introduce TS incremental builds & move src/test_utils to TS project (#76082) 2020-09-03 14:20:04 +02:00
tsconfig.json Cleanup tsconfig files (#84396) 2020-11-30 19:12:00 +01:00

README.md

Core

Core is a set of systems (frontend, backend etc.) that Kibana and its plugins are built on top of.

Plugin development

Core Plugin API Documentation:

Internal Documentation:

Integration with the "legacy" Kibana

Most of the existing core functionality is still spread over "legacy" Kibana and it will take some time to upgrade it. Kibana is started using existing "legacy" CLI that bootstraps core which in turn creates the "legacy" Kibana server. At the moment core manages HTTP connections, handles TLS configuration and base path proxy. All requests to Kibana server will hit HTTP server exposed by the core first and it will decide whether request can be solely handled by the new platform or request should be proxied to the "legacy" Kibana. This setup allows core to gradually introduce any "pre-route" processing logic, expose new routes or replace old ones handled by the "legacy" Kibana currently.

Once config has been loaded and some of its parts were validated by the core it's passed to the "legacy" Kibana where it will be additionally validated so that we can make config validation stricter with the new config validation system. Even though the new validation system provided by the core is also based on Joi internally it is complemented with custom rules tailored to our needs (e.g. byteSize, duration etc.). That means that config values that were previously accepted by the "legacy" Kibana may be rejected by the core now.

Even though core has its own logging system it doesn't output log records directly (e.g. to file or terminal), but instead forward them to the "legacy" Kibana so that they look the same as the rest of the log records throughout Kibana.

Core API Review

To provide a stable API for plugin developers, it is important that the Core Public and Server API's are stable and well documented. To reduce the chance of regressions, development on the Core API's includes an API signature review process described below. Changes to the API signature which have not been accepted will cause the build to fail.

When changes to the Core API's signatures are made, the following process needs to be followed:

  1. After changes have been made, run yarn docs:acceptApiChanges which performs the following:
    • Recompiles all typescript typings files
    • Updates the API review files src/core/public/kibana.api.md and src/core/server/kibana.api.md
    • Updates the Core API documentation in docs/development/core/
  2. Review and commit the updated API Review files and documentation
  3. Clearly flag any breaking changes in your pull request