cbor-java VS pronto

What's the pros and cons of this versus CBOR, which we had great success with in our system.

https://cbor.io

CBOR (Concise Binary Object Representation) is a codec for small JSON object, similar to MessagePack but in the internet standard.

JSON is a simple key=value pair representation. If you want to implement it by your hand with the same set of features (maps, lists, character escaping) then you will get something really similar. They are binary alternatives like https://cbor.io/ , but they are not popular for same reasons we use human readable representation of data for any other use case in programming

CBOR

Maybe this? http://cbor.io/ Haven't used it personally but I've read good things about it and the documentation makes sense.

go-cose is the Go implementation of COSE. COSE is a signing and encryption format based on the Concise Binary Object Representation format (CBOR). While inspired by the needs of the IoT community including fast processing on low-memory devices, the format is broadly applicable from small devices to large-scale server environments. COSE has incorporated lessons learned from Javascript Object Signing and Encryption (JOSE) efforts including JSON Web Signature (JWS) and JSON Web Token (JWT).

Have a look at cbor, https://cbor.io/ It's very compact and works wonderfully for embedded devices. Works identical to Json but than for binary data.

You could also look into CBOR serialization format. It's less readable but it's much more efficient than JSON.

5. Message streaming (gRPC streams are amazing)

I can think of a whole host of features that can be built off of protos (I've even built ORMs off of protobuffs for simple things [0]). The value prop is there IMO. HTTP + json APIs are a local minima. The biggest concerns "I want to be able to view the data that is being sent back and forth" is a tooling consideration (curl ... isn't showing you the voltages from the physical layer, it is decoded). Buff is building that tooling.

[0] - https://github.com/CaperAi/pronto

I've written translation layers for such systems and it's not too bad. See this project from $job - 1: https://github.com/CaperAi/pronto

It allowed us to have a single model for storage in the DB, for sending between services, and syncing to edge devices.

There's no reason you couldn't use gRPC with json as a serialized message format. For example grpc-gateway [0] provides a very effective way of mapping a gRPC concept to HTTP/JSON. The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. While it may be correct to say "parsing json is fast enough" it's important to note that there's a "for most use cases" after that. Parsing protos is fast enough for even more use cases. You also get streams which are amazing for APIs where you have to sync some large amounts of data (listing large collections from a DB for example) across two services.

With gRPC you also have a standardized middleware API that is implemented for "all" languages. The concepts cleanly map across multiple languages and types are mostly solved for you.

Adding to that you can easily define some conventions for a proto and make amazing libraries for your team. At a previous job I made this: https://github.com/CaperAi/pronto/

Made it super easy to prototype multiple services as if you mock a service backed by memory we could plop it into a DB with zero effort.

I think this "gRPC vs X" method of thinking isn't appropriate here because protos are more like a Object.prototype in JavaScript. They're a template for what you're sending. If you have the Message you want to send you can serialize that to JSON or read from JSON or XML or another propriety format and automatically get a host of cool features (pretty printing, serialization to text/binary, sending over the network, etc).

[0] - https://github.com/grpc-ecosystem/grpc-gateway

I attempted to make something similar to this except the opposite direction at a previous job. It was called Pronto: https://github.com/CaperAi/pronto/

It allowed us to store and query Protos into MongoDB. It wasn't perfect (lots of issues) but the idea was rather than specifying custom models for all of our DB logic in our Java code we could write a proto and automatically and code could import that proto and read/write it into the database. This made building tooling to debug issues very easy and make it very simple to hide a DB behind a gRPC API.

The tool automated the boring stuff. I wish I could have extended this to have you define a service in a .proto and "compile" that into an ORM DAO-like thing automatically so you never need to worry about manually wiring that stuff ever again.