gRPC vs REST vs GraphQL: Comparison & Performance
Вставка
- Опубліковано 6 лют 2025
- gRPC vs REST vs GraphQL Performance Benchmark.
🔴 To support my channel, I'd like to offer Mentorship/On-the-Job Support/Consulting (me@antonputra.com)
🍿 Benchmarks: • New Benchmarks
👋 AWS is expensive - Infra Support Fund: buymeacoffee.c...
▬▬▬▬▬ Experience & Location 💼 ▬▬▬▬▬
► I’m a Senior Software Engineer at Juniper Networks (13+ years of experience)
► Located in San Francisco Bay Area, CA (US citizen)
▬▬▬▬▬▬ Connect with me 👋 ▬▬▬▬▬▬
► LinkedIn: / anton-putra
► Twitter/X: / antonvputra
► Instagram: / aputrabay
► GitHub: github.com/ant...
► Email: me@antonputra.com
▬▬▬▬▬▬▬ Source Code 📚 ▬▬▬▬▬▬▬
► Original Source Code: github.com/ant...
#python #golang #nodejs
🔴 To support my channel, I'd like to offer Mentorship/On-the-Job Support/Consulting (me@antonputra.com)
🍿 Benchmarks: ua-cam.com/play/PLiMWaCMwGJXmcDLvMQeORJ-j_jayKaLVn.html&si=p-UOaVM_6_SFx52H
👋 AWS is expensive - Infra Support Fund: buymeacoffee.com/antonputra
Can u do video about postures vs sylladb
Thanks!
Additional advantage of gRPC is you define model once in protobuf format and then you can generate clients for different languages, maintaining such model is much less error prone than JSON
@deprecated
So does GraphQL. But the clients gRPC generates aren't even fully type safe, and generally gRPC is pretty basic compared to GQL.
I like that I don't even need to do that with JSON though. I can just define my controllers and use OpenAPI (previously Swagger) to generate my client and even my documentation.
@@Smaylik03well you saw what happened to graphql right ?
Can you explain what you mean?
So for 99% apps none of these will be a bottleneck
That's like the case for literally every benchmark and framework, it won't matter. These only matter for high load clusters at enterprise level. Most people can just get away with Python, Django and REST, instead of fighting over what's good and what's not and struggling to get more than 10 users despite everything.
@@raptorate2872 python can't handle even that without latency being noticeable to user.
I cannot thank you enough for conducting and publishing these tests. It really shines a light on what’s real when it comes to performance.
please don't take these videos as actual benchmarks. These are not actual production tests, and there are lots of dependencies that come in play here. The implementation and the language you use, as well as the configurations you have, will drastically change every single output of this test. Do your own research and use a proper tool for the job not a UA-cam video show casing these tests.
this channel is a hidden gem!
thank you for making these kinds of comparison videos, it gives a lot of insight to the performance and overhead used by these technologies!
Why you don't use persisted queries in graphql?
Looks like your application spends a lot of time parsing GQL query, you can reduce it down to zero with this feature.
This is exactly why such performance comparisons are BS. Choosing your API layer based on the graphs in this video is stupid. Instead, pick the tool which is right for the job. Don't use a screwdriver for nails. Don't use a hammer for screws.
@@pavelzagrebelin3092 submit a PR or open a ticket in Issue Queue for the channel’s tutorial GitHub repo. That mode is valid for additional comparison.
For microservices - gRPC
For the open api - REST
For lovers latte with soy milk - GraphQL
Thanks for adding the different audio tracks. I can't tell if it is machine-produced voice or a real person, but it sounds great to a native speaker. (tho in Spanish it pronounced gRPC as jRPC, not really a problem).
Спасибо Антон! Полезные цифры❤
Next do gRPC vs Cap’n Proto vs MessagePack please!
This - and also do correlated requests - most requests in real world uses aren't isolated, which is what graphql and CapnProto are optimised for.
Impressive! Do you have tutorial on how to setup and perform this kind of load testing + monitoring?
Many would be interested.
@@kimlehtinen the test files and configs are all contained and available in the channel’s GitHub tutorial repository linked in the bio.
Great video and insights, thanks for making this
Great content as always, you should create a paid course, at this point i'm sure a lot of people will love it, doing the process step by step, it would be a huge success
you're joking right? rest, graphql and grpc are api standards. you can't compare performance between them, only to compare their implementation.
Hi, thanks for this video! I would love to see a video about Gleam vs Golang
Thanks for the benchmark!
Would be nice to show the queries you're doing before start. A lot of benchmarks are based on very simple tasks, that don't show real picture.
I'm not a big fan of GraphQL, but in this case, where you send gql for very simple reason, it might be a big overhead. But try to perform some joins. While REST / RPC requires multiple queries, GraphQL only calls once and return multiple collections in a single response. So, how would it affect performance in this case?
hi @anton
what programming language did you use and which libraries were used to run this test. this depends a lot on the choice of tools and libraries used.
thanks
the source code is in the description
love your content
Any plans to test tRPC?
Great video! Which tool did you use to measure these metrics?
Can you tell us more about the GraphQL server that was used?
impressive, well benchmark
Which tool you are using here? and could you please write some testing tool name whci has this kind of nice graph and dashboard presentation?
Wow, I didn't expect GraphQL is ~2x times slower (rps) comparatively to REST
Thanks Anton
What were these apis doing ?
Need to understand the conditions for this experiment ?
How can you benchmark 3 specifications? I like your other videos but this one doesn’t make sense. Performance is highly dependent on the implementation
Had the same thought. It really depends on what is used in the backend. We don't know anything to make a conclusion. Which language, which framework, which library was used and then what does the code serve behind the endpoint etc.
@@blubblurb he shared the rust clients as usual bro
all rust using tokio
Excellent in many ways.
Easy W for gRPC. Please test the flatbuffers-based gRPC next!
So why the gRPC and HTTP latency flipped? why its happening behind the scene?
Thx dude
Always recreate the wheel to finally do the same thing for at least 30 years... send a few data as input and get an answer from remote 😂
GET part of this isn't fair for GraphQL. You get what you ask, but you ask it all so the framework implementation goes for nothing. Still, if you had a scenario that requires including some additional data from the database but you don't know which clients are going to ask for it, GraphQL would make difference. Of course you can ask for clients to filter for it but you need to handle it yourself with REST or gRPC. Overall, GraphQL provides a good standard and can perform better than REST in some cases but those cases needs to setted up first.
This is such a bullshit. Sorry, but do not do this comparison. What is the code behind? Because every technology has its use case. If you compare only simple requests, then it does not say anything. For example normally something what you have to do by 3 or 4 requests with REST is done with 1 request with GraphQL.
You are completely missing the point of these technologies. So - fix it. Do some coding, create use cases and benchmark it again. There are cases where rest is better, where gRPC is better and also where GraphQL is better. Use the right tool for the right thing! That is a part of development. Not blindly select one technology based on bad usage/comparison!
This is such a bullshit. Github links are always there and author always open to PRs, but you are so dumb.
Why would REST need more queries? Just add an endpoint that does all you need in single query.
@@AllanSavolainen the point of GraphQL is that you can specify what you can provide and don't have to add an endpoint for each different target use case. - and if you write a public API you can't know what will be wanted, and GraphQL introspection provides a great way to quickly determine what an API can provide.
@@JariNestel I know, which is why I wont allow devs to use it. Same reason why devs should not be allowed to write SQL queries. It is all just a big security hole or way to steal data.
Better to just have verified endpoints that give access to only things that are allowed, and same with databases, only allow data access via stored procedures that DB developers write, no custom SQL for backend or frontend devs.
@@AllanSavolainen You never know if you have more endpoints, what user wants to get.
For example - you have endpoints for person, address, order, company.
Will you create all possible combinations like you suggest, or will you add just 4 (lets imagine, for the sake of simplicity, that endpoint returns data for one company, person, address,...) different endpoints and let user to decide what they need?
Normally you would create 4 endpoints, but in your case you would need to create 4 * 3 * 2 endpoints - that is too much work...
Why do you recommend REST for interaction between two web apps and not gRPC?
Cool but if your app is getting 25k req/s and you're running it on a single machine you're headed for disaster anyway
Most apps will get 100req/s max, don't fool yourself this doesn't matter for 99% of apps
Build simple first, then optimize
It would be nice to have a comparison between different serialization formats. For instance Apache Avro is the defacto standard when it comes to schema registry scenarios. So I'd be interested in seeing Avro vs Protobuf vs CapNProto vs MessagePack
I don't get it, why mobile you recommend gRPC and webaplications REST?
might as well just whisper. I can't hear anything
hi are you from indonesia ?
hi, anton, could you compare the zookeeper and etcd get and set performance, thanks
Would you please do a one on one comparison between mysql and mongo dB as I am getting mixed responses from the Internet
Both are specialized for 2 different use cases, MySQL is a Relational Database and Mongo DB is a Document Database. Just choose the right one for your use case.
You should make a data serialisation comparison with gRPC/Protobuf, Avro and Thrift.
What we can conclude here is under 20k req/sec use what you prefer, between 20 and 50k req/sec use REST and above use grpc 😊 This conclusion must be adapted to the application environment.
Is there any chance to test QUIC/HTTP/3 vs gRPC/HTTP/2? I think next gen protocol is amazing and should be introduced to at least service-to-service communications.
HTTP/3 itself doesn’t have much of an advantage for service-to-service. It might even be a bit slower than HTTP/2. Raw QUIC however might have benefits, eliminating HoL blocking of TCP and with 0.5 RTT for TLS. Even then, for persistent connections, RTT is not a problem. Base HTTP/1 tends to have lower latency than 2 or 3 with TLS.
What are the frameworks you used in the benchmarks? Is there a github repo containing the web server setups? In this case what does REST mean? Is it an API Platform kind of framework or a single hard coded SELECT statement? I know it's the boring part of the video many people skip but (imo) this is a bit meaningless without this crucial piece of info.
Nevertheless, thank you for your dedication.
If I can vouch for any next topic it would be around Symfony (+API Platform?), frankenPHP, swoole, Laravel, and why not Spring boot!
it's in the description y'all like to talk a lot
@@GreatTaiwan Yes my bad, I completely missed it. I would have loved a very quick intro to the tech in the video.. or did I miss it too ;) ? Anyway thank you
So where should we use graphql 😅
Whats your testing tool?
He makes a bunch of vps's in aws. He has a monitoring one with EKS set up. A few for the test and usually about double that to generate load. He goes through it in some more detail in other videos. The dashboard you see is just a live grafana feed.
I'd like to see this kind of network serialization & deserialization with a zero-copy deserialization protocol. I have used Rust's rkyv crate.
in which language are your implementations?
servers are in go, clients in rust github.com/antonputra/tutorials/tree/main/lessons/240
And what about msgp?
Thx!
It is insane that GraphQL does 30k req/s. That's over two billion requests per day.
gg!
Compare gleam to rust to go PLEASE
Really interested how new programming language innovated
Have you used deflate with rest? I’d like to see if binary protocols have any advantages data transfer wise if you apply deflate.
Additionally it would be interesting to see how Apache thrift compares. Several big tech companies I worked for used thrift and I wonder why all of them are so consistent in this regard.
But why is GraphQL even present?
REST assured I will go with REST. Its simple.
I liked a lot about the video, however, this comparison is not "fair" Anton, I will explain my point of view, gRPC is working over layer 4 in reason of RPC. GraphQL and Rest are running both on layer 7 with their on serializarion strategy to be fair I would suggest comparing the REST layer with deferents serializerers for exemple Protobuf, Thrift, Avro, Apache Fury...
EDIT1:
- After a revision, I've read remembered that all are running over layer 7, my bad @auton.
this is like saying that comparing Python to Go server is not "fair" - to me that's the whole point of these videos. To see the actual differences
@@Qrzychu92 to say it straight - REST is not even from RPC family and have nothing to do with it.
gRPC is a layer 7 protocol built on top of HTTP/2 (also layer 7).
gRPC is using Protobuf. And Thrift is equivalent to gRPC. Also, both are L7…
@Qrzychu92, @s.i.m.c.a, @JulianMiller780, @LtdJorge - in a straightforward answer there are several diferences where we can have to add into this benchmark to be to create a direction about the "goal" of this is specific test, and, whenever we compare a language with other in the propose of collect "who will handle in the most effective way with real case throughput?" it's make totally sense, for example, if we compare Golang with Rust in the same way as it was made, Golang always will lose in reason of the garbage collector , however, the point that I see in this test is what the serialization framework is more "effective".
Do the test in rust. Go is pretty terrible with json - the built-in json lib is horrendous.
Наглядно, спасибо
Нормально нормально, андестент юю бро
But the point of graphql is to reduce no of req right ?
Yes, exactly, cause you can query more details for a listing in the same request and don't have to request every object separately.
g-rpc si clearly the winner but... only with machine-2-machine scenarios... at least atm (beginning of 2025). It's not possible to directly call a gRPC service from a browser, sadly
Using hundreds of libraries for a performance-comparison that boils down to 2 lines of network traffic - i'd bet that the performance of all 3 implementations is not really based on the underlying concept but the docents of unknown implementations involved.
Kafka with zookeper VS Kafka with KRaft
I use simple hono rpc. So good performance with type safety. I love it.
That has nothing to do with to grpc
@MrDevianceh yeah I know, I just love the type safety it provides and the rest api speed.
@@arytiwa4351 rest api speed? this comment makes no sense bro
@@GreatTaiwan yes the speed is better than graphql although behind grpc. I am not comparing rest with grpc but telling about the type safety I get and the speed. Mana ging all that in gql in tough.
make go grpc vs go connect-rpc vs go twirp
So when should be GraphQL used? Never? 😂
“But can it run Crysis?!” 🤓
haha what is that
13 And no man hath ascended up to heaven, but he that came down from heaven, even the Son of man which is in heaven.
14 And as Moses lifted up the serpent in the wilderness, even so must the Son of man be lifted up:
15 That whosoever believeth in him should not perish, but have eternal life.
16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.
17 For God sent not his Son into the world to condemn the world; but that the world through him might be saved.
18 He that believeth on him is not condemned: but he that believeth not is condemned already, because he hath not believed in the name of the only begotten Son of God.
19 And this is the condemnation, that light is come into the world, and men loved darkness rather than light, because their deeds were evil.
20 For every one that doeth evil hateth the light, neither cometh to the light, lest his deeds should be reproved.
21 But he that doeth truth cometh to the light, that his deeds may be made manifest, that they are wrought in God.
(Jn.3:13-21)
явно русскоговорящий тип делает канал на английском, зачем ?
I thought this is Indonesian youtube Your name like Indonesian. Maybe one of your parent is.
hmm.. I am willing to suffer the performance loss for the nice things I get with graphql. imagine having to write a complex rest api, with filtiers, filters on relational models, pagination, and it all being able to select only the fields it wants. And on top of all, you can use the schema to generate all the frontend queries and mutations.
even if it was 10 times slower, would still use it.
of course, for server to server communication, REST or grpc is fine
"even if it was 10 times slower, would still use it."
Well - if your application has that little requirements then sure.
@ we use graphql for the client facing frontend, with cahcing. We had rest beforehand, and I did some benchmarks for the same result. There is basically 0 difference. That being said. Our rest api returned much more data. Our graphql api just fetches the things you actually request.
From this, we can conclude that GraphQL is shit and no one should be using it.
GraphQL == 💩💩
Which serialisation method you are using?