Idk I built a production system and ensured all data transfers, client to server and server to client were proto buf and it was a pain.

Technically, it sounds really good but the actual act of managing it is hell. That or I need a lot of practice to use them, at that point shouldn't I just use JSON and get on with my life.

▲

barremian 3 hours ago | parent | next [-]

I think the it-just-works nature and human readability for debugging JSON cannot be overstated. Most people and projects are content to just use JSON even if protos offer some advantages, if not only to save time and resources.

Whether the team saves times in the longer when using protos is a question in its own.

▲

Arainach 5 hours ago | parent | prev [-]

What issues did you have? In my experience, most things that could be called painful with protobuf would be bigger pains with things like JSON.

Making changes to messages in a backwards-compatible way can be annoying, but JSON allowing you to shoot yourself in the foot will take more time and effort to fix when it's corrupting data in prod than protobuf giving you a compile error would.

	▲	written-beyond 5 hours ago \| parent [-]
		Well at the bare minimum setting up proto files and knowing where they live across many projects. If they live in their own project, making a single project be buildable with a git clone gets progressively more complex. You now need sub modules to pull in your protobuf definitions. You now also need the protobuf tool chain to be available in your environment you just cloned to. If that environment has the wrong version the build fails, it starts to get frustrating pretty fast. Compare that to json, yes I don't get versioning and a bunch of other fancy features but... I get to finish my work, build and test pretty quickly.