Serve a slimmer core-only bundle for Kibana Platform applications

[joshdover]

As more plugins migrate to the New Platform and the addition of the new optimizer system, our frontend JS bloat is growing larger.

We should be able to conditionally serve a different JS entry point and other JS bundles for bootstrapping the frontend of Kibana based on whether or not we are mounting a legacy application. This could potentially significantly cut down on how much JS we send to the client on initial bootstrap for most use cases.

Steps to making this possible:

• Add a "core" entry point output to the new @kbn/optimizer that:
  • Does not require loading the vendor DLLs or common bundle
  • Does not import any legacy code
  • Does not import any ui exports
• Enhance the backend bootstrapping route to serve the legacy or core bundle when appropriate
  • The backend already serves different bundles based on whether or not the route points to a known legacy application. We just need to change this to serve the a new slimmer bundle (from step above) as well as omitting the vendor DLLs, , commons bundle, and any global CSS that is not needed.

Related issues:

• Migrate bootstrap.js endpoint to Kibana Platform Migrate the bootstrap.js endpoint to Kibana Platform #54375
• Improve plugin bundle load time Improve plugin bundle load time #55241

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[spalger]

I really like this idea.

Step one seems easy enough if we can isolate and remove the places where legacy code is required by the core.

I'm not sure how we'll be able to handle the second step, because I'm pretty sure that there are cases where we need the legacy code to be loaded for new platform application, no?

[joshdover]

I'm not sure how we'll be able to handle the second step, because I'm pretty sure that there are cases where we need the legacy code to be loaded for new platform application, no?

I don't believe so. On the client, I believe the only legacy code we import is already done conditionally based on whether or not we're rendering a legacy application:

• https://github.com/elastic/kibana/blob/master/src/core/public/legacy/legacy_service.ts#L94
• https://github.com/elastic/kibana/blob/master/src/core/public/legacy/legacy_service.ts#L117

We can probably configure webpack in @kbn/optimizer to use empty modules for these specific paths. Since they'll never actually be imported in this case, that should work fine.

The only other place I can think of where we have the potential to import legacy code is in the entry point template: https://github.com/elastic/kibana/blob/master/src/legacy/ui/ui_bundles/app_entry_template.js#L47

I'd have to double check, but I believe this array is empty for the "core bundle" that is created here: https://github.com/elastic/kibana/blob/master/src/legacy/ui/ui_bundles/ui_bundles_controller.js#L102

For the entry point we'd create for this core-only bundle, we can just set that requireLegacyFiles function to a no-op.

Anything else I could be missing?

[spalger]

Do you think we could move the whole legacy_service into a parameter passed to the CoreSystem constructor only by the app_entry_template.js? (going to rename that to mention legacy somehow)

Then we could just continue to disallow legacy stuff in the @kbn/optimizer, not have any special cases, and just have a different entry template for the core bundle which loads a Kibana platform app.

[joshdover]

Good idea. We can't move the everything that is in the legacy service right now, because it still does do some things we need like registering legacy applications with the nav. As far as Core is concerned, Legacy apps are really just dumb navlinks, they don't have any actual legacy code associated with them.

But we could parameterize the legacy modules that it imports (ui/chrome, ui/test_harness, ui/new_platform) so that those only live in the app_entry_template.

I'll take a swing at that first step!

[pgayvallet]

But we could parameterize the legacy modules that it imports (ui/chrome, ui/test_harness, ui/new_platform) so that those only live in the app_entry_template.

Sounds like the correct approach to me. It seems the list is exhaustive, so we only have to do that for 3 modules, seems reasonable.

Another minor point:

ui imports are currently untyped in core

require('ui/new_platform').__setup__(legacyCore, plugins); for example.

If we move the ui/xxx imports into CoreSystem's Params, do we plan to also introduce minimal typings for them (to match core usages)?

[mshustov]

We can probably configure webpack in @kbn/optimizer to use empty modules for these specific paths. Since they'll never actually be imported in this case, that should work fine.

Would it solve #58327 ?

[spalger]

We can probably configure webpack in @kbn/optimizer to use empty modules for these specific paths. Since they'll never actually be imported in this case, that should work fine.

Would it solve #58327 ?

Either solution should, once the core can be imported and built by @kbn/optimizer other plugins will be able to import it too (and build its entire source into their plugin...)

[joshdover]

I've put up a working POC here: #61011

Still need to update some internal core tests, but feedback is welcome.

Preliminary results in dev mode are promising (take a look at the MB transferred):

Before

After

Once this improvement goes in, by far the next biggest opportunity is to reduce the queue time incurred by the large number of requests required to load plugins. This could be solved by either adding HTTP/2 support or concatenating all plugin bundles into a single request (#55241).