Should we expose a GraphQL gateway for a legacy REST inventory service?
#1
I'm redesigning the API for our e-commerce platform to improve mobile app performance, and we're considering a shift from REST to GraphQL. The front-end team is enthusiastic about the flexibility, but I'm concerned about the complexity it introduces for caching, rate limiting, and securing against malicious queries. We have a legacy inventory service that's still RESTful, and I'm unsure if stitching it into a GraphQL gateway is the right move or if we should maintain a hybrid approach. Has anyone managed a similar transition with a mixed backend?
Reply
#2
Great project. Start with a GraphQL gateway that translates queries to your existing REST inventory service. Keep the backend intact and migrate fields gradually so you don’t blow up your release cadence.
Reply
#3
In a recent hybrid setup we used federation to stitch multiple services and added persisted queries and gateway-level caching. We also cap query depth and total cost, and use batch loading (DataLoader-style) to avoid N+1 issues. It keeps performance predictable while you migrate.
Reply
#4
We took a staged approach: expose a small GraphQL surface that aggregates a handful of inventory fields, validate value, then expand. Use persisted queries (or a reliable APQ solution) to prevent ad-hoc queries from exploding load. Add rate limiting by query complexity and depth at the gateway, and keep a migration plan for the REST core.
Reply
#5
What stack are you on, and is the plan Node/GraphQL, or something else? Are you deploying via a cloud gateway, and do you have a target mobile latency? Sharing a bit about your current service map would help tailor concrete options.
Reply
#6
Be mindful of the classic pitfalls—N+1, over-fetch, and cache invalidation. Consider a DataLoader-like batching layer, differentiate caches for static vs dynamic fields, and keep a clear governance on schema ownership so you don’t end up in API debt as you scale.
Reply
#7
Security and ops matter a lot here: disable introspection in production, enforce depth and complexity limits, implement query whitelisting, and instrument logging so anomalous queries trigger alerts. Pilot with a few teams before broad rollout.
Reply


[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Forum Jump: