Comment by hsaliak | Hacker News Reader

Comment by hsaliak | Hacker News Reader

Parent Full thread

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.

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).

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.

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 [1] https://github.com/RSuter/NSwag

Switched to NSwag here, too. I'm in a Python environment and we use it to generate the TypeScript code for our services.

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 [2] https://github.com/OpenAPITools/openapi-generator/blob/maste... [3] https://twitter.com/oas_generator/status/1041939441109983232 [4] https://github.com/OpenAPITools/openapi-generator/projects/4

which IDL do you use? which codegen tools and for which languages?

also i think i'm missing something:

>which you don’t really need with json+REST anyways

why don't you need server stubs for json+REST?

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?

>CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.

Is there a possibility to make the gRPC contracts more universal, to play nicely with things like SignalR, websockets, etc. ?

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/

The best things about it is that you don't have to write the message schemas in advance, only the function signatures.

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.

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.

Looks interesting. How does this compare to RabbitMQ or MQTT?

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) 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.

Reply on news.ycombinator.com