3 ms·

They both exist for a reason. JSON is really nice for your quick proof-of-concept where you have relatively few developers working on a small system. Up to a po

by jlouis 7y ago

They both exist for a reason. JSON is really nice for your quick proof-of-concept where you have relatively few developers working on a small system. Up to a point, this also scales well. On the other hand, if you have many developers, and the problem space starts converging toward scale, then certainly the problem space is different. Encoding of data cannot follow the language with the weakest type zoo, and efficiency starts to matter. The hard part is to know when to make the switch, or when to anticipate growth in advance, such that you pick the right tool for the job. It isn't just a question of the machine. For complex messaging, the added value of a well-defined message typing, provided by protobuf, will help. It will also remove a lot of problems if you have multiple different languages in the stack, talking to each other.

wil421 7y ago
Once you hit the wall with JSON what format do you use? At a past job we were stuck using SOAP/XML middleware. We hit walls but I’m not sure if a different format would work. We ended up rate limiting lower priority traffic to get past our issues.
- q3k 7y ago
  Protobuf/gRPC.
- juliusmusseau 7y ago
  CSV. Just kidding, but I suspect it would be a lot faster.
parliament32 7y ago
>JSON is really nice for your quick proof-of-concept where you have relatively few developers working on a small system. This is really, really bad thinking and will always cause you a timebomb that will 100% explode on you in the long run. "just a quick POC" will always end up being the actual product, and once you start down this path you end up with "let's just use mongo, it's schema-less, it'll be faster for devs and we can use a proper db later"... "let's just use nodejs for the POC, all the devs already know JS so it'll be great"... a few years later you end up with some gargantuan monstrosity that nobody wants to maintain, your "quick" language/db-du-jour is dead and unmaintained, you're EOL on four different software fronts and you now get to explain to the bosses why you need to rewrite the last four years of dev work.

by jlouis 7y ago

wil421 7y ago

Once you hit the wall with JSON what format do you use? At a past job we were stuck using SOAP/XML middleware. We hit walls but I’m not sure if a different format would work. We ended up rate limiting lower priority traffic to get past our issues.

q3k 7y ago
Protobuf/gRPC.
juliusmusseau 7y ago
CSV. Just kidding, but I suspect it would be a lot faster.

parliament32 7y ago

>JSON is really nice for your quick proof-of-concept where you have relatively few developers working on a small system. This is really, really bad thinking and will always cause you a timebomb that will 100% explode on you in the long run. "just a quick POC" will always end up being the actual product, and once you start down this path you end up with "let's just use mongo, it's schema-less, it'll be faster for devs and we can use a proper db later"... "let's just use nodejs for the POC, all the devs already know JS so it'll be great"... a few years later you end up with some gargantuan monstrosity that nobody wants to maintain, your "quick" language/db-du-jour is dead and unmaintained, you're EOL on four different software fronts and you now get to explain to the bosses why you need to rewrite the last four years of dev work.