Support Running Project via WebAssembly (WASM) in the Browser

[tusharmath]

Problem
Developers are required to download and install our product to test configurations and experience its features. This might deter potential users from trying out the product due to the initial setup overhead.

Proposed Solution
Convert our project to run in the browser using JavaScript, by compiling it to WebAssembly (WASM) and then interfacing with JS. This will serve as the foundation for future integrations, such as embedding it into a web-based playground.

Additional Context
By enabling our project to run in the browser through JavaScript:

• Final integration would be on https://tailcall.run/playground

[tusharmath]

/bounty $150

[algora-pbc]

💎 $150 bounty created by tusharmath
🙋 If you'd like to work on this issue, comment below to get assigned
👉 To claim this bounty, submit a pull request that includes the text /claim #381 somewhere in its body
📝 Before proceeding, please make sure you can receive payouts in your country
💵 Payment arrives in your account 2-5 days after the bounty is rewarded
💯 You keep 100% of the bounty award
🙏 Thank you for contributing to tailcallhq/tailcall!
🙋‍♂️ Join our discord channel if you need help.

[ologbonowiwi]

This issue is to support WASM build only or it's needed to serve the solution under /playground?

[tusharmath]

In this issue we don't need to integrate it into the UI. We just need to build the ability to perform this operation.

[ologbonowiwi]

/attempt #381

Tokio doesn't support WASM, as seen on tokio-rs/tokio#1597. They're trying to use WebAssembly System Interface (WASI) over WASM.

Probably, this blocks the issue from a resolution, right @tusharmath?

Options

• Cancel my attempt

[algora-pbc]

Note: The user @bharattech is already attempting to complete issue #381 and claim the bounty. If you attempt to complete the same issue, there is a chance that @bharattech will complete the issue first, and be awarded the bounty. We recommend discussing with @bharattech and potentially collaborating on the same solution versus creating an alternate solution.

[tusharmath]

@ologbonowiwi We might need to make it run using something like https://docs.rs/gloo-net/latest/gloo_net/

Basically move the http calls to the JS Realm.

[ologbonowiwi]

I can be wrong but gloo_net looks like a library to make requests than provide a server; likely we'll need to replace tokio packages (tokio itself and mio are the ones that I saw throwing compiling errors) by packages that run a server on WASM

[ologbonowiwi]

Can you describe the experience you expect to provide under the /playground route?

I am trying to understand here to see what options we have

[ilyvion]

I don't know if it's necessarily the solution, but a library like MSW lets you capture HTTP requests made by the browser and mock responses instead of letting them go through; maybe the same mechanism can be utilized here?

[tusharmath]

@ologbonowiwi If you checkout our quick start guide you will see that one needs to install Tailcall locally to play around with it. This is a major impedance for people to try out the proxy server.

We wanted an experience, where people can just run the server for their configuration within a few seconds on the browser itself. That way they will be able to get a feel of the software before installing anything locally.

Actual Experience:

• Use clicks on the playground link /playground, a window shows up where they enter their graphql configuration.
• Simultaneously we load a graphiql which points to this tailcal server, which is running on the browser.
• The graphiql allows the user to send graphql request to the tailcall wasm server running in the browser, however, the server makes real http calls upstream to orchestrate data from different sources and send back a graphql response.

We don't need to do all of that in this PR though. Our goal is to figure out a way to make sure that we can run the tailcall server on the browser and interact with it using JS. The UI and the UX around it like I explained above will be resolved later.

I hope this make sense.

[ologbonowiwi]

Yeah, it makes sense, @tusharmath.

This experience that you're describing it'd be incredible! But I think compiling to WASM is the cheapest way (saying in terms of infra) to provide this experience. Still, we have the trade-off that it'll require rewriting the core of tailcall to remove Tokio packages and find an I/O alternative compatible with WASM.

Rather than do so, what if we run tailcall in an actual server and open a port to set it up a server via HTTP requests?

So when I go to the /playground, I upload (or paste) my graphql config, and this would POST https://tail-server.free-tier-somewhere.com/setup-server, and this would generate a https://tail-server.free-tier-somewhere.com/uuid/user-url-expectation where the graphql server it'll be up.

It's possible to achieve this by having a simple server with tailcall installed locally, and when a request comes, what the server does is run tailcall <server-setup-command>.

It likely provides an experience compatible with HTTP rather than the browser; it’d be more straightforward than removing all Tokio packages and finding WASM alternatives (when compiling to WASM).

Let me know if you see this as a nice way to provide the experience that you expect on /playground route.

[xmlking]

This could be a great feature to run BFF in the browser. There will be always special need to run BFF in edge closer to users or close to upstream data sources.
I saw some demos showcasing how to run SQLite in the browser via webassembly for local-first apps

[tusharmath]

@ologbonowiwi, you've raised a valid point. Let me outline a potential solution:

1. Endpoint Creation: Introduce a /playground-api endpoint.

   • The UI sends both a Query and Config to this endpoint.
   • Upon receipt, the server evaluates the Config, returning validation errors if present.
   • Without errors, the server processes the query using the /playground-api route.

2. Application Separation: Rather than integrating the /playground-api endpoint into tailcall, it could exist as a standalone application designated for demo purposes.

3. Internal Architecture: At its core, this could be a simple Rust-based web server. It would leverage Tailcall library functions for resolutions.

While this is a preliminary proposal, it ensures that users can experience our product without the installation hassle. If you're interested in spearheading the elaboration of this plan, I'd be thrilled to collaborate!

On another note, the inclusion of WASM significantly broadens our horizons. As @xmlking pointed out, browser execution is an enticing proposition for many firms reluctant to oversee GraphQL infrastructure. Moreover, this approach facilitates our product's deployment on diverse platforms, including Mobile (Android, iOS, PWA) and edge platforms such as Cloudflare Workers and Fermyon.

Strategically, our objective is to embrace various WASM platforms. This adaptability could revolutionize perceptions of our product. However, for this specific use case, perhaps deploying a dynamic server for Tailcall would suffice.