Protobuf-ES: Protocol Buffers TypeScript/JavaScript runtime
buf.build
buf.build
Granted, the benchmark is created for protobufjs and they probably optimize against it. Protobuf-ES was about 5.1x slower than protobufjs for encoding and 14.8x slower than protobufjs for decoding.
This was run on my M1 with node 16.14; not particularly scientific, etc, etc.
My gut feeling is anyway that PB in JS is likely a failure against just using JSON (which the JS runtime implements in efficient native code).
But protobuf has very wide support and is decent enough in js, at least server-to-server. Having a schema is very valuable, and there are substantial size wins over JSON, even with gzip.
I really just prefer to use JSON for everything. It's much easier to debug and observe traffic (browser Network tab). I like JSON-RPC, very simple spec (basically one page long). I don't like REST.
All that said, I'm really glad to see the community take things into their own hands.
Contexts matters, there is no silver bullets, everything has trade offs and so on, and so on.
If you were going to use a binary protocol, why choose one that has no partial parsing/toc these days. There are much better alternatives IMO (flatbuffers being one of them)
Likely not. See here for a comparison: https://nilsmagnus.github.io/post/proto-json-sizes/
Btw, binary formats can also be compressed though it typically won't yield the same compression ratio as similar json would since there will be less repeation in the binary format.
This is a false flag. If you don't know the schema on the receiving (or sending, for that matter) side, then you can't do anything with the data, other than pass it on. If you _do_ know what it looks like, then it has an implicit schema whether you call it a schema or not.
JSON in C is unfortunately way harder than in other modern languages (e.g. Go which makes it a breeze with struct tags and a great stdlib).
The DX for JSON things is much better. The UX for protobufs is much better (faster, less data over the wire, etc). Which you optimize for is up to you, but there isn't a straightforward "Use this tech because it's the best one."
More features is not a measure of better UX. In many cases (most cases!?) it's the opposite.
Backend was with Absinthe+Elixir, so it was great (if I had to do it again today I would instead use Liveview, this was in 2017 where I had to retrofit a React app into something useable).
Public user facing is a different story, the last major one I saw was Tableau, though they are also business facing where they can just ban bad users. Github also has deprecated their GraphQL endpoints[0].
[0] https://github.blog/changelog/2022-08-18-deprecation-notice-...
To be fair, it sounds like that would just make the DX wonderful no matter which stack you were using?
Only if you have a very competent backend team, who, apart from dataloader, will have to figure out caching.
> /less data
Graphql responses tend to be pretty deeply nested.
I've always wondered about this. Firstly, I'm fairly sure clientside JSON parsing is significantly faster than protobuf decoding but even data over the wire: JSON can be pretty compressible so surely the gains here are going to be marginal. Surely never enough benefits to UX to warrant the DX trade off, right?
It also shows a difference of 388ms (protobuf) vs 396ms (JSON) which is pretty negligible. Certainly not orders of magnitude.
Do you have other sources?
[0] https://auth0.com/blog/beating-json-performance-with-protobu...
Third link is also server-side, but since it's NodeJS it's at least close enough / more relevant to client-side perf.
Here's the benchmark from the third link:
benchmark time (avg) (min … max)
---------------------------------------------------
encode-JSON 342.37 µs/iter (311.93 µs … 1.19 ms)
decode-JSON 435.9 µs/iter (384.44 µs … 1.41 ms)
encode-PB 946.43 µs/iter (777.38 µs … 3.13 ms)
decode-PB 770.79 µs/iter (688.99 µs … 1.78 ms)
encode-PBJS 696.75 µs/iter (618.43 µs … 2.43 ms)
decode-PBJS 455.36 µs/iter (413.66 µs … 1.09 ms)
in any case, that's the only time i've ever seen it used in production. the first link is a go benchmark that i felt represented why someone would use it for those purposes, the second was linked to show that despite numerous (successful!) attempts to make deserializing/serializing data faster and smaller, JSON is still the most heavily used and i would wager it's mostly due to how easy it is to use as far as browsers are concerned. the third was a link to justify that claim and show that js-land is much, much different than go-land as far as proto's and JSON encoding/decoding are concerned!
So yeah not a whole order of magnitude. I was using my experience as a guide where JSON parsing is a huge compute hog and Protobuf is not.
I've never experimented w/ Javascript or compression or any of the other things in that article, I guess YMMV.
Clientside is always going to be the pertinent metric for UX since it's processed on the user's device.
I feel like I'm having to repeat myself a lot here as noone seems to have read the original comment correctly: we're talking about one specific language in one specific known environment here. Noone is claiming that JSON outperforms PB in general: only that it does in browsers, where it's actually relevant for UX.
Where I’m working now, we have a REST API for users to interact with and every call behind the scenes is proto. As we deal with quite large objects, the benefits of avoiding repeated serialization and deserialization add up quickly.
From the user’s perspective we have a performant app, and much of this is possible due to proto.
So it sounds like the trade-off can be worthwhile in some cases: particularly for large objects where serialisation is a significant serverside bottleneck.
I'm curious: you say PB helps avoid "repeated serialisation/deserialisation": how? In my mind, architecting an app that uses JSON/PB on the wire serialisation happens once on output & deserialisation happens once on input. For both transfer formats. Surely you wouldn't be passing massive json strings around your app in memory?
Also curious which is the bigger bottleneck for your large objects: input or output. How large is large?
It id also not only the speed but also size is usually a magnitude off (and no, compression doesn't cut it and trades size again for computation).
Sure, if size and speed do not matter it is strange that you had considered protobuf at all.. but claiming they are never needed just means you have never been to resource constrained systems?
What you cite there, I assume most of that 400ms has nothing to do with the message encoding at all btw..
(b) I'm talking about a narrow & specific case. PB may outperform JSON in most cases but I'm very specifically referring to browsers where JSON is native (& highly optimised) whereas PB is provided by a selection of open source libraries written in javascript. So that domain heavily favours JSON perf-wise.
No, not at all... coming from embedded where apeed, memory size and also bandwidth did count, json was actually.not just worse, but just wouldn't have been feasible (because our protobufs already barely fit memory and MTU constraints).
I'm sure given two implementations of equal quality protobuf would easily outperform JSON, but I can also believe the JSON implementation in (for example) v8 is very, very hard to beat.
Of course, I might use protobuf because I prefer it in my code to JSON, and it certainly is faster (if only twice).
Json parsing is also a lot of special cases, error testing, but the v8 team has spent a huge amount of time optimising json parsing (theres a few blog posts on it). Im not assuming either way, but it's definitely as cut and dry as one would assume.
However, "packed" fields are exactly a length followed by a byte array of the typed data. This was an oversight in original proto2 which is unlikely to be corrected, but packed the default in proto3.
a few months ago i tested https://github.com/mapbox/pbf and while it was faster for deep/complex structs vs an unoptimized/repetative JSON blob, it was much slower at shallow structs and flat arrays of stuff. if you spend a bit of time to encode stuff as flat arrays to avoid mem alloc, JSON parsing wins by a lot since it goes through highly optimized C or assembly, while decoding protobuf in the JS JIT does not.
of course it's not always feasible to make optimized over-the-wire JSON structs if you have a huge/complex API that can return many shapes of complex structs.
we were streaming a few hundred float datapoints spread across a dozen(ish) flat arrays over websocket at 20-40hz and needed to decode the payload eagerly. plain JSON was a multi-factor speedup over pbf for this case. but it's fully possible i was holding it wrong, too!
even when your "bottleneck" is rendering/rasterization (10ms), but your data pipe takes 3ms instead of 1ms, it's a big effect on framerate, battery, thermals, etc.
i'm a big fan of your work! while i have you here, would you mind reviewing this sometime soon? ;)
PB can always be decoded to a text representation if you need to inspect it.
I once doing a mixing of two buffers that contains PCM. A simple task that take two number, average and put into another buffer. The native implementation is about 10x fast than the one I wrote with JS (Or consume 10X less cpu time).
A native Protobuf is definitely going to beat a native JSON implementation. A JS Protobuf if also likely to beat a JS JSON implementation.
But a JS Protobuf to native JSON? I doubt.
There's nothing in your comment that hadn't already been said before by sibling commenters but as far as I've seen in the real world JSON appears to be faster in practice. Which is all that counts.
Yours and the many other commenters making the same assumption (it's binary ergo it must be fast) make a really good case for PB's adoption being rooted in theoretical assumptions rather than real-world benefit.
I get it. It makes sense that it should be faster. Nothing is self evident though. You gotta measure it.
https://auth0.com/blog/beating-json-performance-with-protobu...
This thread is about protobuf vs JSON in a JavaScript environment.
The article you linked _does_ talk about JavaScript environments, too, but the numbers are much less impressive.
I'm saying that computer science and hardware dictate that protocol buffers are faster for a wide range of reasons. That part's not in question- smaller data encodings have better cache use, and require far fewer dictionary (hash table) lookups at parse time, as well as far length work parsing strings. If you want to argue against my point there I don't know what to say.
If it was a priority to write a blindingly fast protocol buffer parser in JS, it's almost certain than an expert could write a faster one than a similar JSON parser.
My attitude here is that I made a specific observation: JSON is likely to be faster or at least negligibly slower in browsers in practice.
Everyone is replying either with theoretical speed comparisons or server-to-server non-JavaScript benchmarks, which don't seem relevant to my very specific observation I made up top...
This is doable with JSON, but I've never seen a JSON based setup actually work well at catching these kind of regressions.
That's mostly been down to having IDE autocompletion for data structures and fields once the protobuf code's been generated.
For many JSON APIs I've worked with there's only been human readable documentation, making them more error prone to work with (e.g. having to either craft JSON manually for requests, or writing a client library if one doesn't already exist).
See http://seriot.ch/projects/parsing_json.html
Protobuf support for google's first-class citizen languages is usually very good, i.e. C++, Java, Python and Go. For other languages, it depends on each implementation.
Could it be that JS's Date doesn't support nanoseconds because it cannot represent them, which is the issue we are talking about here?
Don't get me wrong, I understand this is not something that everyone uses every day, but to me it's a pretty straightforward example that can happen in a wide range of situations. It certainly happened to me/colleagues several times in several companies.
What I really like about Protocol Buffers is that you must write a schema to get started. No more JSON.stringify anything. Everything else sucks though.
ALWAYS favor a binary format unless you have a really good reason otherwise.
Also, Capnproto is quite extensively used in some Cloudflare products.
I'm not a frontend dev. Most of my time was spent on the backend but what I'll say is I much prefer the fluidity and dynamic nature of JavaScript and the built in ability to deal with JSON that naturally become objects. All the type stuff is easy to do but with docs you can get away with not needing it.
My feeling. Protobuf lives on for gRPC server side stuff but for everywhere else OpenApi is winning.
grpc-web in particular requires an Envoy proxy which seems absurdly heavyweight. I ended up using Twirp because Buf connect wasn't yet released or planned.
I rolled my own JS representation. The major differences from Connect:
- Avoid undefined if the message is not present on the wire and use an empty instance of the object instead. For recursive types, find the minimal set of fields to initialize as undefined instead of empty.
- Transparently promote some protobuf types, like google.protobuf.Timestamp to a proper Instant type (from js-joda or similar library). This makes a surprisingly large difference on reducing the number of jumps from the UI to the API.
If using compression the size is in the same ballpark (protobuf can be between 20% and 50% smaller). For 99% of users it should not make a difference. https://nilsmagnus.github.io/post/proto-json-sizes/#gzipped-...
If you are designing your own solution that uses protobuf instead of JSON say goodbye to a range of useful tools that the whole industry uses. From testing to automation it will be harder at every step, and you will have to find custom solutions instead of usual no-customization solution that works OOTB with JSON.
It is a good way to frustrate your developers and generate sometimes brittle solutions related to testing/automation/infrastructure.
My suggestion/strawman is to add request/response debug headers that include this in a standardized way. Then tooling can start to pick this up (eventually). The developer experience can then start to approach json.
And if you are faced with a server that only speaks protobuf, the same question applies to the original devs: why did they make that decision?
The link you included shows that protobufs are at least 15% better for all users, and as much as 57% better for cases where the data is small. Doesn't that mean for 100% of users it will actually make a difference?
Your users might not care about the difference but it will be there.
Actually realizing that speed up for your users will take time away from delivering features.
Engineering is a trade off, always will be.
You don't optimize things for the cases when they are fast. (Unless the gain is a couple of orders of magnitude; certainly not for a 50% speedup.)
The 15% gain is the one that matters. On practice, it comes at the expense of a more complex (thus larger, negating some of it) and less reliable system. It is very rare that this trade-off is worth it.
You also have solutions like GraphQL that define a schema, or you can publish some kind of schema (a good thing to do) but use JSON instead of a binary format.
Both your application and documentation will assume certain state to be true, but only with type checking you can actually verify if it's correct.
- https://github.com/project-flogo/grpc/blob/master/proto/grpc...
- https://github.com/OAI/OpenAPI-Specification/blob/main/examp...
(I still like protobuf, but the schemas are a terrible reason to like it.)
Isn't it slower than protobufjs?
Otherwise personally json wins
The principle benefit is that you can use the schema to define the data format, which means you can pack the data in more tightly (you don't need a byte to say "this is an object" if you know that the input data must be an object at this point). That's a big benefit in certain situations, but if you're using this sort of stuff just to get validation then you're probably better off using JSON Schema and having a wire transfer format that you can read easily without additional tools.
I can't tell whether I'm just dumb or a really terrible developer, or if the docs or the thing itself is really hard to use?
1. Your schema is the source of truth.
2. The protoc should generate code as part of your build (try not to check in generated proto code if at all possible).
3. Use generated code to output bytes/parse bytes (this depends on your HTTP/RPC library).
The other trick is that you should use the exact same (!) schema file for your frontend and backend projects. This means that changing it should trigger regeneration of generated code for your clients and servers and then run CI on them.
So if you accidentally introduce a breaking API change, the CI for broken client will fail before you deploy it.
You do not need to have the exact same schema file, in fact protobuf is carefully designed to avoid needing this. You need to follow some rules about what to do when fields are added or removed:
* Generally, roll out the server side first then, once that is complete, start rolling out the client afterwards.
* If a field is added (on the server side), make sure that it can be ignored on the client side, so old clients are not impacted. For example, don't add a "units" field that changes the meaning of existing "temperature" field (previously had to be fahrenheit, now can be celsius or fahrenheit). Instead add a separate field "temperature_celsius" and send both. (You can always remove the old one later on the server if new clients don't need it and you have 100% finished roll out of clients.) Note that receiving unexpected field data is not an error in protobuf, so the extra field won't cause any problems so long as it's not a problem at application level.
* You can equally remove a field so long as the client isn't relying on it (in this case you may need to roll out client update first). More accurately (with proto3 syntax) it will appear as empty/zero so this needs to be OK.
* You can't change a field's type e.g. from integer to double (or from one message type to another, but just adding a field to a message according to the above is OK). If you want to do that, go through a controlled process of adding a new field with the new type you want then removing the old field.
* You are free to reorganise the order fields appear in the proto file but don't renumber the fields - the field number is what defines it in the binary encoding. In particular, if you remove field number 2 (for example) you should leave a gap (fields 1, 3, 4,... remaining) rather than renumbering the remaining ones to be contiguous.
Depending on the application, it is often actually a good idea to have a completely separate copy of the proto file in the client and server applications, with the client proto typically lagging behind the server one.
I suspect this would not be much heavier than json so it could be always left on for those who are ok with the overhead.
Win win?
I was hoping Buf could solve that problem... Maybe in the future! :)
It has a minimal API, literally one function, with which you can expose your server’s functions. It will generate a Typesafe SDK for your frontend(s), packed with all models you’re using. It will also generate a server which will automatically validate input & output to your server.
One thing I’ve seen no other similar solution do is the way we do error handling: throw an error on the server and catch it on the client as if it was a local error.
As I said, it’s only meant for teams who have full stack TypeScript. For teams with polyglot stacks an intermediate like protobuf or GraphQL might make more sense. We generate a TS declaration file instead.
I recently had to select a suitable data serialization format for a sort-of-distributed application. The goal was to force teams to declare/discuss contracts up-front, so schema-based. It was a very frustrating experience. All the formats with expressive schemas and type systems somehow don’t have a concept of required fields, or not anymore. How can you create a robust system like this?
> required: a well-formed message must have exactly one of this field.
https://developers.google.com/protocol-buffers/docs/proto#sp...
I’ve also talked to Googlers about this. My understanding is that having required fields created a robustness problem for them.
My guess is that it’s the same situation as for basically everything else: the problems Google is trying to solve for, and the constraints on the solutions to those problems, are just different from what the rest of us are dealing with. That doesn’t make protocol buffers bad, but it maybe does make the level of mindshare Google gets in this corner of the technology world bad.
That said, 100% agreed. Proto2 solves for that one use case (required fields), but not others such as "I want to talk to this API from the browser." I would love to have a solution that prioritized being easy to implement and support over being as heavily engineered - and, consequently, difficult to understand and use effectively - as FAANG-scale technologies tend to be.
Over those ten years your data model has evolved. Your first client, the one whose data model you were imitating when you added the required field, was deprecated five years ago and turned down last year. You have a dozen or a thousand client services, each using you as a backend in a slightly different way. Are you sure every single one of them is going to require that field? Are you sure the field will even be semantically meaningful for their use case?
It’s not that smaller companies never have these problems. It’s that, at smaller companies, the ways in which they manifest themselves and the cost/benefit ratios tend to favor different solutions to these problems. For example, the company I was at that stuck with Proto2 so they could keep required fields, all the engineers worked in a single room, and could resolve questions about the needs of all a protocols consumers by simply standing up and saying, "Hey everybody, …"
The problem with required fields is it kicks the can down the road when you want to deprecate a field. Keeping everything optional is much, much better for everyone in the long run.
I understand that "elastic" contracts may make some stuff easier. They do not help in forcing developers to create a message correctly, unfortunately.
Still, it's great to see someone is tackling the validation rule topic. One of my stakeholders is very… enthusiastic about validation. Just goes to show how bad software engineering is in practice in this org.
If you set the value of a field, then it will be serialized with that value. It doesn't matter if the value is the default for that field.
The docs (proto3) say this: “Also note that if a scalar message field is set to its default, the value will not be serialized on the wire.”
https://developers.google.com/protocol-buffers/docs/proto3#s...
If you don't like that, don't use "singular".
Guess I’ll take another look at proto2 then.
A protobuf is a low-level abstraction, like a struct or record type in your favorite programming language. You want validation logic to be a separate layer on top. You don't want it so coupled to parsing/serialization that you literally cannot parse/serialize something that doesn't validate.
Protobuf has a rich facility for adding custom annotations to anything (messages, fields, etc). These annotations are the right place to put validation predicates. That will let anyone build a validation layer on top of protobuf, for example: https://scalapb.github.io/docs/validation/
1. To me the compression that protobuf offers, while cool, is not what I find most important about it (or, rather, is not the feature that I like the most). What is the most important (for me) is that the sterilization _forces your server and client to have a typed API contract_. This is a pretty big deal. Imagine you're in a situation where you spent months laboring over your OpenAPI config, just to later realize that
> _oops! my OpenAPI config doesn't actually represent what my server is actually doing, and now my OpenAPI generated user documentation is wrong, and my TypeScript types I generated from the OpenAPI config are wrong too, which means I'll get runtime `TypeError`s on the frontend.
This is a pretty common situation for people to find themselves in, and it's a tough spot to be in because... well... you can't ever escape. Because no one is really reliably generating actual running servers from OpenAPI configs, you hit this situation reallllly fast. Protobuf, on the other hand, is legitimately a spec-first workflow (by force -> which to me is a very good thing). Take a look at Postman's state of the API report, and you'll see that even their customers are only doing spec-first 10% of the time (and, this is supposed to be the cream of the crop in cutting-edge spec-first development). Why? Because it's really really really hard to do in practice. But protobuf makes it easy. That's a big deal.
2. gRPC and protobuf are not as deeply tied as you might think. You can use protobuf without gRPC at all, and in fact a lot of people are doing this. You can even do it over WebSockets, or anything else. Unfortunately, because the two technologies are often mentioned in the same breath we tend to deeply associate them. Years ago I had a project I needed to pick a wire compression thing for (it was just for fun) and since I was tired of always just using messagepack over and over again, I evaluated other options. I picked FlatBuffers in the end, but I wish I could go back in time and ask my past self why I didn't pick Protocol Buffers instead. I KNOW I remember looking into protobuf, but I think I just assumed that in order to do protobuf well you had to also use gRPC and since I wasn't up for learning gRPC, I gave up on protobuf. That's the beauty of what tools like Protobuf-ES are changing -> they're making protobuf accessible to everyone.
..and besides, there are other things that protobuf unlocks(namely the "reflection" API (very much like GraphQL's introspection API if you're familiar with that), but also things like documentation generation and enforcement of backwards-compatible changes) but the above are the two most appreciated by me.
I solved this by generating JSON schemas from my TypeScript files, and then enforcing those schemas on my endpoints.
Using the magic of code generation (actually just templated strings) I am then able to create client libraries in whatever languages are needed.
The unfortunate part of this is being limited by what TypeScript offers, no run time validation of the shape of fields, e.g. no way to say "this number has to be less than 120". JSON Schema is actually a lot more powerful than TypeScript, so going from TS->JSON Schema actually reduces expressiveness.
But then again, the vast majority of programming languages don't allow for actually good descriptions of types. :(
Also, if you haven't checked it out, typescript-json-schema has some REALLY powerful validation it can do for things like your example (https://youtu.be/HHTDCY5uh_M?t=1379). You can do stuff like this
export interface Shape {
/**
* The size of the shape.
*
* @minimum 0
* @maximum 120
* @TJS-type integer
*/
size: number;
}
Oh wow I didn't realize TS JSON Schema was capable of all that!
> but there's still nothing _enforcing_ that contract.
Sure there is, the schema on my REST endpoint. Express and AJV check all messages coming in.
It requires changes be non-breaking changes of course, new fields need to be optional, same as protobuf.
Removing a field means making it optional, removing it from all calling code, then removing it from the schema entirely. Real pain, but that is the price you pay if you want required fields. Only really doable if you can also control all the code, but since I'm working on internally facing services only, not an issue. :)
The protobuf-gen-es plugin sounds nice, I'll definitely be checking it out.
However, I don't understand the desire for people to write protoc plugins in anything but C++, and I'm not even a C++ developer (I much prefer js/ts for many things). Instead of a single c++ source file with a builtin cool templating library which compiles trivially to a tiny binary, you inherit a huge dependency chain that includes the typescipt compiler and nodejs runtime. Totally unnecessary IMHO.
In practice, this is pretty similar to how you maintain compatibility with old clients in JSON. But with protobuf, you have the schema file to make code reviewing this kind of change easier.
What's not in there is protection against violations such as sending multiple values for non-repeated fields (the latest value wins) or accidentally making non-backwards-compatible changes to the schema, e.g. reusing field numbers or changing types. The internal Google styleguide for Protobuf is a valuable resource for the collective avoidance of foot-firearms, and it's a bit sad it doesn't seem to be published externally.
I don't know of any existing linter that could check for backwards compatibility , but I am interested in one. Might break out one I wrote to a separate library. There aren't too many situations that commonly causes breakages. One reason may be that developer names (text identifiers) are separate from on-wire/persistent names (integer tags). This leaves some wiggle-room for improving your development environment by incrementally clarifying names without breaking backwards-compatibility with already compiled code.
Buf, from the OP, does this with `buf breaking`.
Theoretically, a protobuf schema allows addition and removals. In practice. schema-nazist will destroy your life and change whatever cause the only little thing that separates them from the peasants is that royal like power of making breaking schema changes in prod and pinning that incident on you. Your code did not even use that data probably.
> Arrow Flight is an RPC framework for high-performance data services based on Arrow data, and is built on top of gRPC and the IPC format.
> Flight is organized around streams of Arrow record batches, being either downloaded from or uploaded to another service. A set of metadata methods offers discovery and introspection of streams, as well as the ability to implement application-specific methods.
> Methods and message wire formats are defined by Protobuf, enabling interoperability with clients that may support gRPC and Arrow separately, but not Flight. However, Flight implementations include further optimizations to avoid overhead in usage of Protobuf (mostly around avoiding excessive memory copies
"Powered By Apache Arrow in JS" https://arrow.apache.org/docs/js/index.html#powered-by-apach...
Read: https://westurner.github.io/hnlog/
If you have a question about what I just took the time to share with you here, that would be great. Otherwise, I'm going to need you on Saturday.
I prepared all of these buddy. These links are very relevant.
Given the form of the way I've been accused, I won't be spending time defending anything for yas.
Something "interesting" in the overall IoT protobuf experience is software licensing.
I can write software under, GPL, or whatever, to access or otherwise interoperate with a REST API implemented using, BSD, or whatever, no problem as long as it follows reasonably close to generic REST standards. Just look at your swagger API docs or whatever system you use, it'll interoperate just fine.
Ditto "most JSON stuff" just write your proprietary code to generate a JSON looking like some text documentation for a server under, perhaps, the MIT license, or whatever other license, and interoperability across licenses is easy and legal.
Things get weird with protobuf .proto3 files where the server and ANY clients need to use the same .proto3 file to compile to whatever language they'd like to use. So what license do YOU apply to your .proto3 files to make sure other people can (or intentionally cannot) redistribute your .proto3 or compile software against it, etc?
You can, intentionally or accidentally, implement all kinds of lockdown and restriction on APIs using protobufs via innocent or intentional copyright and license selection for a .proto3 file.
For better or worse, protobufs are a tool invented primarily to enable the prevention of interoperability. If it was just about saving bytes on the wire we'd be doing IoT using zipped up JSONs or similar technology.
Another issue with the standard implementation is that the TypeScript declaration files are missing lots of stuff. E.g. deserialization functions actually take a jspb.ByteSource (which can be Uint8Array, base-64 string and others), but the declaration files use Uint8Array.