Wow totally meaningless performance tests. What did you measure exactly? How did you measure it? Basically you might as well have produced random numbers as you don't say what you tested.
Hi! Thank you for your feedback! We are creating the short videos so we can’t explain everything. But we will discuss your comment for our future videos! Thank you!
I don't know about you, but I often choose for an IoT project the simplest and cheapest hardware able to do the job, that is a good philosophy. Keep it simple, no overkills. Sometimes that can be an ATMega board hooked to an ESP-01, a STM32 MCU with built in board connectivity, or even an ESP32 board. I will always use the cheapest and simplest board I can get await with. More than that is overkill, like a Raspberry Pi for instance. Other coding language working on a higher level than C is also overkill, unless libraries that you *MUST* make use of demand so. That being said, REST is the king here, due to its minimalistic and simplistic approaches to communication. It also supports several forms of authentication, and you can fiddle around with the best one for your scenario, that is (due to the nature of IoT constrictions and restrictions)usually the simplest and less resource intensive one that wouldn't of course compromise security. Its also difficult to imagine how things like gRPC and GraphQL would have a smaller implementation footprint than REST in such restricted devices.
Very good one. Another good question: GRPC vs AMQP RPC, costs of implementation(specially if you already have AMQP in use for other stuff in your infrastructure), and performance.
Perhaps a combination of the two? REST for minimal data that needs to be transported, and any large sets of data using gRPC, isn't that supposed to be the beauty of microservices?
Great point! A combination of REST and gRPC can indeed be a powerful approach. REST works well for simpler, lightweight data transfers and broader compatibility, while gRPC shines with performance when dealing with larger datasets or requiring high efficiency in communication between microservices. Leveraging both plays to their strengths and aligns perfectly with the flexibility and scalability that microservices architecture offers!
Consider I just need a simple CRUD and a few actions for my own business and there is no importance how hard is implementing each one of REST or gRPC. Can I choose gRPC just for getting experienced in it, and I can hope will not face any problem that wouldn't happen with REST?
If you're looking to get hands-on experience with gRPC, it's definitely a great choice for learning, even for a simple CRUD application! However, keep in mind that gRPC has a steeper learning curve and might require more setup, especially around things like HTTP/2, protocol buffers, and client libraries. That said, for a small-scale project, you shouldn’t run into any significant problems that wouldn’t happen with REST - just be aware that REST might be more straightforward for basic CRUD operations due to its wide adoption and simplicity. If you're comfortable with the extra setup, go for gRPC and enjoy the learning
as new to industry I take Rest API because it's stable. we tried GraphQL but it didn't fix the problem infact it only introduce extra work to the backend. I will just adjust to graphql , grpc, trpc etc etc incase the Job requires to. But what can you suggest
