7 ms·

I'm still not sold on gRPC vs JSON/REST. .proto offers me little over a decent development environment around JSON, and it seems to be pretty Google-specific.

• nprateem 8y ago
  Say "farewell" to Swagger, etc. and just generate your server & client libraries. I've found it to be far superior to JSON/REST, especially for microservices. Browser support was always the sticking point to wide adoption, so this is great news.
• Techonomicon 8y ago
  It allows you to define an interface wherein you can then simply generate clients and service libraries from that are typesafe.
• hsaliak 8y ago
  disclaimer: I work for the gRPC team. gRPC lets you use other data exchange formats or IDLs as well, such as flatbuffers. However, the protobuf codegen experience we have spent most of the time and energy on. I see two sides to this - on one hand, there are folks who want a 'contract first' development experience, in which the service contracts are defined first, and the business logic is implemented later. gRPC lends itself to this model very well. Admittedly, this is also the way services are developed in Google. On the other hand, there are folks who want a model whereby you evolve a service and generate the specs from that service. Currently, this is not the experience that gRPC is optimized for. Time and effort are the main barriers to making this work well alongside a contract-first experience. FWIW: I believe both models have merit and it really depends on what you want to adopt as the source of truth for how your services interact. Ideally, gRPC would be good at both.
  • yashap 8y ago
    IMO json+REST works just as well for contract first workflows. Just write up the contract in an IDL, have both sides agree on it up front, then use codegen tools to generate client SDK(s) for your client language(s) of choice. Same workflow as as with gRPC, though you’re probably less likely to get generated server stubs (which you don’t really need with json+REST anyways).
    • ben_jones 8y ago
      Could you recommend any codegen tools that generate bindings in Typescript or Go? I suppose there's some tools around swagger and various GraphQL libraries, but I'm not seeing any great options though a quick google search.
      • ThePadawan 8y ago
        I have made negative experience with using a custom swagger-codegen [0] template - the library is quite diffuse with no clear direction in which PRs are merged and which aren't, making it a mess to read and extend. I have however, managed to generate the exact Typescript bindings I wanted using it. In contrast, I have been using NSwag [1] to generate C# client code with far greater comfort, and it seems to support multiple Typescript clients already. [0] https://github.com/swagger-api/swagger-codegen https://github.com/swagger-api/swagger-codegen [1] https://github.com/RSuter/NSwag https://github.com/RSuter/NSwag
        • Brometheus 8y ago
          Switched to NSwag here, too. I'm in a Python environment and we use it to generate the TypeScript code for our services.
        • wing328hk 8y ago
          Sorry to hear your negative experience with Swagger Codegen regarding the PRs. Having been "managing" the project for a few years, I agree with you that I've not done a very good job in reviewing and merging all the PRs (239 open PRs as of today) contributed by the awesome community. Myself and 40+ top contributors have decided to fork Swagger Codegen so as to maintain a community-driven version called OpenAPI Generator [1] with a better governance structure to move the project forward. Now there are 10+ core team members and contributors with proper rights to merge PRs so I think we've better PR management in OpenAPI Generator. Please refer to the Q&A [2] for the reasons behind the fork. For TypeScript generators, we've recently added the TypeScript Axios client generator [3] and there's an ongoing project to consolidate the TypeScript generators into one [4]. Please check these out and let us know if you've any feedback. We hope you will find OpenAPI Generator useful in your projects. [1] https://openapi-generator.tech https://openapi-generator.tech [2] https://github.com/OpenAPITools/openapi-generator/blob/master/docs/qna.md https://github.com/OpenAPITools/openapi-generator/blob/maste... [3] https://twitter.com/oas_generator/status/1041939441109983232 https://twitter.com/oas_generator/status/1041939441109983232 [4] https://github.com/OpenAPITools/openapi-generator/projects/4 https://github.com/OpenAPITools/openapi-generator/projects/4
  • polskibus 8y ago
    What's the difference between CORBA and Protobuf with regard to IDL? I remember it was supposed to be the next big thing before SOA and webservices took over - I wonder what's different this time?
    • aaronblohowiak 8y ago
      >CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.
  • polskibus 8y ago
    Is there a possibility to make the gRPC contracts more universal, to play nicely with things like SignalR, websockets, etc. ?
    • sametmax 8y ago
      If you want RPC and PUB/SUB over Websocket, you have the "Web Application Messaging Protocol" standard, which has implementations for Python, JS (node and in browser), PHP, C# and Java. Checkout the main router, it's open source and handles a decent 6k msg/sec on a raspi: https://crossbar.io/ https://crossbar.io/ The best things about it is that you don't have to write the message schemas in advance, only the function signatures.
      • polskibus 8y ago
        Thanks a lot, I'm a bit worried about performance here, I wonder how does it compare against standard REST and SignalR in terms of number of active connections, performance, etc.
        • sametmax 8y ago
          The general rule of thumbs is that Websocket are cheaper if you want long connection with states to maintain (you only need to identify once) or have a lot of small messages. However, you have a low number of requests, or big requests, REST is going to be faster. But as usual, it depends of your implementation and your constraint. After all, facebook is using polling if I recall.
      • GordonS 8y ago
        Looks interesting. How does this compare to RabbitMQ or MQTT?
        • sametmax 8y ago
          It's a bit more performant than MQTT, but it eats more ressources (bandwidth and cpu). It's still practical for IoT (although I use it for the Web), as the C++ implementation (https://github.com/crossbario/autobahn-cpp https://github.com/crossbario/autobahn-cpp) targets embeded systems. However, it uses boost, so it won't fit in extrems memory requirements. All it all, if your configuration allows it, it's way, way easier and more flexible than MQTT to use. Combared to RabbitMQ, it's not as fast. You can't beat years of optimized Erlang and field testing by fortune 500. Yet, Rabbit MQ is very low level: you need to setup queues, and consumers, and if you need RPC with returned value you will add manual logic on top of it. Don't get me started if you want to load balance consummers. Real life AMQP is hard. Comparatively crossbar offers a great out of the box experience. All in all, I'd say the sweet spot for the tech is between the arduino/raspi and an average website/company micro service archi. If you have very small hardware, MQTT could fit in the tiny space, and if you have a 100 message highways interconnecting your data centers around the world, you may want AMQP. Between those, crossbar.io is great.
• philwelch 8y ago
  > .proto offers me little over a decent development environment around JSON If your development environment includes Swagger, programmatically generated HTTP clients and servers in multiple languages, built-in intelligent error handling, client-side and server-side type-checking of API requests and responses, gzipping your JSON over the wire, and if you exclusively write in languages like Python and JavaScript where protobuf doesn't serialize and deserialize any faster than JSON, then your development environment is honestly rather exceptional.
  • dnautics 8y ago
    Is serialization/deserialization often a service bottleneck?
    • philwelch 8y ago
      How often is often? It becomes more of an issue when you have more microservices because you might have multiple serialization/deserialization steps if you're calling a service that calls a service that calls a service, or if you're managing larger payloads.
    • cobookman 8y ago
      """ When using Protobuf on a non-compressed environment, the requests took 78% less time than the JSON requests. This shows that the binary format performed almost 5 times faster than the text format. And, when issuing these requests on a compressed environment, the difference was even bigger. Protobuf performed 6 times faster, taking only 25ms to handle requests that took 150ms on a JSON format. """ https://auth0.com/blog/beating-json-performance-with-protobuf/ https://auth0.com/blog/beating-json-performance-with-protobu...
      • dnautics 8y ago
        I suggest anyone who reads this comment read the linked article carefully. The difference is in a java-to-java scenario, and the specific task is retrieving 50k structured records. If your data to be transported is heterogeneous, or one of your endpoints is JavaScript, or if your requests are gates by something else, e.g. bandwidth, transport latency, endpoint raw compute, or human interaction, this dramatic difference may not necessarily apply.
• asdkhadsj 8y ago
  It's worth keeping in mind too that Protobuf isn't tied to gRPC. Conceptually simpler RPC libraries can exist. Twirp is a good example of this, imo
• ilovecaching 8y ago
  Pretty much every large well known tech company uses an IDL and binary format to exchange data between their very large number of services, so that says something about why this might be a critical piece of the puzzle over have ad-hoc interfaces and shoving JSON everywhere. JSON isn't a very efficient format to send and store data in, and it's a terrible IDL.
• endgame 8y ago
  I used to like .proto, but I found this article recently and it made me reconsider: http://reasonablypolymorphic.com/blog/protos-are-wrong/index.html http://reasonablypolymorphic.com/blog/protos-are-wrong/index...
  • sa46 8y ago
    You should really read the hacker news comments on that rather one-sided view of the topic. https://news.ycombinator.com/item?id=18188519 https://news.ycombinator.com/item?id=18188519
• spiralpolitik 8y ago
  If most of your communication is between two containers sitting inside a Kubernetes cluster then using GRPC is a no brainer as you get fast performance backed by a strongly typed interface definition language. No human is going to be looking at the traffic so using a binary format makes total sense. In my experience it's also faster to develop GRPC microservices as you spend less time dealing with Serialization and Deserialization. The only main downsides are the quirks of Protobuf but they are pretty easy to get used to. Combining with GraphQL you can get a pretty high performance microservice stack, especially if you develop your microservices in Go and use a GraphQL Gateway like Apollo to stitch the whole thing together.
• atombender 8y ago
  I've decided to go this way for now, at least for CRUD APIs: Frontend | | GraphQL | V Backend | | gRPC | V Microservice The situation with gRPC in the browser right now isn't ideal. Moreover, the client-side story -- interaction with React/Redux, client-side catching and prefetching, relationships and so on -- is nearly non-existent. GraphQL is better suited to how JS web apps work. In particular, GraphQL is designed to work with arbitrarily nested graphs of objects at dynamic levels of detail, in a way that makes caching, prefetching and so on fairly simple. And it speaks JSON fluently. gRPC's payloads are fixed, and if you want levels of detail ("fetch posts with creator"; "fetch posts without creator") you have to invent your own scheme for expressing this. gRPC also isn't particularly developer-friendly when it comes to implementing the client or the server. As with any language-agnostic RPC layer, the interfaces tend to be quite sharp-edged: For example, it's relatively awkward to write services that deal with heterogenous collections of objects ("oneof" fields are limited), and arbitrary structured — as opposed to schema-based that can be expressed with the Proto IDL — data (while there's the "well-known" type Value that can effectively express JSON data, it's easier just to wrap JSON in a proto string). GraphQL is much smoother to implement the client. Less so for the server, but it's all about graphs of objects, so it has the benefit that every server is essentially implemented the same way (the "verbs" are the same). GraphQL's introspection story is also better. gRPC has facilities for probing an API without having the schema at hand, but GraphQL arguably has better tools here for now.
  • pjmlp 8y ago
    > GraphQL is better suited to how JS web apps work. If the server side is also JS, because it is just a pain in anything else. I am yet to see a good reason to move away from the flexibility, and most relevant, the tooling of REST.
    • scaryclam 8y ago
      A few months ago I'd have agreed with you. However, I've recently created a couple of PoCs that changed my mind. The trick however, is to ignore how a lot of people seem to use GraphQL. Just treat it as another view layer that happens to come with schemas. Keep it as far away from your data layer as you can and it's a lot like working with regular old json and rest, with the added benefit of being able to request data in a more flexible manner.
• red-tea 8y ago
  > gRPC vs JSON/REST. gRPC is still REST.
• kureikain 8y ago
  gRPC is more than just a data protocol to me. Imagine writing JSON/Rest, you have to define end point/router, convert/encode data into JSON/text. With gRPC, all are done for you, the data is ready and pass to your function handler directly without you writing any glue code.