[kbn/server-route-repository] Migrate plugins to use the package

[miltonhultgren]

Within the Observability solution we tend to mix between using Core HTTP directly, using @kbn/server-route-repository or a mix (see https://github.com/elastic/kibana/issues/198681).

Once https://github.com/elastic/kibana/issues/198681 is done, we should be at a point where there are only two ways* that HTTP APIs are defined, but our guidelines describe that the recommended way is to use @kbn/server-route-repository, thus we should consider if we should migrate all or some of the existing plugins to use the package.

This may be most relevant for plugins that are still seeing active development.

* In theory, in practice there are differences in the patterns employed before reaching Core's HTTP router

Affected plugins

• infra [@elastic/obs-ux-logs-team, @elastic/obs-ux-infra_services-team]
• logs_shared [@elastic/obs-ux-logs-team]
• metrics_data_access [@elastic/obs-ux-infra_services-team]
• profiling [@elastic/obs-ux-infra_services-team]
• synthetics [@elastic/obs-ux-management-team]
• uptime [@elastic/obs-ux-management-team]

[elasticmachine]

Pinging @elastic/obs-knowledge-team (Team:obs-knowledge)

[miltonhultgren]

FYI @elastic/obs-ux-logs-team @elastic/obs-ux-infra_services-team @elastic/obs-ux-management-team

Can you give me some insight into if any of these plugins are seeing active or future development?

[tonyghiani]

@miltonhultgren regarding the APIs owned by the logs team:

• logs_shared register APIs for the log views and log entries retrieval, which are only used for the legacy logs stream app. Given the direction we are taking for logs exploration, no active or upcoming work is planned for those endpoints.
• In the infra plugin we own APIa for log_alerts and log_analisys, which are currently pretty stale and we don't have any plans to update them in the short term. If the obs-ux-infra team will start migrating the majority of the infrastructure APIs to @kbn/server-route-repository, we can help there on moving also those endpoint to make the implementation consistent across the plugin.

[miltonhultgren]

Thank you @tonyghiani, that's exactly the kind of context I was looking for 🙌🏼 We won't make any decisions now but based on your feedback I would imagine we leave these APIs as they are.

I will mention one more thing: There is nothing stopping a plugin from using both systems, so it's possible to migrate only the active endpoints for example (if some endpoints are planned for deprecation for example). This means the work doesn't have to be done all at once, the package can be adopted incrementally across multiple PRs.