[core-new-docs] Adds a dev-doc for core documentation (#92976)

dev_docs/kibana_platform_plugin_intro.mdx

@@ -68,7 +68,7 @@ We will continue to focus on adding clarity around these types of services and w
 
 ### Core services
 
-Sometimes referred to just as Core, Core services provide the most basic and fundamental tools neccessary for building a plugin, like creating saved objects,
+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"/>.
 
@@ -141,4 +141,4 @@ plugins to customize the Kibana experience. Examples of extension points are:
 
 ## Follow up material
 
-Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />
+Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />.

dev_docs/kibana_server_core_components.mdx

@@ -0,0 +1,30 @@
+---
+id: kibServerAndCoreComponents
+slug: /kibana-dev-docs/core-intro
+title: Core components
+summary: An introduction to the Kibana server and core components.
+date: 2021-02-26
+tags: ['kibana','onboarding', 'dev', 'architecture']
+---
+
+Core is a set of systems (frontend, backend etc.) that Kibana and its plugins are built on top of.
+
+## 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.
+
+### Logging
+`core` has its own <DocLink id="kibCoreLogging" text="logging system"/> and will output log records directly (e.g. to file or terminal) when configured. When no specific configuration is provided, logs are forwarded to the "legacy" Kibana so that they look the same as the rest of the
+log records throughout Kibana.
+

src/core/CONVENTIONS.md

@@ -202,14 +202,14 @@ export class MyPlugin implements Plugin {
 }
 ```
 
-Prefer the pattern shown above, using `core.getStartServices()`, rather than store local references retrieved from `start`. 
+Prefer the pattern shown above, using `core.getStartServices()`, rather than store local references retrieved from `start`.
 
 **Bad:**
 ```ts
 export class MyPlugin implements Plugin {
  // Anti pattern
   private coreStart?: CoreStart;
-  private depsStart?: DepsStart;  
+  private depsStart?: DepsStart;
 
   public setup(core) {
     core.application.register({
@@ -220,7 +220,7 @@ export class MyPlugin implements Plugin {
         return renderApp(this.coreStart, this.depsStart, params);
       }
     });
-  }  
+  }
 
   public start(core, deps) {
     // Anti pattern
@@ -361,5 +361,5 @@ Migration example from the legacy format is available in `src/core/MIGRATION_EXA
 
 ### Naming conventions
 
-Export start and setup contracts as `MyPluginStart` and `MyPluginSetup`. 
+Export start and setup contracts as `MyPluginStart` and `MyPluginSetup`.
 This avoids naming clashes, if everyone exported them simply as `Start` and `Setup`.

src/core/CORE_CONVENTIONS.md

@@ -15,7 +15,7 @@ area of Core API's and does not apply to internal types.
 
  - 1.1 All API types must be exported from the top-level `server` or `public`
    directories.
-   
+
    ```ts
    // -- good --
    import { IRouter } from 'src/core/server';
@@ -23,15 +23,15 @@ area of Core API's and does not apply to internal types.
    // -- bad --
    import { IRouter } from 'src/core/server/http/router.ts';
    ```
-   
+
    > Why? This is required for generating documentation from our inline
    > typescript doc comments, makes it easier for API consumers to find the
    > relevant types and creates a clear distinction between external and
    > internal types.
- 
+
  - 1.2 Classes must not be exposed directly. Instead, use a separate type,
    prefixed with an 'I', to describe the public contract of the class.
-   
+
    ```ts
    // -- good (alternative 1) --
    /**
@@ -66,14 +66,14 @@ area of Core API's and does not apply to internal types.
    ```
 
    > Why? Classes' private members form part of their type signature making it
-   > impossible to mock a dependency typed as a `class`. 
+   > impossible to mock a dependency typed as a `class`.
    >
    > Until we can use ES private field support in Typescript 3.8
    > https://github.com/elastic/kibana/issues/54906 we have two alternatives
    > each with their own pro's and cons:
    >
    > #### Using a derived class (alternative 1)
-   > 
+   >
    > Pro's:
    > - TSDoc comments are located with the source code
    > - The class acts as a single source of type information
@@ -81,12 +81,12 @@ area of Core API's and does not apply to internal types.
    > Con's:
    > - "Go to definition" first takes you to where the type gets derived
    >   requiring a second "Go to definition" to navigate to the type source.
-   >  
+   >
    > #### Using a separate interface (alternative 2)
    > Pro's:
    > - Creates an explicit external API contract
    > - "Go to definition" will take you directly to the type definition.
-   > 
+   >
    > Con's:
    > - TSDoc comments are located with the interface not next to the
    >   implementation source code.

src/core/README.md

@@ -9,7 +9,7 @@ Core Plugin API Documentation:
  - [Conventions for Plugins](./CONVENTIONS.md)
  - [Testing Kibana Plugins](./TESTING.md)
  - [Kibana Platform Plugin API](./docs/developer/architecture/kibana-platform-plugin-api.asciidoc )
- 
+
 Internal Documentation:
  - [Saved Objects Migrations](./server/saved_objects/migrations/README.md)
 
@@ -18,18 +18,18 @@ Internal Documentation:
 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 
+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 
+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 
+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.
 
 ### Logging
-`core` has its own [logging system](./server/logging/README.mdx) and will output log records directly (e.g. to file or terminal) when configured. When no 
+`core` has its own [logging system](./server/logging/README.mdx) and will output log records directly (e.g. to file or terminal) when configured. When no
 specific configuration is provided, logs are forwarded to the "legacy" Kibana so that they look the same as the rest of the
 log records throughout Kibana.