[Meta] Index Patterns Everywhere

[stephmilovic]

Closed in favor of #113440

As I began work on Index pattern "pattern list” support (comma delimited list of index patterns) #87851 , it became apparent that in order to make enhancements to Kibana Index Patterns (KIP), first we would need to sync across how we are using KIP by making 2 pre-requisite changes. Otherwise, implementing the change causes a lot of downstream changes.

1. All Kibana apps should use the IndexPatternsService to access index patterns, not the saved objects API

For example, many apps are directly accessing KIP via the saved objects api rather than using the IndexPatternsService . If these apps were using the IndexPatternsService , everyone gets index pattern updates for free via rather than updating their saved object requests. Perhaps an important spot to update is the Saved Objects API documentation, which uses type: 'index-pattern' as an example!

• Replace direct saved object usage with index patterns service Use index pattern service to load index patterns #91715

2. The IndexPatternsService is currently being called both client side and server side.

• The IndexPatternsService should not be called by the index pattern server routes
• The IndexPatternsService methods should be updated to be like the getFieldsForWildcard, which makes a server-side call to do the work. All the logic from IndexPatternsService should be moved to server-side file IndexPatternsFetcher.
• The routes that reference client-side IndexPatternsService should be changed to reference the new methods in server-side IndexPatternsFetcher

Once these 2 issues are handled, something like the patternList update becomes easy to implement. Reference this PR for the code.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[ppisljar]

lets have a sync about this proposals. I completely agree with 1. but I am not sure i understand 2. correctly.

our plan regarding server/client side index patterns goes mostly like this:

• all calls to elasticsearch should be made from server side
• as much as possible of actual code/logic should exist only on the server
• server should expose public API (to be consumed by other plugins) as well as REST API (to be consumed by client side and other software outside of kibana when necesarry)
• client side API should be just a wrapper around REST API mimicking the same interface we have on public interface on the server

[ryankeairns]

The UI side of this needs some design work, up front, since this is a critical piece of the user experience. This change will affect many applications and seems somewhat complex. The @elastic/kibana-design team can assist.

[mattkime]

closing in favor of #113440 - we'll work out the improved definition over there.