• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..03-May-2022-

public/H03-May-2022-109

server/H03-May-2022-235184

test_helpers/H03-May-2022-

types/H03-May-2022-

utils/H03-May-2022-

README.mdH A D21-May-20211.6 KiB2216

README.md

1# Core
2
3Core is a set of systems (frontend, backend etc.) that Kibana and its plugins are built on top of.
4
5## Integration with the "legacy" Kibana
6
7Most of the existing core functionality is still spread over "legacy" Kibana and it will take some time to upgrade it.
8Kibana is started using existing "legacy" CLI that bootstraps `core` which in turn creates the "legacy" Kibana server.
9At the moment `core` manages HTTP connections, handles TLS configuration and base path proxy. All requests to Kibana server
10will hit HTTP server exposed by the `core` first and it will decide whether request can be solely handled by the new
11platform or request should be proxied to the "legacy" Kibana. This setup allows `core` to gradually introduce any "pre-route"
12processing logic, expose new routes or replace old ones handled by the "legacy" Kibana currently.
13
14Once config has been loaded and some of its parts were validated by the `core` it's passed to the "legacy" Kibana where
15it will be additionally validated so that we can make config validation stricter with the new config validation system.
16Even though the new validation system provided by the `core` is also based on Joi internally it is complemented with custom
17rules tailored to our needs (e.g. `byteSize`, `duration` etc.). That means that config values that were previously accepted
18by the "legacy" Kibana may be rejected by the `core` now.
19
20Even though `core` has its own logging system it doesn't output log records directly (e.g. to file or terminal), but instead
21forward them to the "legacy" Kibana so that they look the same as the rest of the log records throughout Kibana.
22