Enable Camunda 8 SDK in the browser

[jwulf]

Here are the things that need to be dealt with:

• The web browser does not support gRPC
• Web browsers cannot easily support custom SSL certificates
• Secrets cannot be secured in the browser

These three mean that the web browser environment requires distinct strategies from the server-side environment.

Creating and maintaining differential strategies for the two environments (client- and server-side) is a significant engineering effort.

[hassan-alnator]

What are the use cases we are trying to cover here ? I see that the taskList already uses the REST API with got.

I think something like grpc-web would be the start , or basically using basic Http with protocol bridging

Browser Out : grpc_http1_bridge filter which allows gRPC requests to be sent to Envoy over HTTP/1.1. Envoy then translates the requests to HTTP/2 or HTTP/3 for transport to the target server. The response is translated back to HTTP/1.1. When installed, the bridge filter gathers per RPC statistics in addition to the standard array of global HTTP statistics.

Browser In : connect_grpc_bridge filter which allows Connect requests to be sent to Envoy. Envoy then translates the requests to gRPC to be sent to the upstream. The response is converted back into the Connect protocol to be sent back to the downstream. HTTP/1.1 requests will be upgraded to HTTP/2 or HTTP/3 when needed.

Another suggestion with like you said requires significant engineering effort but might be more native is chaining EventSource and Fetch together to replicate the same functionality.

Just thinking loudly 😄

[jwulf]

Full REST support for Zeebe is coming.

The only parts that won't work are the OAuth token caching to disk, and loading TLS certs from disk.

The hydration of the OAuth component with a client Id and client secret is via environment at the moment. Or it can be explicit in code, which leaves the responsibility for managing those secrets with the application.

But we would have to take the file system out of the loop for the browser env.

I think that supporting gRPC in the browser is out of scope - because the upcoming REST API will supersede it and reduce the complexity.

[hassan-alnator]

@jwulf i understand but I think we should have something like @camunda8/sdk-web where it can be used on the web and with frameworks like react and is completely rest based , as the main issue is supporting the browser more than GRPC itself , everyone at the end wants to build a user interface that gets controlled by a BPMN process.

[jwulf]

With the Camunda8RestClient in 8.6, we should be able to support the SDK in the browser.

Here are some things that will need to be managed to have this work:

• Tree-shaking to remove all the code except for the Camunda8RestClient.
• Isolate file-caching of tokens
• Isolate code to support custom SSL cert chains
• Mechanism to supply credentials for OAuth flow

[jwulf]

I am splitting out the new Camunda 8 API client to its own @camunda8/isomorphic-sdk package.

I'm going to try doing here as a monorepo.

[hassan-alnator]

Hi Josh , I recommend using https://turbo.build/ for this , it helps a lot with the structure and generating packages , also parallel execution performance is excellent giving the team a great developer experience . Cheers

…

On Sep 26, 2024, at 2:47 AM, Josh Wulf ***@***.***> wrote: I am splitting out the new Camunda 8 API client to its own @camunda8/isomorphic-sdk package. I'm going to try doing here as a monorepo. — Reply to this email directly, view it on GitHub <#79 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABH7A4DJ5FIC5Y6ZY5HFL7TZYONVLAVCNFSM6AAAAABFCHCTM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZWGA3TCMRYGE>. You are receiving this because you commented.

[jwulf]

It's looking like making a dual CJS/ESM build is the way to go here.

Or: make it ESM and do a breaking change release.