bfetch (2)

[streamich]

Summary

Closes #44326
Partially addresses: #44393

• Moves batched_fetch to the NP, now it is plugins.bfetch.batchedFunction.
• Introduces plugins.bfetch.addBatchProcessingRoute on server-side which works with client-side plugins.bfetch.batchedFunction.
• Moves legacy interpreter server-side function execution to NP expressions plugin.
• Improves README for bfetch plugin.
• Adds bfetch_explorer example plugin.

To see the bfetch_explorer example plugin run

yarn start --run-examples

Checklist

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

• [This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

---

Dev Docs

Request batching and response streaming functionality of legacy Interpreter plugin has been moved out into a separate bfetch Kibana platform plugin. Now every plugin can create server endpoints and browser wrappers that can batch HTTP requests and stream responses back.

As an example, we will create a batch processing endpoint that receives a number then doubles it
and streams it back. We will also consider the number to be time in milliseconds
and before streaming the number back the server will wait for the specified number of
milliseconds.

To do that, first create server-side batch processing route using addBatchProcessingRoute.

plugins.bfetch.addBatchProcessingRoute<{ num: number }, { num: number }>(
  '/my-plugin/double',
  () => ({
    onBatchItem: async ({ num }) => {
      // Validate inputs.
      if (num < 0) throw new Error('Invalid number');
      // Wait number of specified milliseconds.
      await new Promise(r => setTimeout(r, num));
      // Double the number and send it back.
      return { num: 2 * num };
    },
  })
);

Now on client-side create double function using batchedFunction.
The newly created double function can be called many times and it
will package individual calls into batches and send them to the server.

const double = plugins.bfetch.batchedFunction<{ num: number }, { num: number }>({
  url: '/my-plugin/double',
});

Note: the created double must accept a single object argument ({ num: number } in this case)
and it will return a promise that resolves into an object, too (also { num: number } in this case).

Use the double function.

double({ num: 1 }).then(console.log, console.error); // { num: 2 }
double({ num: 2 }).then(console.log, console.error); // { num: 4 }
double({ num: 3 }).then(console.log, console.error); // { num: 6 }

[elasticmachine]

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

[streamich]

Question about fetchStreaming: Why does it return both an observable and a promise? Couldn't we just return the observable and any consumers can call toPromise on it if they want the promise behavior?

Yes, it does not have to return a promise, I removed it. It was for legacy reasons, because prior ajax_stream would return a promise and collect individual messages through a callback, now that the callback is replaced by an observable we don't need the promise.

Regarding TimedItemBuffer and ItemBuffer, is there any reason these classes need to be separate or can we have only a TimedItemBuffer that implements all of the behavior? As far as I can tell there's no place that one is used independently (but I could be wrong).

They are separate because they provide different functionality, they could be combined into one class, but since its already written separately, would like to leave it as is.

Also, I know you had mentioned adding in functional tests from the example plugin, is that something you're wanting to tackle in this PR or in a future one?

Yes, I added functional tests here.

[streamich]

@elasticmachine merge upstream

[lukasolson]

Recent code changes LGTM but I didn't pull down and test (although I did yesterday and everything looked good)

[streamich]

@elasticmachine merge upstream

[streamich]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: bd75508

History

• 💚 Build #20804 succeeded bd75508
• 💚 Build #20082 succeeded 62cd03a
• 💔 Build #19711 failed 6f76117
• 💔 Build #19679 failed 364826c
• 💔 Build #19350 failed c87291f

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