Forty minutes into the scoping call, the vendor recommended gRPC. Nobody had asked yet what the API would carry, how many external clients would consume it, or whether a single engineer on the client’s team had written a proto file before. The recommendation arrived before the requirements did. Everyone nodded, because it sounded like the fast option, and fast is the only adjective most people have for a protocol.
That happens because protocol choice is the most visible decision in an API project and the least reversible one. Swap your database later and you migrate data. Swap your protocol later and you migrate every client that ever integrated with you, including the two you’ve lost the contact details for. The blast radius isn’t your codebase. It’s your customers’ codebases.
The engineering internet will tell you REST is dated, GraphQL is elegant and gRPC is fast. One of those is a matter of taste, one is a matter of tooling, and the third falls apart the moment somebody measures it against nested data. We’ll get to the measurement, because it’s the most useful thing in this article and almost nobody publishes it.
Empyreal Infotech has delivered API development services since 2011, and the protocol question resolves the same way nearly every time: match the protocol to the payload shape and the consumer, not to the trend. REST for public surfaces, GraphQL where the client drives the query, gRPC for internal traffic between services you own. Everything below is how you prove which case you’re in.
What Do API Development Services Decide That You Cannot Undo?
API development services cover contract design, endpoint or schema implementation, authentication, rate limiting, versioning policy, documentation and client SDKs. Empyreal Infotech treats exactly one of those as structural: the protocol and the contract it implies. Everything else can be changed in a sprint without telling anybody. The contract can’t be changed without telling everybody.
Sort the work into two piles and the whole engagement gets easier to price. In the reversible pile: your auth provider, your rate limits, your pagination defaults, your error message copy, your hosting region, even your language and framework. Teams change these constantly and nobody outside the building notices. In the irreversible pile there’s one item, and it’s the shape of the contract you published.
Consider what a reversal actually costs. A logistics platform with eleven integration partners decided eighteen months in that its REST API should have been GraphQL. The rebuild itself was nine weeks. Getting eleven partners to schedule their own engineering time to migrate took fourteen months, and two of them never did, so the old endpoints are still running today alongside the new ones. The technical work was the small half.
This is also why the protocol conversation can’t be separated from the architecture your API sits on. A protocol is a surface. If the services behind it are tangled, no protocol rescues them, and choosing an API architecture on aesthetics while the structure underneath is undecided is how teams end up paying twice.
What Is the Difference Between REST, GraphQL, and gRPC?
REST exposes resources over HTTP, one address per resource, returning whatever the server decides to send. GraphQL exposes a single endpoint and lets the client specify exactly which fields it wants. gRPC exposes typed remote procedure calls over HTTP/2 using binary Protocol Buffers. Three protocols, three different original problems.
REST solved interoperability. It works with every HTTP client written since 1999, caches at any HTTP intermediary once you set Cache-Control, ETag and Vary properly, and can be debugged by anyone with a browser. Its cost is over-fetching and under-fetching: the mobile app that needs three fields receives forty, and the screen that needs data from four resources makes four round trips. Sparse fieldsets and compound documents take most of the sting out of that, and contract-first design with an OpenAPI specification at least makes the cost visible before you ship.
GraphQL solved exactly that problem and introduced its own. One endpoint, one query, precisely the fields requested. In exchange you inherit resolver complexity, the N+1 query problem, and a caching story you have to design deliberately, because the default POST endpoint sits outside HTTP caching until you move queries to GET with persisted documents. gRPC solved something different again: throughput between services. Protocol Buffers serialise to compact binary, HTTP/2 multiplexes many calls over one connection, and code generation gives both sides a typed client. The trade is that a browser can’t call it directly and your existing HTTP tooling can’t read it.
Adoption matters more than elegance when you’re hiring. Postman’s 2025 State of the API Report, drawn from more than 5,700 developers, architects and executives, put REST at 93%, Webhooks at 50%, WebSockets at 35% and GraphQL at 33%, with 82% of organisations having adopted some level of API-first practice. Those shares overlap, because most teams run more than one. What they really forecast is your hiring pool, and you will always be able to find someone who has shipped a REST API.
REST vs GraphQL vs gRPC: Where the Speed Advantage Comes From
On flat payloads gRPC measured roughly 4.8 times faster than REST. On nested payloads under concurrent load that gap collapses, and at 100 requests REST edged ahead. Much of the headline advantage came from gRPC running over HTTP/2 while REST ran over HTTP/1.1, which is a transport difference rather than a law of protocols.
Those numbers come from a 2024 study by Niswar and colleagues in the International Journal of Electronics and Telecommunications, which measured all three protocols against identical microservices. Read the whole paper rather than the headline, because it ran two different tests and they tell slightly different stories. Peer-reviewed measurement of all three on one rig is rare, and most vendor comparisons carry no numbers at all.
One API Protocol Comparison, Two Test Methods, Two Answers
Average response times and CPU usage, with the test method attached to each:
- Concurrent, flat data, 100 requests: gRPC 233.84ms, REST 1,113.33ms, GraphQL 3,852.07ms. gRPC wins by 4.8 times.
- Concurrent, nested data, 100 requests: REST 5,201.39ms, gRPC 5,667.33ms. REST edges ahead and the advantage vanishes.
- Concurrent, nested data, 500 requests: gRPC 14,962.61ms, REST 16,646.55ms. gRPC leads again, by 1.1 times rather than 4.8.
- Sustained load, nested data: gRPC led at every level, returning in 437.03ms against REST at 510.47ms for 100 requests.
- CPU on flat data: REST 10.26% to 48.90%, gRPC 10.95% to 36.11%, GraphQL 120.09% to 142.15%.
Read the last line twice. GraphQL crossed 100% CPU usage at low load, meaning it consumed more than a full core to serve flat data that REST handled on a tenth of one. GraphQL’s flexibility is not free, and it isn’t paid for in latency. It’s paid for on your hosting bill, every month, forever.
Two caveats the authors would want stated. Their overall conclusion is that gRPC is the fastest of the three, and the sustained-load test supports it. But in the concurrent test REST and GraphQL ran over HTTP/1.1 while gRPC ran over HTTP/2, and the authors attribute much of the gap to that transport difference rather than to the protocol. Run REST over HTTP/2 and the comparison narrows.
The practical instruction is short. Before anyone quotes you a protocol, take a real response from your product, note whether it’s flat or deeply nested, and ask the vendor to justify the recommendation against that shape and that transport. If they can’t tell you which of those two tests your traffic resembles, they haven’t opened your API.
Which API Architecture Is Best for Microservices, and Why Do Most Teams Run Two?
For service-to-service traffic inside a network you control, gRPC is usually the best API protocol for microservices: typed contracts, compact payloads, and streaming built in. For anything a third party consumes, REST. Most mature systems run both, with a gateway translating at the boundary. Running two protocols is not indecision. It is matching each one to the traffic it was built for.
gRPC is no longer an exotic choice internally. The CNCF Annual Cloud Native Survey published in January 2026 put gRPC in production use at 44% of respondents on that question, from a base of 395 to 502 of the 628 people who completed the survey, all screened as familiar with cloud native technologies. That population is the point rather than a footnote: these are teams already deep in the cloud native stack, not developers at large. Set beside Postman’s 93% for REST, the split tells you where each protocol belongs. gRPC lives inside the building. REST answers the door.
GraphQL earns its place in the third position, between your clients and your services, as a backend for frontend. When four client applications each need a different slice of the same six services, a GraphQL layer stops you building four bespoke aggregation endpoints and maintaining them forever. This is the shape that suits the SaaS platform your API serves, where a web app, a mobile app, an admin console and a partner portal all want the same entities at different depths.
So the reference architecture most teams converge on has three layers rather than one winner. gRPC handles internal calls between services, including bidirectional streaming where it’s needed. REST sits at the public edge, versioned and cacheable, for partners and integrations. GraphQL sits at the client edge when, and only when, more than two client applications need genuinely different projections of the same data. One protocol for all three jobs is a constraint nobody imposed on you.
If you run one service and one client, none of this applies to you. Build REST, ship it, revisit in a year. A microservices API protocol debate for a monolith with a single web front end is a way of feeling architectural rather than being it.
How Much Do API Development Services Cost Over Three Years?
Empyreal Infotech prices API development services in four bands, from £6,000 for a single-service REST API to £90,000 for a full platform API with versioning, gateway and published SDKs. Running costs add roughly 10 to 20% of the build price every year. The honest three-year number is about half again the quote, and closer to double once versioning and observability are properly staffed.
Those bands assume an hourly rate of £20 to £35, and the spread inside each one is driven by integration count rather than endpoint count. Six endpoints stitched across four third-party services with inconsistent error handling costs more than twenty endpoints over a schema you own. When a quote varies wildly between vendors, that variance is almost always a difference in how much of your existing mess they’ve actually looked at.
Four Build Bands, and What Each One Costs to Run
Build price first, then the annual run cost that nobody puts in the proposal:
- Single-service REST API with an OpenAPI spec, auth and docs: £6,000 to £12,000 ($7,500 to $15,000), four to seven weeks, £900 to £1,800 a year to run.
- GraphQL layer over existing services, with resolver design and caching: £12,000 to £25,000 ($15,000 to $31,000), eight to twelve weeks, £1,800 to £3,800 a year including the extra compute.
- gRPC internal mesh with a REST edge and a translating gateway: £20,000 to £45,000 ($25,000 to $56,000), twelve to eighteen weeks, £3,000 to £6,800 a year.
- Full platform API with versioning, gateway, observability and published client SDKs: £45,000 to £90,000 ($56,000 to $112,000), twenty to thirty weeks, £6,800 to £13,500 a year.
Run the arithmetic on the second band and the pattern shows itself. A £20,000 GraphQL build at £3,000 a year is £29,000 across three years, and that’s before the compute overhead the benchmark predicts. The same product served by a £10,000 REST API at £1,500 a year lands at £14,500. The cheapest protocol to build is frequently not the cheapest one to keep, and the gap compounds quietly in a line item nobody reviews.
Three API Costs That Never Reach the Quote
Three costs are absent from almost every API proposal: versioning governance, observability, and the salary premium for protocol-specific engineers. Together they routinely add 40% to the three-year total. The same Postman survey found 60% of teams version their APIs while only 26% use semantic versioning, which is where most breaking-change incidents actually begin.
Each protocol handles change in a fundamentally different way, and nobody explains this before you sign. REST versions in the URI or a header, so v1 and v2 coexist and you carry both until the last client moves. GraphQL is designed to avoid versions: you add fields rather than replace them, mark the old ones deprecated, and use field-level usage data to see exactly which clients still select them. Large platforms version anyway when they need a hard break, which is why Shopify ships dated GraphQL versions on a quarterly cadence. Protocol Buffers gives you a reserved declaration for retired field numbers, the safest of the three change models, provided an engineer remembers to write it every time a field is deleted, because nothing enforces it for you.
Observability is the cost that shows up as on-call burden rather than a bill. gRPC’s binary frames are opaque to ordinary HTTP tooling, so the debugging techniques your team already has stop working on day one. GraphQL’s single endpoint breaks the per-route metrics and per-endpoint rate limits your team already has. You can get the granularity back, but only by instrumenting for it: tag by operation name, adopt persisted queries, and rate limit on query cost rather than request count. That is a fortnight of work nobody quoted for.
Why gRPC Talent Costs More Than REST Talent
What the staffing reality looks like once the build is handed over:
- Ramp-up time: a competent REST engineer needs two to four weeks to become productive in GraphQL, and six to ten in gRPC with Protocol Buffers.
- Hiring pool: REST is in use at 93% of teams against GraphQL’s 33%, so far more engineers have shipped one than the other. Treat that as direction, not a ratio.
- Bus factor: schema and proto files concentrate knowledge in one or two people far more than REST controllers do.
- Tooling spend: schema registries, codegen pipelines and gateway licences are line items REST projects rarely carry at all.
- Debugging tax: every incident on a binary protocol takes longer to diagnose, and incidents are priced in engineer-hours whether you budget for them or not.
None of this argues against GraphQL or gRPC. It argues against choosing either one without pricing the decade after launch. Ask the uncomfortable question before you sign: who maintains this in year three, and can we hire them?
Payload shape already settled? Then the build conversation is a short one, and you can put it to our team whenever you like. If it isn’t settled, the migration sequence below matters more than any quote.
Run Both, Then Retire One: Migrating Without a Cutover Weekend
Migrating between API protocols should never involve a cutover weekend. Put a gateway in front of the existing API, add the new protocol behind it for one low-traffic endpoint, run both in parallel while real clients move at their own pace, and retire the old surface only when its traffic reaches zero. Expect this to take quarters, not weeks.
The pattern is the strangler fig, and it works because it never asks every client to move on the same day. Pick the endpoint with the least traffic and the most forgiving consumer. Implement it in the new protocol behind the same gateway. Route a small share of traffic to it, compare responses against the old path in production, and only widen once the two agree. Then take the next endpoint. Teams usually discover this on their second migration, having learned it expensively on their first.
Write the rollback criteria before the first endpoint moves, because nobody writes them calmly at 2am. Ours are simple: if error rates on the migrated endpoint exceed the old path by more than half a percent, or p95 latency regresses by more than 20%, traffic goes back and the endpoint gets re-examined rather than re-explained. A migration that takes three quarters and breaks nothing is cheaper than one that takes six weeks and breaks a partner integration.
One honest warning about dual-running: it costs more while it lasts. You’re paying for two surfaces, two sets of tests and two things to monitor, sometimes for a year. That’s the premium for not taking your customers offline, and it’s almost always worth paying.
Inside a Custom API Development Company: How Empyreal Infotech Decides
Empyreal Infotech works as a custom API development company the same way on every engagement: the protocol is chosen last, not first. We start with the payload shape, the consumer list and the change frequency, then let those three facts pick the protocol. If a vendor names a protocol on the first call, they are describing their last project, not yours.
In practice that means week one is discovery rather than code. We take a real response from your product and measure whether it’s flat or nested. We count the consumers and split them into ones you control and ones you don’t. We ask how often the contract has changed in the last year, because a contract that changes monthly rules out anything with expensive versioning. Only then do we write the contract, in OpenAPI or Protocol Buffers, and only then do we quote. Empyreal Infotech’s API development services cover the rest of it: OAuth 2.0 or API key auth, JWTs where a self-contained token fits, mTLS where services talk to each other, rate limiting, the versioning policy, and the client SDKs your integrators will actually use.
The API Projects We Turn Down, and Why
We say no to two kinds of API work, and both cost us money. The first is the team that has already chosen gRPC before we’ve seen a payload. If the decision is fixed and the data is deeply nested, we’d be taking a fee to build something the measurements say will underperform, and we’d rather lose the project than deliver that. The second is the single-service product with one web client asking for a GraphQL layer. That’s a £14,000 answer to a £6,000 question, and the honest recommendation is a REST API and a conversation in eighteen months.
A partner who agrees with your protocol choice before examining your data is agreeing with your budget, not your architecture. If you want a straight read before you commit anywhere, you can talk to our team about your API and get the payload shape measured first.
Frequently Asked Questions About API Development Services
When should you use gRPC instead of REST?
Use gRPC when the traffic is internal, the payloads are flat, the volume is high, and both sides of the call are services you control. It measures roughly 4.8 times faster than REST on flat data at 100 concurrent requests. Choose REST instead whenever a browser, a partner, or any client outside your network needs to consume the API directly.
GraphQL vs gRPC: which is better for internal service to service calls?
gRPC, in almost every case. It was designed for service-to-service traffic, uses binary Protocol Buffers over HTTP/2, and generates typed clients for both ends. GraphQL was designed for the opposite situation, where a client needs to shape its own query. Using GraphQL between two services you control adds resolver overhead and CPU cost to solve a problem those services don’t have.
How much do custom API development services cost?
Empyreal Infotech’s API development services run from £6,000 to £12,000 for a single-service REST API, £12,000 to £25,000 for a GraphQL layer, £20,000 to £45,000 for a gRPC mesh with a REST edge, and £45,000 to £90,000 for a full platform API. Add roughly 10 to 20% of the build price annually to run it. Integration count drives the price more than endpoint count.
How do you choose an API development company you will not have to replace?
Ask four questions on the first call. Which protocol do you recommend and what in our data made you say that? What does this cost to run in year three? Who owns the contract and the SDKs if we leave? Tell us about an API you shipped that needed rewriting. Anyone can answer the first three. Watch what happens during the fourth.
Can REST, GraphQL, and gRPC run in the same system?
Yes, and most mature platforms do. The common arrangement runs gRPC between internal services, REST at the public edge for partners and integrations, and a GraphQL layer in front of the clients when several applications need different projections of the same data. A gateway translates at each boundary. Running one protocol everywhere is a constraint nobody actually imposed on you.
Choosing an API Architecture You Will Not Rebuild in Two Years
Return to that scoping call, where the protocol arrived before the requirements did. Choosing an API architecture well takes three facts and about an hour: the shape of a real payload, the list of who consumes it, and how often the contract has changed. Empyreal Infotech has never needed more than that to make the call, and no vendor should need less.
The defaults are unglamorous and they hold up. REST at the edge because you can always hire for it and clients can always reach it. gRPC inside, where the payloads are flat and you own both ends. GraphQL only when several different clients genuinely need different slices, and only once you’ve priced the CPU. Anything more ambitious than that needs a reason you can say out loud.
Bring one real response payload and your consumer list to a free 30-minute API review with Empyreal Infotech. Thirty minutes, no charge, and you leave knowing which protocol your data is asking for. If that turns out to be the REST API you already run, we will tell you that instead.
Measure the payload. Count the consumers. Then choose.