GraphQL and REST are two approaches to designing HTTP APIs. REST uses fixed endpoints returning fixed shapes; GraphQL exposes a schema and lets clients.
GraphQL and REST are both HTTP-based API paradigms with strong opinions and passionate advocates. REST (or more accurately, resource-oriented HTTP APIs) exposes fixed endpoints that return fixed response shapes. GraphQL exposes a single endpoint with a typed schema, letting clients specify exactly which fields they want. Neither is universally better; the choice depends on how diverse your clients are, how frequently your data model evolves, and how much complexity your team can absorb.
(1) Multi-client backends — mobile apps, web apps, and third parties all want different subsets of the same data. GraphQL lets each ask for what it needs without proliferating endpoints (getUserForMobile, getUserForWeb, getUserForDashboard). (2) Aggressive client teams — GraphQL empowers frontend teams to iterate without backend changes for every new screen. (3) Rapidly evolving schemas — adding fields is non-breaking by definition; clients only see what they query. Facebook, GitHub, Shopify all use GraphQL for these reasons. If two or three of these apply, GraphQL likely pays for itself.
(1) Public APIs for third-party developers — REST's simplicity, HTTP semantics, cacheability, and universal tooling make it easier to adopt. (2) Small teams — GraphQL's schema, resolvers, dataloader, and query complexity limits add real engineering surface. Under 5 backend engineers, REST is usually the higher-productivity choice. (3) File uploads and streaming — awkward in GraphQL, natural in REST. (4) Simple CRUD — GraphQL's power is wasted when the API is 'list resource, get resource, create resource' with one client. Stripe, Twilio, and every popular payment/messaging API remain REST for these reasons.
GraphQL's biggest operational trap: a nested query that looks simple ('list users with their orders and each order's items') can generate hundreds of database queries under naive resolver implementations. The industry-standard fix is DataLoader (Facebook's library, now available for every language) which batches and caches within a request. Any GraphQL implementation without DataLoader-style batching will hit performance walls; treat batched loading as non-optional infrastructure, not an optimization.
GraphQL's flexibility means a client can construct queries that request millions of nested records with one request. Public GraphQL APIs need query complexity analysis (assign cost points to fields, reject queries above threshold), depth limits (max nesting level), and rate limiting based on computed cost not just request count. GitHub's public GraphQL API uses a points-based quota system that's worth studying. REST APIs get this defense mostly for free because endpoints have bounded work; GraphQL forces you to build it explicitly.
Many mature systems run both: GraphQL for the primary web/mobile experience, REST for public APIs and webhook payloads. This mirrors GitHub's architecture. Alternatively, gRPC or tRPC for internal service-to-service communication, REST for external, GraphQL for the client experience. Choosing one paradigm for everything is often ideological; matching the paradigm to the consumer produces better systems even if it means maintaining two API layers.
Investor directory · Fundraising library · Articles A–Z · Company funding database