We’re having a discussion where we wanted to provide a completely separate federated graph for authenticated clients and a completely separate federated graph for unauthenticated clients.
And if any services under authenticated graph needs to refer to the type defined on other graph, we’d duplicate the service and deploy under also the authenticated graph.
This is so that our gateway can validate JWTs and private graph would reject any requests that have invalid JWT or no JWTs.
And the other gateway can simply forward the request.
We’d still do permission checks using the directive on each subgraph.
I don’t know if I’m missing something here. Can someone verify if this is a good idea?
Sounds like a great use case for Schema contracts from Apollo. Let’s use annotate fields with the @tag directive in the subgraphs but then have separate gateways that expose specific fields that you included or excluded in the contract variant
Separating the federated graph for authenticated and unauthenticated clients can be a valid approach to enforce security and access control in your system. By doing this, you can ensure that only authorized users can access certain parts of your system, while also simplifying the authentication process.
Duplicating services and deploying them in both the authenticated and unauthenticated graphs can allow you to reuse code and reduce maintenance overhead. However, it’s important to keep in mind that this approach may increase the complexity of your system and require additional testing to ensure that changes made to one graph are also reflected in the other.
Using permissions checks on each subgraph can help ensure that users have the appropriate access to the resources they need. However, you may also want to consider other security measures, such as rate limiting, to prevent potential attacks or abuse of your system.
Overall, the decision to separate the federated graph for authenticated and unauthenticated clients will depend on your specific security requirements and system architecture. It’s a good idea to carefully evaluate the potential benefits and drawbacks before implementing this approach in your system.