Yes, and I was lucky enough to read his stuff on finance within 6 months of starting work! He has some very good design ideas for many things, just as always treat it like things in your toolbox and not dogma.
I agree, but also our accountants kept asking for the craziest of things. I guess its a problem that the real world of transactions is full of async processes and weirdness. There is always something new weird that will happen, so it always ends up back in a spreadsheet software.
Well, only in python is that N/A value also a float. In protobuf, go or Java for that matter, that data model must somehow be changed to communicate the difference.
If you had use 3 float values in Go or Java you would have had the same problem.
In the case for Lat/Lon, I guess that 0.0 could have a meaning, though it is very unlikely someone is exactly at lat/lon 0.0. An alternative is to translate to the XY coordinate system, though that is not a perfect solution either.
If you really feel like expressing that LatLon as possibly null, it should rather be:
I think your anecdote is rather weak with regards to the way protobuf works, but to entertain, why would a confidence of 0.0 be so different from None? 0.0 sounds very close to None for most numerical purposes if you ask me.
This, 100%. I am never going back to stringly typed JSON in whatever random url structure that team felt like doing that week. GraphQL is made for Facebook type graph problems. Its way overcomplicated for most use cases. I just want a lingua franca DSL to enforce my API specification in a consistent manner. I dont care if its PUT POST PATCH. Just keep it easy to automate tooling.
This is the true design issue with gRPC as I see it. It would be way bigger without this. I love protobuf though, gRPC is just alright. At least gRPC makes it so much simpler to build powerful automation and tooling around it than the wild west of randomly created 'json'-ish REST-ish APIs.
I dont even care about the performance. I just want some way to version my messages that is backward and forwards compatible and can be delivered in all the languages we use in production. I have tried to consume json over websockets before and its always a hassle with the evolution of the data format. Just version it in protobuf and push the bytes over websocket if you have a choice. Also, load balancing web socket services can be a bitch. Just rolling out our web socket service would disconnect 500k clients in 60 seconds if we didnt make huge amounts of work.
Some of the details inside protobuf in Java can be very convoluted, but they are also the result of intense benchmarking, years of experiences and a long tail with deep legacy support for old java.
Honestly I found the Java bindings to be way better designed and thought out than Golang. On a consumer level, the immutable message builders are fantastic, the one-ofs are decent compared to what Java can offer, and the service bindings actually provide a beautiful abstraction with their 0-1-many model. In Golang, if you only have to deal with Unary rpc they are OK I guess, but I really miss the immutable messages.
I had the same experience. It was a bit awkward for 6 months, but down the line we learned to design better apis, and dealing with nullable values are tedious at best. Its just easier knowing that a string or integer will _never_ cause a nullpointer.
Like nearly every time, empty string and 0 for integers can be treated the same as "no value" if you think about it. Are you sending data or sending opinions? Usually to force a choice, you would make a enum or a one-of where the zero-value means the client has forgotten to set it and it can be modelled as a api error. Whether the value was actually on the wire or not is not really that important.
It was a little weird at first, but if you just read the 1.5 pages of why protobuf decided to work like this it made perfect sense to me. It will seem over complicated though to web developers who are used to being able to update all their clients at a whim at any moment.
Yeah, the feature bloat makes it a hurdle to make some good quality implementations. I mostly stayed in Java for years. They are quite good. grpc-web is ok I guess, protobuf-ts are great, swift came along as nice, then I have always been saddened by how awful they are in Go. You will get terrible enums, terrible one-ofs, the interceptors and service registration are very awkward.
.NET looks quite good, as well as Swift actually. I have most experience with Java, and those are almost as nice as the .NET bindings. I have also used Go quite a bit, and they are pretty much awful. It takes so much practice and knowledge to use them well in Go.
As someone in a very small company, no affiliation with any Google employees, gRPC and protobuf has been a godsend in many, many ways. My only complaint is that protoc is cumbersome af to use, and that is almost solved by buf.build. Except for our most used language, Java.
Protobufs has allowed us to version, build and deliver native language bindings for a multitude of languages and platforms in a tiny team for years now, without a single fault. We have the power to refactor and design our platform and apis in a way that we never had before. We love it.
TestContainers, or just assume there is a postgres running locally.
> - maintain this, eg have good, representative testing data lying around?
This can be tricky, but usually my advice is to never even being trying to do write seed data in the database unless its very static. It just gets annoying to maintain and will often break. Try to work out a clean way to setup state in your tests using code, and do not rely on magic auto increment ids. Some of the more effective ways I have found is to f.ex. have every test create a fresh customer, then the test does work on that customer. Avoid tests assuming that the first object you create will get id == 1, makes it very annoying to maintain.
This 100%. Really the only reason to work at a startup as an engineer is if you really want to, because everyone pays low and the tiny bit of equity is essentially worthless in 99% of cases, which gives it a very low value.
Interesting enough, but this misses most of the point. In any case, its not really that interesting if the value you looked for is missing or not, its way more important that I can see _which_ value was not found. Any solution that does not capture which value was missing, is kind of besides the point for most practical applications.
suing sounds very extreme, but as someone who has worked on a similar service, unofficial clients are actually pretty annoying to deal with. They often end up using ancient APIs, dodgy secrets handling, we don't know what trackers they use, they do not follow our policies for usage that our official clients do. But they create a secondary community and some actually work surprisingly well for what they try to do.
JWTs has been both overhyped and overused, by myself as well. But after working with JWT authentication for so long, it felt very strange to go back to sessions stored in a database. Suddenly every service we have needs a db connection setup to go verify the sessions. No more stateless and authenticated services. But I still agree JWTs have been overused. One of the things I have used it for that I found the most useful is probably just storing some smaller pieces of signed state during parts of a data transfer, like just bridging between two systems or in-and-out of a browser without needing to setup a database.