Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I stopped using JSON for my APIs

aloisdeniel.com

Post reply on HN
Print view View original

51–60 of 245 posts

Re: Why I stopped using JSON for my APIs

#51

Post by zzo38computer »

morshu9001 wrote: post #46
zzo38computer wrote: post #42

Earlier quoted context omitted.

it is not necessary to use or to implement all of the data types and other features of ASN.1; you can implement only the features that you are using. Since DER uses the same framing for all data types, it is possible to skip past any fields that you do not care about (although in some cases you will still need to check its type, to determine whether or not an optional field is present; fortunately the type can be che…

Yes but I don't want to worry about what parts of the spec are implemented on each end. If you removed all the unnecessary stuff and formed a new standard, it'd basically be protobuf.

I do not agree. Which parts are necessary depends on the application; there is not one good way to do for everyone (and Protobuf is too limited). You will need to implement the parts specific to your schema/application on each end, and if the format does not have the data types that you want then you must add them in a more messy way (especially when using JSON).

Re: Why I stopped using JSON for my APIs

#52

Post by morshu9001 »

zzo38computer wrote: post #51
morshu9001 wrote: post #46

Earlier quoted context omitted.

Yes but I don't want to worry about what parts of the spec are implemented on each end. If you removed all the unnecessary stuff and formed a new standard, it'd basically be protobuf.

I do not agree. Which parts are necessary depends on the application; there is not one good way to do for everyone (and Protobuf is too limited). You will need to implement the parts specific to your schema/application on each end, and if the format does not have the data types that you want then you must add them in a more messy way (especially when using JSON).

In what ASN1 application is protobuf spec too limited? I've used protobuf for tons of different things, it's always felt right. Though I understand certain encodings of ASN1 can have better performance for specific things.

Re: Why I stopped using JSON for my APIs

#53

Post by barremian »

written-beyond wrote: post #5

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.

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.

Re: Why I stopped using JSON for my APIs

#54

Post by recursivecaveat »

My dream binary format is schema driven, as compact and efficient as Capt Proto or such, but just optionally embeds the entire schema into the message. Then we can write a vim plugin that just opens the file in human readable form without having to fish for the schema. Whenever I am using binary formats, it's because I have a list of millions of objects of the same types. Seems to me that you may as well tack 1KB of schema onto a 2GB message and make it self-describing so everyone's life is easier.

Re: Why I stopped using JSON for my APIs

#55

Post by c-cube »

morshu9001 wrote: post #41

Protos are great. Last time I did a small project in NodeJS, I set up a server that defines the entire API in a .proto and serves each endpoint as either proto or json, depending on the content header. Even if the clients want to use json, at least I can define the whole API in proto spec instead of something like Swagger. So my question is, why didn't Google just provide that as a library? The setup wasn't hard but…

That's what Twirp (https://github.com/twitchtv/twirp) is about. Protobuf or JSON, over any HTTP, with a simple URL schema. It's fairly simple.

Re: Why I stopped using JSON for my APIs

#56

Post by barremian »

pyrolistical wrote: post #24

Compressed JSON is good enough and requires less human communication initially. Sure it will blow up in your face when a field goes missing or value changes type. People who advocate paying the higher cost ahead of time to perfectly type the entire data structure AND propose a process to do perform version updates to sync client/server are going to lose most of the time. The zero cost of starting with JSON is too com…

> When judging which alternative will succeed, lower perceived human cost beats lower machine cost every time.

Yup this is it. No architect considers using protos unless there is an explicit need for it. And the explicit need is most times using gRPC.

Unless the alternative allows for zero cost startup and debugging by just doing `console.log()`, they won't replace JSON any time soon.

Edit: Just for context, I'm not the author. I found the article interesting and wanted to share.

Re: Why I stopped using JSON for my APIs

#57

Post by barremian »

recursivecaveat wrote: post #54

My dream binary format is schema driven, as compact and efficient as Capt Proto or such, but just optionally embeds the entire schema into the message. Then we can write a vim plugin that just opens the file in human readable form without having to fish for the schema. Whenever I am using binary formats, it's because I have a list of millions of objects of the same types. Seems to me that you may as well tack 1KB of…

You could have a look at Avro (https://avro.apache.org/) and Yardl (https://microsoft.github.io/yardl/).

Re: Why I stopped using JSON for my APIs

#58

Post by zzo38computer »

morshu9001 wrote: post #52
zzo38computer wrote: post #51

Earlier quoted context omitted.

I do not agree. Which parts are necessary depends on the application; there is not one good way to do for everyone (and Protobuf is too limited). You will need to implement the parts specific to your schema/application on each end, and if the format does not have the data types that you want then you must add them in a more messy way (especially when using JSON).

In what ASN1 application is protobuf spec too limited? I've used protobuf for tons of different things, it's always felt right. Though I understand certain encodings of ASN1 can have better performance for specific things.

Numbers bigger than 64-bits, character sets other than Unicode (and ASCII), OIDs, etc.
Post reply on HN