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

Why doesn't the SDK run in the web browser? #79

Open
jwulf opened this issue Mar 21, 2024 · 3 comments
Open

Why doesn't the SDK run in the web browser? #79

jwulf opened this issue Mar 21, 2024 · 3 comments
Labels
seeking-feedback We're looking for feedback on a feature or proposal.

Comments

@jwulf
Copy link
Member

jwulf commented Mar 21, 2024

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.

@jwulf jwulf added the seeking-feedback We're looking for feedback on a feature or proposal. label Mar 28, 2024
@hassan-alnator
Copy link
Contributor

hassan-alnator commented Apr 17, 2024

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
Copy link
Member Author

jwulf commented May 9, 2024

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
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
seeking-feedback We're looking for feedback on a feature or proposal.
Projects
Status: 🆕 Inbox
Development

No branches or pull requests

2 participants