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

[data views] Move data views api from data plugin and into its own #113497

Merged
merged 35 commits into from
Oct 4, 2021

Conversation

mattkime
Copy link
Contributor

@mattkime mattkime commented Sep 30, 2021

Summary

Moving the data views api from the data plugin into its own plugin to shrink the data plugin bundle size and for better separation of concerns.

In order to minimize the impact of this change, the data plugin provides the data views api and re-exports data view exports. This should be removed once all api consumers are using the data view plugin directly.

@mattkime mattkime changed the title initial pass at moving data views into own plugin [data views] Move data views api from data plugin and into its own Sep 30, 2021
@mattkime mattkime added auto-backport Deprecated - use backport:version if exact versions are needed Feature:Data Views Data Views code and UI - index patterns before 8.0 release_note:skip Skip the PR/issue when compiling release notes Team:AppServicesSv v7.16.0 v8.0.0 labels Oct 1, 2021
@mattkime mattkime requested review from a team as code owners October 3, 2021 23:01
@mattkime
Copy link
Contributor Author

mattkime commented Oct 3, 2021

@elasticmachine merge upstream

@mattkime mattkime requested a review from a team as a code owner October 3, 2021 23:42
@mattkime
Copy link
Contributor Author

mattkime commented Oct 4, 2021

@elasticmachine merge upstream

Copy link
Contributor

@mbondyra mbondyra left a comment

Choose a reason for hiding this comment

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

VisEditors changes LGTM 🆗

Copy link
Member

@jgowdyelastic jgowdyelastic left a comment

Choose a reason for hiding this comment

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

ML changes LGTM

Copy link
Contributor

@Dosant Dosant left a comment

Choose a reason for hiding this comment

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

LGTM 🚀

Noticed couple issues that could be addressed:

preset: '@kbn/test',
rootDir: '../../..',
roots: ['<rootDir>/src/plugins/data_views'],
testRunner: 'jasmine2',
Copy link
Contributor

Choose a reason for hiding this comment

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

could try to remove 'jasmine2' override here. maybe it would all pass with default runner

"server/**/*.json"
],
"references": [
{ "path": "../../core/tsconfig.json" },
Copy link
Contributor

Choose a reason for hiding this comment

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

Likely not all of these references needed for data_views plugin

Copy link
Member

@mistic mistic left a comment

Choose a reason for hiding this comment

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

Changes under operations team code owners LGTM

Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

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

I think the intention here is good, but I don't think splitting views out of the data plugins is actually helping. Splitting plugins is not a good way to separate concerns and the overall impact on initial page load bundles is +11kb. I think we should take another approach here.

Copy link
Member

@mistic mistic left a comment

Choose a reason for hiding this comment

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

I've misread the bundles info here. If the goal here was to reduce the overall bundles size, it actually did the opposite. Thanks @spalger for double checking this

@mattkime
Copy link
Contributor Author

mattkime commented Oct 4, 2021

Splitting plugins is not a good way to separate concerns

I'm confused by this in part because this PR is pretty clean meaning there was a relatively good separation of concerns to begin with. Having two plugins instead of one should encourage maintaining this separation. Is there an alternative approach you recommend?

and the overall impact on initial page load bundles is +11kb.

We have a goal to keep bundle sizes below 100kb but I'm unaware of any guidelines around limiting total payload growth, particularly around something as small as 11kb.

I haven't investigated it yet, but I suspect the additional 11kb is because the data plugin reexports most of the data views plugin exports. This is to limit the overall impact on the code base due to splitting plugins. That said, I suspect you have more experience thinking about these things - what overhead can we expect introducing a new plugin? How many kb?

@mattkime
Copy link
Contributor Author

mattkime commented Oct 4, 2021

I've misread the bundles info here. If the goal here was to reduce the overall bundles size, it actually did the opposite. Thanks @spalger for double checking this

No, the goal was to reduce the size of the data plugin, which it did. The goal was not to reduce overall bundle size - I would expect some amount of combined bundle size increase by separating plugins. This is 2% growth compared to the starting point. Its not desired but I don't understand why it would dissuade from moving forward with this.

Here's where we split out field formatters from the data plugin - #107173 - Page load bundle sizes grew by 14kb and more specifically a 11.7kb growth from data plugin including field formatters vs field formatters in its own plugin.

@tylersmalley
Copy link
Contributor

tylersmalley commented Oct 4, 2021

@mattkime, the point of reducing plugin bundles is to reduce the overall page load. Details can be found in this issue: #95853

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
data 571 536 -35
dataViews - 43 +43
total +8

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
data 2800 2796 -4
dataViews - 531 +531
total +527

Any counts in public APIs

Total count of every any typed public API. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats any for more detailed information.

id before after diff
data 44 43 -1
dataViews - 6 +6
total +5

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
data 49 48 -1
dataViews - 5 +5
total +4

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
data 491.0KB 464.4KB -26.6KB
dataViews - 38.1KB +38.1KB
visualizations 32.8KB 32.8KB +20.0B
total +11.5KB
Unknown metric groups

API count

id before after diff
data 3186 3181 -5
dataViews - 671 +671
total +666

References to deprecated APIs

id before after diff
apm 57 73 +16
canvas 64 67 +3
dashboard 217 240 +23
data 2 463 +461
dataViews - 231 +231
dataVisualizer 146 242 +96
discover 1135 1790 +655
fleet 33 39 +6
graph 102 168 +66
indexPatternEditor 53 85 +32
indexPatternFieldEditor 100 156 +56
indexPatternManagement 306 496 +190
infra 358 507 +149
inputControlVis 209 325 +116
lens 248 348 +100
maps 1176 1689 +513
ml 466 704 +238
monitoring 39 53 +14
observability 112 166 +54
osquery 22 34 +12
reporting 25 29 +4
savedObjects 26 44 +18
savedObjectsManagement 17 29 +12
security 61 71 +10
securitySolution 878 1008 +130
stackAlerts 130 183 +53
timelines 75 84 +9
transform 96 148 +52
uptime 16 26 +10
visDefaultEditor 141 223 +82
visTypeTimelion 36 45 +9
visTypeTimeseries 226 347 +121
visTypeVega 29 35 +6
visualizations 89 104 +15
visualize 93 99 +6
total +3568

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@spalger
Copy link
Contributor

spalger commented Oct 4, 2021

@mattkime and I have discussed this at length and agree that this doesn't meet the goal of improving page load time or reducing bundle sizes, but think that it ultimately is worth merging for the purpose of encapsulating the "data views" and eventually being able to move that into a package. I've agreed to work with the app services team and help consult on further efforts to reduce the size of the data plugin, which we really should be able to do.

We will prevent many data* plugins from being created and I think we can accept this 11.5kb debt for now.

@mattkime mattkime merged commit bbb2e96 into elastic:master Oct 4, 2021
@kibanamachine
Copy link
Contributor

💔 Backport failed

Status Branch Result
7.x Commit could not be cherrypicked due to conflicts

To backport manually run:
node scripts/backport --pr 113497

mattkime added a commit to mattkime/kibana that referenced this pull request Oct 4, 2021
…lastic#113497)

* initial pass at moving data views into own plugin

* require expressions plugin, fix META_FIELDS reference

* bundle limits and localization

* fix integration test

* update plugin list and jest config

* type fixes

* search fixes

* fix localization

* fix mocks

* fix mocks

* fix stub

* type fixes

* fix import on test file

* path fixes

* remove shorted dotted from data plugin

* more todo removal

* eslint fixes

* eslint fix

* simplify data views server plugin

* simplify data views server plugin

* simplify data views server plugin

* fix imports on api routes

* fix imports on api routes

* update plugin list

* ts fixes

* ts fixes

* add deprecation notice

* fix circular dependency and api integration test

* fix circular dependency and api integration test

* rename types for better clarity

* path fixes

* jest.config and tsconfig cleanup

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
mattkime added a commit that referenced this pull request Oct 4, 2021
…own (#113497) (#113833)

* [data views] Move data views api from data plugin and into its own (#113497)

* initial pass at moving data views into own plugin

* require expressions plugin, fix META_FIELDS reference

* bundle limits and localization

* fix integration test

* update plugin list and jest config

* type fixes

* search fixes

* fix localization

* fix mocks

* fix mocks

* fix stub

* type fixes

* fix import on test file

* path fixes

* remove shorted dotted from data plugin

* more todo removal

* eslint fixes

* eslint fix

* simplify data views server plugin

* simplify data views server plugin

* simplify data views server plugin

* fix imports on api routes

* fix imports on api routes

* update plugin list

* ts fixes

* ts fixes

* add deprecation notice

* fix circular dependency and api integration test

* fix circular dependency and api integration test

* rename types for better clarity

* path fixes

* jest.config and tsconfig cleanup

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

* localization fix

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Deprecated - use backport:version if exact versions are needed Feature:Data Views Data Views code and UI - index patterns before 8.0 release_note:skip Skip the PR/issue when compiling release notes v7.16.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants