We want to use Tyk as an API gateway for a number of different microservices.
There is a use case for mobile devices where GraphQL would be preferable to REST for that segment only. I have read about the Universal Data Graph function in Tyk.
My question is - is it possible to have a GraphQL endpoint that maps the underlying REST API microservices for mobile whilst also routing traditional REST requests without GraphQL for, say, web clients? Or is the transition through UDG a one-time thing - so everything has to consume GraphQL once you implement it?
Use UDG to expose services as a graph, but keep the underlying services in place for other clients. It’s worth talking to one of the Tyk Architects to walk through what would be involved, shouldn’t take more than 40mins to deep dive into it and validate the best approach for your use cases.
DM me if you’d like me to set that up, or just go via the contact form.
To add to @James’s answer, we are currently implementing a new feature will expose persistent graphql as REST endpoints. This is actually built to support the exact use case you described while allowing you to do the aggregation that UDG offers
The feature should be part of our 4.3 release last I checked but I will let @agata-wit expand my answer and correct me if I am wrong on when this will be released!
I can look to see if we have some RC containers that this feature can be tested on if you’re interested
Just as James and Zaid already pointed out, for this particular use case (REST-to-GraphQL) Universal Data Graph will be perfect. It’s a lightweight solution that allows you to integrate your microservices BUT it also allows you to turn a single REST API into a GQL API for your consumers in case they prefer to pull data from graph.
So with a single REST API you can run two services with Tyk - proxy REST as is and then do all the API management in the gateway, while at the same time using that proxy as a data source for your graph and have a GQL layer on top. Two different services for consumers, single backend in your architecture. It’s pretty neat.
Zaid is right, we are releasing a feature at the end on November that will allow you to “RESTify” GQL queries. Essentially you will be able to “hide” any GQL query under REST endpoint and allow your consumers only limited access to your graph.
This usually makes sense in production, gives you a bit more control over your graph and tends to save you from someone attacking your graph with a deeply nested query or some other vulnerabilities GQL might be susceptible to.
Reach out anytime if you want to know more or need help with configs!
Hi @James . I was hoping that we could set up a call to discuss my requirements for our API Gateway project. Could you please propose a time this week that would be convenient for you? Thanks very much.
Hi @agata-wit - I was hoping to arrange a call to discuss our requirements for an API Gateway in more detail, and to see how Tyk can meet our needs. Would it be possible to set up a meeting sometime this week please? We are based in the United Kingdom. Let me know please. Thanks.
I think by now someone has reached out to you via other channels - I’m guessing either James or Shane. I’ll follow up with them and make sure they send me an invite as well.
