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

bfetch #52888

Merged
merged 28 commits into from
Dec 14, 2019
Merged

bfetch #52888

merged 28 commits into from
Dec 14, 2019

Conversation

streamich
Copy link
Contributor

@streamich streamich commented Dec 12, 2019

Summary

  • Ports ajax_stream to the New Platform
  • Creates bfetch plugin to host all batching and streaming services
  • Switches Interpreter to use bfetch for response streaming
  • Adds bfetch.addStreamingResponseRoute() on the server side, which will be used in the future for implementing batch request processing on the server.
  • There will be further work on this to create a higher level abstraction to allow any plugin to easily create a batched endpoint, e.g. batched_fetch will be moved to NP and integreated into bfetch plugin such that any plugin can create a batching endpoint.

Partially adresses: #44393
Part of: #46909

Checklist

For maintainers


Dev Docs

ajax_stream has been ported to the New Platform. Use fetchStreaming() method of bfetch plugin instead.

import { npStart } from 'ui/new_platform';

const { stream, promise } = npStart.plugins.bfetch.fetchStreaming({ url: 'http://elastic.co' });

@streamich streamich requested a review from a team as a code owner December 12, 2019 14:53
@streamich streamich added Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. review Team:AppArch v7.6.0 v7.7.0 v8.0.0 labels Dec 12, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch (Team:AppArch)

@streamich streamich changed the title Bfetch bfetch Dec 12, 2019
Copy link
Contributor

@chrisdavies chrisdavies left a comment

Choose a reason for hiding this comment

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

Everything looks pretty good to me. Switching to rxjs instead of some random, ad-hoc thing is definitely an improvement. I'm a bit concerned about the way errors are swallowed on the server here, though.

@lukasolson lukasolson mentioned this pull request Dec 12, 2019
4 tasks
src/plugins/kibana_utils/common/defer.ts Show resolved Hide resolved
src/plugins/bfetch/server/plugin.ts Outdated Show resolved Hide resolved
src/plugins/bfetch/public/streaming/split.test.ts Outdated Show resolved Hide resolved
src/plugins/bfetch/public/plugin.ts Outdated Show resolved Hide resolved
src/plugins/bfetch/README.md Show resolved Hide resolved
Copy link
Contributor

@chrisdavies chrisdavies left a comment

Choose a reason for hiding this comment

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

LGTM. w/ tweaks (logging should use the Kibana logger vs console)

Copy link
Contributor Author

@streamich streamich left a comment

Choose a reason for hiding this comment

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

@chrisdavies I've changed it to use Kibana logger.

With regards to errors, we agreed with @chrisdavies that those are lowest level protocol errors and there is no benefit to streaming them back. Instead a higher level abstraction will implement its own application errors that will indeed be streamed back.

@lizozom I'm not sure what you mean, what are you proposing to retry?

Copy link
Member

@lukeelmers lukeelmers left a comment

Choose a reason for hiding this comment

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

My only main concern here is using the export * in our public/index and server/index files -- we are already exporting internal things here, and this is a brand new plugin. Having just started the process of cleaning these up in the data plugin, I can testify that it is incredibly time consuming to retroactively go back and figure out what pieces of a plugin are truly public. So I think we should be explicit from the start on this one so we don't create more work for ourselves later.

One broader question I'm interested in: In the original POC, this was introduced as part of the data plugin. What was the motivation for changing the approach to making this a standalone plugin? Are there technical or design reasons why this is necessary?

It feels like a relatively small domain to justify its own plugin, but I'm sure there are pros and cons which we could discuss further.

src/plugins/kibana_utils/public/index.ts Outdated Show resolved Hide resolved
src/plugins/kibana_utils/public/index.ts Outdated Show resolved Hide resolved
src/plugins/bfetch/server/index.ts Outdated Show resolved Hide resolved
src/plugins/bfetch/public/index.ts Outdated Show resolved Hide resolved
@streamich
Copy link
Contributor Author

streamich commented Dec 13, 2019

@lukeelmers with regards bfetch being a separate plugin, I always thought it should be a separate plugin thus it says so in the issue. In size it is actually comparable to any of our plugins. For example expressions plugin is just over 5,000 lines of code, inspector plugin is also around 5,000 line of code, etc.. This first PR adds about 1,500 lines to the bfetch plugin and once it is fully complete it will be at least 3-4x larger. In terms of domain it seems like a perfect fit for a plugin. If it was part of data plugin, we would have a circular dependency between data plugin and expressions plugin.

@streamich streamich requested a review from lukeelmers December 13, 2019 21:41
Copy link
Member

@lukeelmers lukeelmers left a comment

Choose a reason for hiding this comment

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

Thanks for making those export changes! Rest of the code LGTM.

If it was part of data plugin, we would have a circular dependency between data plugin and expressions plugin.

IMO this is good enough reason to keep bfetch separate for now.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

History

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

@streamich streamich merged commit 5fee62b into elastic:master Dec 14, 2019
streamich added a commit that referenced this pull request Dec 14, 2019
* feat: 🎸 add bfetch plugin stub

* feat: 🎸 add sample routes

* feat: 🎸 implement streaming response

* feat: 🎸 add Defer class

* refactor: 💡 move Defer inot /common folder

* feat: 🎸 add fromStreamingXhr() method

* feat: 🎸 add split method

* feat: 🎸 add fetchStreaming() function

* test: 💍 fix test after refactor

* test: 💍 add tests for fetStreaming() method

* refactor: 💡 move removeLeadingSlash() to /common folder

* feat: 🎸 expor stateful fetchStreaming() throuh plugin contract

* chore: 🤖 clean up bfetch

* chore: 🤖 prepare to replace ajax_stream by bfetch

* Change ajax_stream to use new-line delimited JSON

* refactor: 💡 move batched_fetch to use bfetch service

* refactor: 💡 make use of defer() utility from kibana_utils

* chore: 🤖 remove ajax_stream library

* fix: 🐛 fix tests and inject fetchStreaming() method as dep

* refactor: 💡 make split() operator more readable

* refactor: 💡 improvee PR according to feedback

* docs: ✏️ add fetchStreaming() reference

* refactor: 💡 use NP logger, rename to createNDJSONStream()

* chore: 🤖 adress Luke's review comments

* chore: 🤖 add missing type
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. review v7.6.0 v7.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants