Best practices

Consider these best practices, whether developing code directly to the Kibana repo or building your own plugins. They are intended to support our Kibana development principals.

Performance

Are you planning with scalability in mind?

  • Consider data with many fields
  • Consider data with high cardinality fields
  • Consider large data sets, that span a long time range

  • Do you make lots of requests to the server?

Accessibility

Did you know Kibana makes a public statement about our commitment to creating an accessible product for people with disabilities? We do! It’s very important all of our apps are accessible.

Localization

Kibana is translated into other languages. Use our i18n utilities to ensure your public facing strings will be translated to ensure all Kibana apps are localized.

Conventions

  • Become familiar with our styleguide (use Typescript!)
  • Write all new code on the platform, and following conventions
  • Always use the SavedObjectClient for reading and writing Saved Objects.
  • Add `README`s to all your plugins and services.
  • Make your public APIs as small as possible. You will have to maintain them, and consider backward compatibility when making any changes to them.
  • Use EUI for all your basic UI components to create a consistent UI experience.

Re-inventing the wheel

Over-refactoring can be a problem in it’s own right, but it’s still important to be aware of the existing services that are out there and use them when it makes sense. We have service oriented teams dedicated to providing our solution developers the tools needed to iterate faster. They take care of the nitty gritty so you can focus on creative solutions to your particular problem sphere. Some examples of common services you should consider:

  • Data services

    • Search strategies

      • Use the esSearchStrategy to make raw queries to ES that will support async searching and partial results, as well as injecting the right advanced settings like whether to include frozen indices or not.

  • Embeddables

    • Rendering maps, visualizations, dashboards in your application
    • Register new widgets that will can be added to a dashboard or Canvas workpad, or rendered in another plugin.

  • UiActions

    • Let other plugins inject functionality into your application
    • Inject custom functionality into other plugins

  • Stateless helper utilities

  • state syncing and
  • state container utilities provided by

  • kibana_utils if you want to sync your application state to the URL?

Re-using these services will help create a consistent experience across Kibana from every solution.

Backward compatibility

Eventually we want to garauntee to our plugin developers that their plugins will not break from minor to minor.

Any time you create or change a public API, keep this in mind, and consider potential backward compatibility issues. While we have a formal saved object migration system and are working on adding a formal state migration system, introducing state changes and migrations in a minor always comes with a risk. Consider this before making huge and risky changes in minors, especially to saved objects.

  • Are you persisting state from registries? Consider what will happen if the author of the implementation changed their interfaces.
  • Are you adding implementations to registries? Consider that someone may be persisting your data, and that making changes to your public interfaces can break their code.

Be very careful when changing the shape of saved objects or persistable data.

Saved object exported from past Kibana versions should continue to work. In addition, if users are relying on state stored in your app’s URL as part of your public contract, keep in mind that you may also need to provide backwards compatibility for bookmarked URLs.

Testing & stability

Review:

Most Popular