kibana/dev_docs/tutorials/building_a_plugin.mdx

---
id: kibDevTutorialBuildAPlugin
slug: /kibana-dev-docs/tutorials/build-a-plugin
title: Kibana plugin tutorial
summary: Anatomy of a Kibana plugin and how to build one
date: 2021-02-05
tags: ['kibana','onboarding', 'dev', 'tutorials']
---

Prereading material:

- <DocLink id="kibPlatformIntro" />

## The anatomy of a plugin

Plugins are defined as classes and present themselves to Kibana through a simple wrapper function. A plugin can have browser-side code, server-side code,
or both. There is no architectural difference between a plugin in the browser and a plugin on the server. In both places, you describe your plugin similarly, 
and you interact with Core and other plugins in the same way.

The basic file structure of a Kibana plugin named demo that has both client-side and server-side code would be:

```
plugins/
  demo
    kibana.json [1]
    public
      index.ts  [2]
      plugin.ts [3]
    server
      index.ts  [4]
      plugin.ts [5]
    common
      index.ts  [6]
```

### [1] kibana.json 

`kibana.json` is a static manifest file that is used to identify the plugin and to specify if this plugin has server-side code, browser-side code, or both:

```
{
  "id": "demo",
  "version": "kibana",
  "server": true,
  "ui": true
}
```

### [2] public/index.ts

`public/index.ts` is the entry point into the client-side code of this plugin. It must export a function named plugin, which will receive a standard set of
 core capabilities as an argument. It should return an instance of its plugin class for Kibana to load.

```
import type { PluginInitializerContext } from 'kibana/server';
import { DemoPlugin } from './plugin';

export function plugin(initializerContext: PluginInitializerContext) {
  return new DemoPlugin(initializerContext);
}
```

### [3] public/plugin.ts

`public/plugin.ts` is the client-side plugin definition itself. Technically speaking, it does not need to be a class or even a separate file from the entry
 point, but all plugins at Elastic should be consistent in this way.


 ```ts
import type { Plugin, PluginInitializerContext, CoreSetup, CoreStart } from 'kibana/server';

export class DemoPlugin implements Plugin {
  constructor(initializerContext: PluginInitializerContext) {}

  public setup(core: CoreSetup) {
    // called when plugin is setting up during Kibana's startup sequence
  }

  public start(core: CoreStart) {
    // called after all plugins are set up
  }

  public stop() {
    // called when plugin is torn down during Kibana's shutdown sequence
  }
}
 ```


### [4] server/index.ts 

`server/index.ts` is the entry-point into the server-side code of this plugin. It is identical in almost every way to the client-side entry-point:

### [5] server/plugin.ts

`server/plugin.ts` is the server-side plugin definition. The shape of this plugin is the same as it’s client-side counter-part:

```ts
import type { Plugin, PluginInitializerContext, CoreSetup, CoreStart } from 'kibana/server';

export class DemoPlugin implements Plugin {
  constructor(initializerContext: PluginInitializerContext) {}

  public setup(core: CoreSetup) {
    // called when plugin is setting up during Kibana's startup sequence
  }

  public start(core: CoreStart) {
    // called after all plugins are set up
  }

  public stop() {
    // called when plugin is torn down during Kibana's shutdown sequence
  }
}
```

Kibana does not impose any technical restrictions on how the the internals of a plugin are architected, though there are certain 
considerations related to how plugins integrate with core APIs and APIs exposed by other plugins that may greatly impact how they are built.

### [6] common/index.ts

`common/index.ts` is the entry-point into code that can be used both server-side or client side.

## How plugin's interact with each other, and Core

The lifecycle-specific contracts exposed by core services are always passed as the first argument to the equivalent lifecycle function in a plugin. 
For example, the core http service exposes a function createRouter to all plugin setup functions. To use this function to register an HTTP route handler, 
a plugin just accesses it off of the first argument:

```ts
import type { CoreSetup } from 'kibana/server';

export class DemoPlugin {
  public setup(core: CoreSetup) {
    const router = core.http.createRouter();
    // handler is called when '/path' resource is requested with `GET` method
    router.get({ path: '/path', validate: false }, (context, req, res) => res.ok({ content: 'ok' }));
  }
}
```

Unlike core, capabilities exposed by plugins are not automatically injected into all plugins.
Instead, if a plugin wishes to use the public interface provided by another plugin, it must first declare that plugin as a
 dependency in it’s kibana.json manifest file.

** foobar plugin.ts: **

```
import type { Plugin } from 'kibana/server';
export interface FoobarPluginSetup { [1]
  getFoo(): string;
}

export interface FoobarPluginStart { [1]
  getBar(): string;
}

export class MyPlugin implements Plugin<FoobarPluginSetup, FoobarPluginStart> {
  public setup(): FoobarPluginSetup {
    return {
      getFoo() {
        return 'foo';
      },
    };
  }

  public start(): FoobarPluginStart {
    return {
      getBar() {
        return 'bar';
      },
    };
  }
}
```
[1]  We highly encourage plugin authors to explicitly declare public interfaces for their plugins.


** demo kibana.json**

```
{
  "id": "demo",
  "requiredPlugins": ["foobar"],
  "server": true,
  "ui": true
}
```

With that specified in the plugin manifest, the appropriate interfaces are then available via the second argument of setup and/or start:

```ts
import type { CoreSetup, CoreStart } from 'kibana/server';
import type { FoobarPluginSetup, FoobarPluginStart } from '../../foobar/server';

interface DemoSetupPlugins {  [1]
  foobar: FoobarPluginSetup;
}

interface DemoStartPlugins {
  foobar: FoobarPluginStart;
}

export class DemoPlugin {
  public setup(core: CoreSetup, plugins: DemoSetupPlugins) { [2]
    const { foobar } = plugins;
    foobar.getFoo(); // 'foo'
    foobar.getBar(); // throws because getBar does not exist
  }

  public start(core: CoreStart, plugins: DemoStartPlugins) { [3]
    const { foobar } = plugins;
    foobar.getFoo(); // throws because getFoo does not exist
    foobar.getBar(); // 'bar'
  }

  public stop() {}
}
```
	
[1] The interface for plugin’s dependencies must be manually composed. You can do this by importing the appropriate type from the plugin and constructing an interface where the property name is the plugin’s ID.

[2] These manually constructed types should then be used to specify the type of the second argument to the plugin.

[3] Notice that the type for the setup and start lifecycles are different. Plugin lifecycle functions can only access the APIs that are exposed during that lifecycle.