jsapi - improvements for 3rd party consumers

[bmingles]

Improve jsapi for 3rd party consumers

CommonJS / non-browser module support The current jsapi is exposed as 2 ES modules that have dependencies on browser apis. Certain nodejs environments like Electron and Vscode extensions only support CommonJS. They also require polyfilling a few select browser apis to make jsapi function. It would be helpful to

1. Provide jsapi with zero browser dependencies
2. Provide this as multiple module types, namely es + commonjs

Dynamic download of jsapi We currently provide jsapis via urls on running DH instances. This is great since it ensures the jsapi is compatible with the server. It does, however, require some boilerplate scripting that is a bit cumbersome for a consumer.

Npm package It seems we could address all of the above in a single npm package. There is an initial version of this in the vscode-extension https://github.com/deephaven/vscode-deephaven/tree/main/packages/require-jsapi

• Handle downloading the appropriate api based on a server url
• Provide the appropriate module format for the consumer. We should explore using esbuild as an npm module. It may be performant enough to just transpile esm -> commonjs at runtime as part of the download. Note that DHE is already commonjs (although that could change), so the package needs to be able to handle the various scenarios.

[bmingles]

@niloc132 @mofojed I created this task to facilitate some discussion / thoughts on jsapi improvements based on recent experience developing a dh vscode extension.

[bmingles]

@niloc132 I investigated node support for h2c a bit. Here's my understanding:

• node fetch uses the undici package under the hood. Http2 is not the default, but it can be enabled. It does not support h2c. Also may still be considered experimental.
• fetch-h2 package supports h2c. There are some options for manual disconnection once requests are finished. Not sure how complicated this gets in practice

[niloc132]

Concrete changes for the js api to consider (follow-up for Colin):

• Don't require window/document on global, but create them in the js api's own Scope shim
• Stop using Event and CustomEvent, but declare our own
• Stop using window.location to decide if we enable websockets or not, but use the provided URL to the server (and a flag eventually, see below)

Brian will also try again with fetch-h2, assigning to global.fetch, so that the grpc-web ts implementation we have can make h2 calls, instead of requiring websockets.

[bmingles]

I'm tracking the fetch / fetch-h2 testing in DHE: Connect to Core+ worker over http2 #154