MultiHub Forum

Full Version: Should we expose a GraphQL gateway for a legacy REST inventory service?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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?
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.
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.
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.
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.
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.
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.