Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[New platform] Introduce start phase for core services on server #35297

Merged
merged 23 commits into from Apr 30, 2019

Conversation

mshustov
Copy link
Contributor

@mshustov mshustov commented Apr 18, 2019

Summary

The main reason for pushing start phase on the server side is exposing an ability to register a router in New platform.
I added a full support for start method only for http, legacy & plugins services and changed their API accordingly.
Now HTTP service exposed

  • a setup contract as
interface Setup {
  server: Server;
  options: ServerOptions;
  registerRouter: (router: Router) => void;
  registerAuth: (authenticationHandler,  cookieOptions) => void;
  registerOnRequest: (requestHandler: OnRequestHandler) => void;
}
  • a start contract as
interface Start {
  isListening: () => boolean;
}

Legacy service stores passed setup contracts and create an instance of KbnServer on start
Other core services expose start method, but it is just noop.
Remaining core services can be updated in following PR:

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@mshustov mshustov changed the title Introduce start phase for core services on server [New platform] Introduce start phase for core services on server Apr 18, 2019

await root.setup();
const { http } = await root.setup();
http.registerRouter(router);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe it seems redundant to call both methods to run a test server. that was done to support such cases without introducing a lot of changes.

I believe we can easily to fix this later. For example, we can extend KbnTestServer in a way it creates root, declares all routes and after starts a real server.

src/core/public/plugins/plugins_service.ts Outdated Show resolved Hide resolved
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@mshustov mshustov marked this pull request as ready for review April 18, 2019 17:01
@mshustov mshustov requested review from a team as code owners April 18, 2019 17:01
@mshustov mshustov added Feature:New Platform Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc release_note:skip Skip the PR/issue when compiling release notes v7.2.0 labels Apr 19, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform

src/core/server/legacy/legacy_service.ts Outdated Show resolved Hide resolved
const serverOptions = getServerOptions(config);
this.server = createServer(serverOptions);

return {
options: serverOptions,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deepFreeze might be a good idea here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aah yeah. I wanted to add freeze here, but found that we have 2 implementations - one for js in x-pack/secuirty, one for ts in core/public/utils. I think it makes sense to reach an agreement how we going to distribute environment agnostic code snippets, case with deepFreeze is perfect example. Do we have such agreement? If not I will create a discussion

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think that we do have a guideline on sharing code other than things that live as @kbn/ packages. Could make sense to move this utility there, but it's so small, I'm not sure the boilerplate of a separate package is worth it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

turned out the correct implementation is not so simple microsoft/TypeScript#13923

for now I will copy this functionality, but we need to extract it in a separate package later

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

to get rid of Optional<HttpServer> type and make it Require<HttpServer>
@mshustov mshustov requested review from joshdover and removed request for a team April 25, 2019 08:15
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@joshdover joshdover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really good, really just one small comment.

When you add this to the PluginsService in the follow up PR, do you also plan to introduce this to the plugin spec themselves at the same time? I'm asking because I've already added the start lifecycle event to UI plugins.

src/core/server/server.ts Outdated Show resolved Hide resolved
const serverOptions = getServerOptions(config);
this.server = createServer(serverOptions);

return {
options: serverOptions,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think that we do have a guideline on sharing code other than things that live as @kbn/ packages. Could make sense to move this utility there, but it's so small, I'm not sure the boilerplate of a separate package is worth it.

@mshustov
Copy link
Contributor Author

When you add this to the PluginsService in the follow up PR, do you also plan to introduce this to the plugin spec themselves at the same time? I'm asking because I've already added the start lifecycle event to UI plugins.

agree, I will add it for parity.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@mshustov mshustov merged commit 39091e7 into elastic:master Apr 30, 2019
mshustov added a commit to mshustov/kibana that referenced this pull request Apr 30, 2019
…stic#35297)

* introduce start phase. setup is bloated with start functionality

* fix amp typings: server is part of start contract now

* update mock files

* root.start(): necessary to run test server

* expose  setup&start server api to simplify testing

* move tests to the new API

* test servers also should call root.start()

* update docs

* update snapshots: this functionality is tested in http server

* split setup/start phases

* update docs

* expose http server if it not started

to get rid of Optional<HttpServer> type and make it Require<HttpServer>

* adopt test to exposed Http server via SetupContract

* udpate docs

* cleanup apm changees

* check legacy service setup before start

* check http server setup before start

* restrict server options mutation; unify Promise interface for setup

* introduce start pahse for plugins service for parity with client side

* Revert "introduce start pahse for plugins service for parity with client side"

This reverts commit c04fdd2.
@mshustov mshustov removed the review label Apr 30, 2019
mshustov added a commit that referenced this pull request Apr 30, 2019
) (#35791)

* introduce start phase. setup is bloated with start functionality

* fix amp typings: server is part of start contract now

* update mock files

* root.start(): necessary to run test server

* expose  setup&start server api to simplify testing

* move tests to the new API

* test servers also should call root.start()

* update docs

* update snapshots: this functionality is tested in http server

* split setup/start phases

* update docs

* expose http server if it not started

to get rid of Optional<HttpServer> type and make it Require<HttpServer>

* adopt test to exposed Http server via SetupContract

* udpate docs

* cleanup apm changees

* check legacy service setup before start

* check http server setup before start

* restrict server options mutation; unify Promise interface for setup

* introduce start pahse for plugins service for parity with client side

* Revert "introduce start pahse for plugins service for parity with client side"

This reverts commit c04fdd2.
@mshustov mshustov mentioned this pull request May 21, 2019
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.2.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants