browser-side support

[gflarity]

For now, the client is implemented for server-side use with node using the request library.

Just curious. Aside from the use of the request library, are there any other major impediments to supporting direct browser usage?

Would this be a welcome/encouraged contribution?

[brendandburns]

You would need to regenerate the client to use jquery or something else. It's a welcome contribution, but it requires working with the https://github.com/kubernetes-client/gen repository to change/update the code generator.

[NicolasT]

Recent versions of swagger-codegen (as used by kubernetes-client) have a typescript-fetch 'language' type which should be portable across NodeJS and browser (using portable-fetch, which is what the generated code uses).

However, things are not as simple. There's a bit of code (config.ts mainly) that's quite tightly coupled to a NodeJS environment (not sure how to read kubeconfig files in a browser from fs...). As such, having a single library entrypoint (index.ts) which exports everything and works cross-environment won't work. In a browser environment, you'll likely want a more simple configuration mechanism, e.g. providing a bearer token you already retrieved using an OIDC implicit flow dance.

Also, some code (watch support) is using request directly.

Anyway.

Since I need browser-based access to the API soon'ish, I took the liberty to fork this repository and 'hack things in'. The resulting branch is published at https://github.com/scality/kubernetes-client-javascript/commits/browser

I don't claim this is the 'right' way to achieve the goal (it's most certainly not), but does the trick (for now).

The way it works: it uses Webpack's alias feature to re-implement what api.ts uses from request, but using fetch instead. Code is in src/browser/request-fetch.js. This is not meant as a drop-in replacement for request, only the bare minimum required.

I also dropped the NodeJS config module for a slightly different one (src/browser/config.js) which for basic usage exposes a similar interface, given a known token.

Finally, because saw no way to implement the request API used by the watch module based on fetch (a request result is a stream.Readable you can pipe, which can't be constructed when a call to fetch returns), I re-implemented that module (src/browser/watch.js), using the same logic and libraries, mostly, now including code to morph a fetch ReadableStream into a stream.Readable for further processing.

I also include a very bare-bones example in example/browser (see README.md on how to run it) which does an OIDC dance, logs you in, performs a getNode call (assuming you have the right RBAC authz) and starts a watch for cluster events which get dumped to the Javascript console.

All of this only got some small amounts of manual testing. No guarantees everything works 'just fine', at all!.

To consume the library, don't import src/browser/index.ts or dist/browser/index.js, because that won't work, unless (maybe?) if you configure your project Webpack config to alias request properly. Instead, I set the browser entry-point in package.json to dist/browser/bundle.js, which is also checked into the repository, and has the request stubs in place.

Finally, if a browser-friendly version of this library would be developed, I believe the API of the watch module should be revisited: let it return a ReadableStream or stream.Readable of watch results instead of working callback-based with a custom 'end' callback.

[NicolasT]

I figured one could adjust how kubernetes-client/gen generates the API bindings, to make it generate typescript-fetch code which would then work in the browser, and be done with it.

However, things aren't as simple: with fetch, there's no way to emulate strictSSL = false to ignore 'invalid' TLS certificates, which is possible in the current library. This feature will never be possible on client-side anyway.

So, if this feature is to be retained, then we can't use fetch in a NodeJS environment. At the same time, the hack I did to substitute request with a fetch wrapper, and the code required to make watch work in a browser (which will likely need some duplication if #214 lands) with a somewhat odd API as a result, suggest the NodeJS and browser bindings may need to be two completely different libraries...

[burn2delete]

I agree, this library makes heavy use of platform specific code. We should move the browser javascript to it's own repo.

[NicolasT]

Goh... not entirely sure about that, to be honest. It should be possible to keep NodeJS and browser libraries in the same 'source tree'. The major pain-point is generated code, I guess. However, I bet we can work-around this, it's mostly a matter of writing API-compatible stubs and delegating to the 'right' one.

For whatever using platform-specific code (e.g. the current config using fs and such), maybe we should not inclulde those in @kubernetes-client/client-node (to be renamed to client-javascript?), but put it in either another package, or a sub-package to be imported (@kubernetes-client/client-javascript/node/index.js, @kubernetes-client-client-javascript/browser/index.js and such?). Or use rollup or similar to generate dist modules for both platforms, each including the 'right' implementation. When creating dist bundles, let's aim for ESM-style such that tree-shaking can work (currently the bundle is... quite big, even if you only use one of the API calls).

Finally, when writing 'custom' code, e.g. to implement watch, I'd suggest we stick on the side of what a browser provides and put NodeJS-style APIs on top. What I mean is: instead of letting the browser code depend on the stream module while we already have ReadableStream and such in the WHATWG streams spec, use the latter and transform to a NodeJS 'native' stream later, the rationale being to focus on size-reduction of the browser bundle, which is less of a concern in NodeJS.

[brendandburns]

Maybe we can extract out the node or browser specific stuff into separate things that we could have users dynamically require/import?

[NicolasT]

Maybe we can extract out the node or browser specific stuff into separate things that we could have users dynamically require/import?

To some extent, yes. However:

• In-browser, request isn't available so the code as generated today can't work.
• In NodeJS, fetch can be made available, but the fetch API doesn't support disabling TLS server certificate validation, which is currently supported by this lib.
• As in my PoC, we can stub request with an implementation using fetch underneath (and not support disabling TLS server certificate validation), but this puts requirements on the library consumer build environment (Webpack's alias feature, rollups alias plugin,...)

Other approach would be to generate two api.tss: one as today, one using the typescript-fetch 'language', then dispatch to the 'correct' one. However, this could again push customization to the library user's build system.

One thing we could do, is to generate two api.tss, and create two pre-built bundles in dist, instead of a whole lot of tsc-generated modules, one for NodeJS (using typescript/request), one for browser (using typescript-fetch/fetch, and a slightly different API for config), and dispatch in package.json to the right bundle.

However, since then we'd have a single module, we better publish things as an actual ES6 module, such that (especially in browser environments) tree-shaking can work.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[drubin]

/remove-lifecycle rotten

[dinfer]

any progress?