Discussion. Example: registry to NP by streamich · Pull Request #37310 · elastic/kibana

streamich · 2019-05-29T07:28:50Z

Proposal: start using NP as soon as possible, move every single line we can to NP.

This example moves interpreter function registry into NP plugin. NP allows for a plugin with the same name, in this case interpreter, to exist as a legacy plugin as well as an NP plugin.

Following this pattern we can move everything line-by-line to the NP. This example moves just one of many registries.

We could proceed by:

Moving more registries to NP.
Moving uses of registries to NP.
In general, moving everything that has no Angular (like Embeddables API).

Benefits of moving every single line of code we can to NP as soon as possible:

We know that already migrated code actually works in NP.
Migration is a continuous process. Instead if we move a whole plugin or a collection of plugins at once there can (and probably will) be surprises.
We know the NP functionality that migrated code uses works.
We can track our progress very precisely by LOC in src/plugins vs src/legacy folders.

Our migration metric could be LOC in src/plugins folder vs LOC in src/legacy folder.

find src/plugins -name '*.*' | xargs wc -l
     145 total

find src/legacy -name '*.*' | xargs wc -l
     104589 total

Currently we have 145 LOC in plugins and 104,589 LOC in legacy. So our migration progress is 0.14%.

streamich · 2019-05-29T07:30:09Z

src/legacy/ui/public/new_platform/new_platform.ts


 export function getNewPlatform() {
-  if (runtimeContext.setup.core === null || runtimeContext.start.core === null) {
+  if (runtimeContext.setup.core === null /* || runtimeContext.start.core === null */) {


My understanding was that platform loading follows

NP setup -> NP start -> legacy platform

but for some reason when legacy runs runtimeContext.start.core is still null.

Does this need to be resolved before merging?

We don't need to merge this PR, I should have made it as a Draft. I guess, this is just an example of moving one Interpreter registry, but I am looking into moving way bigger chunk of Interpreter, as it does not have many dependencies.

But in general this runtimeContext.start.core must be addressed somehow. For moving registries we don't need runtimeContext.start.core, but kibana-react will probably need runtimeContext.start.core in legacy world.

elasticmachine · 2019-05-29T08:25:46Z

💔 Build Failed

continuous-integration/kibana-ci/pull-request

m-adams · 2019-05-29T08:28:45Z

Does anybody know why I'm a reviewer on this??

streamich · 2019-05-29T08:30:27Z

@m-adams sorry I was selecting the other Matt and apparently clicked on you, too.

lukeelmers · 2019-05-29T15:44:24Z

I love this idea and think it'll give us a concrete way to look at progress as we get further down the migration path, while simultaneously starting to test NP services. This basically answers the question of how we will deal with the last step in the migration process.

As long as we keep re-exporting the new platform contracts from the equivalent legacy plugins, then this can all happen behind the scenes without downstream plugins being aware of what's going on. Basically replicating the pattern we've been using in Phase I as we move legacy code into legacy plugins.

Then at the end of migration, we will end up with a bunch of "empty" legacy plugins that are simply re-exporting the new platform plugin contracts, at which point we can kill the legacy plugin and fully cut over to new platform.

With the introduction of this step, that means the new platform migration process for each plugin would look something like this:

Phase I

Consolidate legacy code into legacy plugins with new platform-style plugin definition shims & contracts
Metric: # of plugins & ui/public directories that have been moved to their new home

Phase II

De-Angularize & manage stateful dependencies from the top level of each plugin
Metric: # of plugins which have had dependencies updated & Angular removed

Phase III (pattern established by this PR)

Gradually move "leaf" node services to the new platform behind the scenes, re-exporting from their corresponding legacy plugins.
Metric: LOC moved to the NP plugins directory, as @streamich describes above

[Edit: Just because this step is Phase III doesn't mean it shouldn't start happening now, as long as a plugin has made it through the first two steps]

elasticmachine · 2019-05-29T16:43:48Z

Pinging @elastic/kibana-app-arch

joshdover

I know this is a draft, but there are some things to know about the conventions we're adopting.

joshdover · 2019-05-29T16:28:11Z

src/plugins/interpreter/public/index.ts

+
+import { FunctionsRegistry } from './registries';
+
+export const plugin = () => ({


All plugins at Elastic should follow the class convention of defining plugins, it's also useful to implement the Plugin interface for that class.

This plugin needs to export types for it's setup and start contracts.

Good to know!
And then things can be imported statically from the top level of the plugin.

mattkime · 2019-05-30T14:45:39Z

src/plugins/interpreter/public/registries.ts

+ */
+
+import { Registry } from '@kbn/interpreter/common';
+const { Fn } = require('@kbn/interpreter/common'); // eslint-disable-line


why does this line use require instead of an import statement?

Because Fn does not appear in TypeScript .d.ts, I believe, in @kbn/interpreter/common, so it complains.

streamich · 2019-07-02T22:29:42Z

Half of Interpreter has been moved to the NP, next half is to be followed shortly.

refactor: 💡 move interpreter function registre to NP

146c65c

streamich commented May 29, 2019

View reviewed changes

streamich requested review from m-adams, mattkime and ppisljar May 29, 2019 08:05

streamich requested review from epixa, joshdover, lizozom, lukasolson and lukeelmers and removed request for m-adams May 29, 2019 08:30

streamich changed the title ~~Example: registry to NP~~ Discussion. Example: registry to NP May 29, 2019

streamich requested a review from stacey-gammon May 29, 2019 15:34

lukeelmers added the :AppArch label May 29, 2019

joshdover reviewed May 29, 2019

View reviewed changes

mattkime reviewed May 30, 2019

View reviewed changes

streamich requested a review from timroes June 6, 2019 20:13

streamich mentioned this pull request Jun 14, 2019

[DISCUSS] Registries #36705

Closed

streamich closed this Jul 2, 2019


		import { FunctionsRegistry } from './registries';

		export const plugin = () => ({

Conversation

streamich commented May 29, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

streamich May 29, 2019

Choose a reason for hiding this comment

Uh oh!

mattkime May 29, 2019

Choose a reason for hiding this comment

Uh oh!

streamich May 29, 2019

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented May 29, 2019

💔 Build Failed

Uh oh!

m-adams commented May 29, 2019

Uh oh!

streamich commented May 29, 2019

Uh oh!

lukeelmers commented May 29, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elasticmachine commented May 29, 2019

Uh oh!

joshdover left a comment

Choose a reason for hiding this comment

Uh oh!

joshdover May 29, 2019

Choose a reason for hiding this comment

Uh oh!

lizozom May 30, 2019

Choose a reason for hiding this comment

Uh oh!

mattkime May 30, 2019

Choose a reason for hiding this comment

Uh oh!

streamich May 30, 2019

Choose a reason for hiding this comment

Uh oh!

streamich commented Jul 2, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

streamich commented May 29, 2019 •

edited

Loading

lukeelmers commented May 29, 2019 •

edited

Loading