Hacker News Reader

Comment by tempest_ | Hacker News Reader

I like the idea of grpc because I wanted the contract but I tried it on a small service and I think I would avoid it in the future. Too many rough edges and features I didnt really need. I was using it in Rust and python mainly (maybe it is better in Go?) but it had a whole bunch of google stuff in there I didnt need.

- Configuring the python client with a json string that did not seem to have a documented schema

- Error types that were overly general in some ways and overly specific in other ways

- HAProxy couldn't easily health check the service

There were a few others that I cant remember because it was ~5 years ago. I liked the idea of the contract and protobuf seemed easy to write but had no need for client side dns load balancing and the like and was not working in GoLang.

View on HN

I think connect-rpc[0] strikes a good balance between normal http apis, and gRPC. It allows protobuf as json. So you could think of it as an opinionated http api spec. A health check would be just a call to an url /something.v1.MyService/MyMethod -d { "input": "something }.

it works really well, and the tooling is pretty good, though it isn't that widely supported yet. Rust for one doesn't have an implementation. But I've been using it at work, and we basically haven't had any issues with it (go and typescript).

But the good thing is that it can interoperate with normal grpc servers, etc. But that of course locks it into using the protobuf wireformat, which is part of the trouble ;)

0: https://connectrpc.com/

+1 for connect-rpc. After go-micro‘s maintainer went off the rails, I ripped it all out and switched to connect.

> After go-micro‘s maintainer went off the rails

What do you mean by this? Genuinely curious, as someone who's followed that project in the past.

He probably means when I took VC funding in 2019 and started to rip apart the framework to try build a platform and business. The 2-3 years after were very chaotic.

My goal was never to serve the community but instead leverage it to build a business. Ultimately that failed. The truth is it's very difficult to sustain open source. Go-micro was never the end goal. It was always a stepping stone to a platform e.g microservices PaaS. A lot of hard lessons learned along the way.

Now with Copilot and AI I'm able to go back and fix a lot of issues but nothing will fix trust with a community or the passage of time. People move on. It served a certain purpose at certain time.

Note: The company behind connect-rpc raised $100m but for more of a build system around protobuf as opposed to the rpc framework but this was my thinking as well. The ability to raise $10-20m would create the space to build the platform off the back of the success of the framework.

Obligatory "this is why I love HN" but even for that standard, this is is an incredibly open account, thank you for the insight and sorry it hasn't seemed to pan out quite how you hoped. Still sounds like you got your bag, built something cool, and have your "micro" share of Internet legacy, so not too bad eh?

Using connectrpc was a pretty refreshing experience for me. Implementing a client for the HTTP stuff at least is pretty easy! I was able to implement a basic runner for forgejo using the protobuf spec for the runner + libcurl within a few days.

I've only enjoyed using Protobuf + gRPC after we've started using https://buf.build. Before that it was always a pain with Makefiles building obscure commands, then developers having different versions of the Protobuf compiler installed and all kinds of paper cuts like that.

Now it's just "buf generate", every developer has the exact same settings defined in the repo and on the frontend side we are just importing the generated Typescript client and have all the types instantly available there. Also nice to have a hosted documentation to link people to.

My experience is mostly with Go, Python and TS.

buf.build sounds interesting as a middle ground for using protos without going all-in on the Bazel build ecosystem.

> - Configuring the python client with a json string that did not seem to have a documented schema

I'm far from an expert, yet I came to believe that what you've described is basically "code smell". And the smell probably comes from seemingly innocuous things like enum's.

And you wondered if the solution was using Go, but no, it isn't. I was actually Go at the time myself (this was a few years ago, and I used Twirp instead of Protobuf) - but I realised that RDBMS > "Server(Go)" layer had quirks, and then the "Server(Go)" > "API(JS)" had other quirks -- and so I realised that you may as well "splat" out every attribute/relationship. Because ultimately, that's the problem...

Eg: is it a null field, or undefined, or empty, or false, or [], or {}? ...

[] == my valentines day inbox. :P

Reply on news.ycombinator.com