News for hackers. Stuff that matters.
Re:The Future of Kubernetes by radicalbyte on Sunday March 13, 2022 @09:06AM (#30660900)
I find this amusing considering that the JSON community are slowly re-inventing XML with their versions of XSL, XSLT etc.
Re:The Future of Kubernetes by leetrout on Sunday March 13, 2022 @09:13AM (#30660949)
True but i do see a general shift to "types are good" so there is a shift to "schemas are good" by extension IMO.

The big thing is JSON has common basic building blocks (simple types) so you are unlikely to see the same class of interop problems like SOAP and friends had ... "oh look this defines a new type my Python soap / xml lib doesnt natively support" (happened to me a few times, most memorable was akamai soap api using a custom list-of-string type nothing in python would parse out of the box)

Re:The Future of Kubernetes by radicalbyte on Sunday March 13, 2022 @09:46AM (#30661155)
Types are good and XML/SOAP was a good idea. The vendor lock-in shenanigans were the problem.
Re:The Future of Kubernetes by pjmlp on Sunday March 13, 2022 @10:53AM (#30661724)
Just like the WASM folks are now re-inventing application servers.
Re:The Future of Kubernetes by tkiolp4 on Sunday March 13, 2022 @09:10AM (#30660930)
JSON is already 20 years old. I guess things can’t stay the way they are forever (and 20 years in the IT world is a lot).
Re:The Future of Kubernetes by marcyb5st on Sunday March 13, 2022 @09:30AM (#30661036)
I am not sure. There are already superior (IMHO) alternatives and JSON still sticks around unaffected. For instance, at work we use protobuffers everywhere and now I am so used to that that I started using them also on my personal projects since I believe they are so convenient. In fact, I am not sure how many hours I saved from not having to write serialisation/deserialisation code, and how you can get full IDE support for your messages.

However, it seems protobuffers (or alternatives like flatbuffers, cap'n proto) are still niches compared to JSON.

Re:The Future of Kubernetes by leetrout on Sunday March 13, 2022 @09:57AM (#30661242)
Everyone I've worked with save a few that experienced protobufs with extentions immediately finds the benefit once they use them.

However I have yet to convince anyone at an org that isn't already using them that they will change things for the better.

Schema once, code everywhere. It is really nice.

Have you seen Buf? https://buf.build/

Re:The Future of Kubernetes by marcyb5st on Sunday March 13, 2022 @04:06PM (#30665207)
Indeed a chicken and egg problem since investing in the tooling to make protobuf usage smooth requires some prior use.

No, thanks for sharing! I will have a look!

Re:The Future of Kubernetes by vstollen on Sunday March 13, 2022 @10:04AM (#30661305)
I'm not too far into protobuf, etc., but do you only prefer them for your internal services, or do you actually see them as a viable solution for public-facing APIs?
Re:The Future of Kubernetes by marcyb5st on Sunday March 13, 2022 @04:04PM (#30665175)
Great question! My rule of thumb would be for server to server apis use protobufs. Also probably for Android/iOS/Flutter clients (depending on how well the protobuf compiler is integrated in your toolchain). For web clients, last time I checked, grpc-web was the most complete implementation/tool, but couldn't make it work with the rest of our stack. Maybe spending more time I could've, but it got really frustrating and I gave up.