WASM build

[mfulton26]

Is your feature request related to a problem? Please describe.

I don't want to manage much infrastructure and I want to deploy Apollo Federation solutions to the edge.

Describe the solution you'd like

I want to be able to easily configure and deploy Apollo Router to web assembly supporting runtimes like Deno Deploy which supports WASM (so it should be able to run Rust code).

I'm not sure exactly how this would work and it's possibly that the overhead for transferring the request from JavaScript into the native code might negate any benefits. It would depend what parts are CPU intensive. Deciding where to send all the subgraph requests and/or merging the results could be delegated to WASM.

Describe alternatives you've considered

Using pure JS solutions like GraphQL Yoga or managing my own containers (e.g. AWS ECS) to run Apollo Router.

[smyrick]

@mfulton26 You may have some of the terminology confused here so let me try to add some more context.

A Federated supergraph is made up of 2 runtime component, the Apollo Router and Subgraphs.

The subgraphs are the components that define the GraphQL schema and contain the runtime resolvers that implement that schema. These subgraphs can be written in any language, include JavaScript with Apollo Server, and in theory can be deployed to Deno Deploy (I personally have not done this yet to test out the full capabilities of Deno Deploy but as long as you can send a HTTP request to an endpoint and have that responsed with JSON, it can be GraphQL compatible).

The Apollo Router is delivered and release as a pre-compiled binary or Docker images and so you can deploy this any infrastructure you can run Docker. To my knowledge, that is not Deno Deploy. It operates purely in running source code files for you in a sandboxed environment.

If you are looking for an easier deployment of Apollo Router, I recommend you checkout Apollo GraphOS Cloud. Apollo can run the router for you so you only have to deploy and manage subgraphs

[mfulton26]

thank you for the clarification!

as Apollo Router is built in Rust I was wondering if a WebAssembly (WASM) solution could be made in addition to the pre-compiled binary or Docker images; anywhere that runs WASM would then be able to run Apollo Router too (e.g. Deno, Bun, standalone WASM solutions, even in-browser… although I doubt you'd want Apollo Router client side 😄)

[smyrick]

Yep, that makes sense. I agree that I don't see many use cases today (that might change) for Router in the browser, however if we wanted to rebrand this issue as:

Provide a WASM build of Router

That would be easier to track than just "Deno Deploy Support". If you would like that could you update the title and initial comment on what is required for that to work on your end

[mfulton26]

Updated. Thank you.

[pmrotule]

@smyrick In our case, we would love to have a WASM build to make it possible to run the router in a Cloudflare Worker. Do you have any update?

[smyrick]

@pmrotule This is not something we have planned yet. Can you provide more context on your specific issues and why the current available binaries and Docker images do not support your use case?

[pmrotule]

@pmrotule This is not something we have planned yet. Can you provide more context on your specific issues and why the current available binaries and Docker images do not support your use case?

@smyrick Thanks for getting back to me. I'm happy to provide more context.

We are currently running the Apollo Router on our own infrastructure, but we would like to know if it would be possible to run it on a Cloudflare Worker since it supports Rust using WebAssembly. We can make the Hello-World example work, but the knowledge of Rust is pretty limited in our team so I'm not sure how to go further and integrate the router by compiling a custom router binary from source. Do we actually need a WASM specific build? Can the router run in a worker environment? Any guidance would be greatly appreciated 🙏

Regarding the reason why we want this, we simply want to increase performance: serving the request closer to the customer, but also because we would like to have a caching layer in front of some of our subgraphs and those caching layers would be running on Cloudflare Workers. If we're able to also have the router running on Cloudflare, it would mean we could render pages end-to-end from the edge.

[smyrick]

So after reading the docs and consulting some older conversations the team has already had around Cloudflare Workers, this is a much larger issue than just WASM support.

First CF Workers have a limit of 1MB for the free tier and 10MB for paid but the current 1.35.0 release is coming in around ~40MB for the stock binary, not including any extra libraries and code you have to add for CF support.

Also the CF Worker runtime, while supporting WAMS builds from Rust, does require you to use a specific interface and library that would have to intercept the HTTP requests that are currently handled by the Router runtime and tokio (which still needs WASI support).

Also, keep in mind the architectural performance gain you are looking for here. Moving services closers to users can speed up response times but if you are running in short-lived, memory constrained environments, that might have a more costly impact to Router than standard long-lived containers. We find that deploying Router with more memory and CPU is actually helpful to GraphQL execution.

Have you considered other platforms that allow you to deploy docker images closer to users like Fly.io, AWS Fargate?

[abernix]

I'll close this issue as it hasn't picked up a lot of traction and we're trying to clean up some old issues. This isn't anything we would prioritize in the near or mid term. Thanks!