I’ve been looking into migrating from gateway to router and running into a few things that require an Enterprise plan. We currently customize the gateway with things like authN against auth0 to forward user context. In my research it seems like the way to do this would be a co-processor. Additionally we currently self host the gateway. It appears both of these features are Enterprise features, which is going to be impossible for us to get a budget for. We don’t want to be on an unsupported gateway going forward, and we do like Federation, but do we have a choice?
@Patrick_Hansen being in a similar position, my understanding is that if you want federation, can’t afford Enterprise and/or the router approach doesn’t support all your needs then you are effectively compelled to stick with a self-hosted gateway (non-router) solution. Furthermore if you want what used to be called managed federation there is no self-hosted option for that and you have to effectively roll your own using rover calls.
It is frustrating to have invested time and effort in the managed federation route and have a bunch of customized gateway features only to find that that option is no longer available under Apollo’s new plans, either because cost is prohibitive, or that the router approach currently can’t (easily, or at all) support (be it self-hosted or not) those features.
1 Like
Hi Patrick and Alan, I wanted to provide some information and options here for both of you.
One option you have available would be to create native rust plugins that would perform your JWT validation (or rolling your own registry using rover supergraph compose). This is very similar to how you built customizations for @apollo/gateway, but you would be managing that in Rust and compiling the apollo-router binary yourself. Nothing will change in the apollo-router plugin API because of coprocessors; coprocessors are actually implemented through a plugin we created for the apollo-router. We have seen others face challenges with this path, but ultimately, it comes down to your comfort/familiarity with Rust.
Router v1.12 release added the coprocessors feature to apollo-router which is currently an Enterprise feature, but we hope to bring this feature to our cloud plans in the future. Would co-processor support in GraphOS Serverless fit your use case? We’ve built co-processors into the stock router binary so they’re easy to customize in the YAML config. Ultimately, we want to bring the performance of Rust to the community without everyone having to develop in the Rust space. We do understand that there will be users that don’t want to go this route and will build their own binary of apollo-router. This is why we recently spent time on beefing up the Rust documentation available on crates.io (where Rust developers typically get their docs).
Would writing a Rust plugin not be an option for you? What friction or blockers do you have in that (i.e. my auth service doesn’t provide a Rust SDK)? We would love to understand each of your scenarios better so that we can improve the router. Feedback from the community has always been critical to Apollo projects and we’re hoping to learn more.
We’re always open to feedback and I appreciate you both raising these concerns. If there is anything I can do to help answer questions or point you in the right direction, please let me know.
1 Like
Hey Patrick,
I was in this situation a couple months ago. I have recently migrated to a self-hosted router by Cosmo, which supports fed v1 and v2.
Cost is much more manageable and I am free to self host the entire thing if I needed.