There are a couple I have in mind. Like many techies, I am a huge fan of RSS for content distribution and XMPP for federated communication.

The really niche one I like is S-expressions as a data format and configuration in place of json, yaml, toml, etc.

I am a big fan of Plaintext formats, although I wish markdown had a few more features like tables.

  • arthur@lemmy.zipEnglish
    17·
    14 days ago

    GRPC for building APIs instead of REST. Type safety makes life easier

    • JakenVeina@lemm.eeEnglish
      8·
      13 days ago

      I mean, REST-ful JSON APIs can be perfectly type-safe, if their developers actually take care to make them that way. And the self-descriptive nature of JSON is arguably a benefit in really large public-facing APIs. But yeah, gRPC forces a certain amount of type-safety and version control, and gRPC with protobuf is SUCH a pleasure to work with.

      Give it time, though, it’s definitely gaining traction.

    • FizzyOrange@programming.dev
      8·
      13 days ago

      The biggest problems with gRPC are:

      1. Very complicated. Way more complexity than you want in most cases.
      2. Depends on HTTP 2. I’ve seen people who weren’t even doing web stuff reach for gRPC, and now boom you have a web server in your stack for now reason. Compare to Thrift which properly separates out encodings, transports, etc.
      3. Doesn’t work from the web. There are actually two modifications to gRPC to make it work on the web which means you have three different incompatible versions of gRPC with different feature sets. IIRC some of them require setting up complex proxies, some don’t support streaming calls, ugh. Total mess.

      Plain HTTP can be type safe. Just publish JSON schema or Typespec files or even use Protobuf.

      • arthur@lemmy.zipEnglish
        3·
        13 days ago

        Your concerns are all valid, but about 1 and 3 there are possible solutions. I’m using Rust+Tonic to build an API and that’s eliminate the necessity of proxies and it’s very simple to use.

        I know that it don’t solve all problems, but IMHO is a question of adoption. Easier told tools will be develop for it.

      • ulterno@lemmy.kde.socialEnglish
        3·
        13 days ago

        Depends on HTTP 2.

        Doesn’t work from the web.

        Am I the only one who is weirded out? Requiring a web server for something and then requiring another server if you want it to actually work on the web?
        How expensive do people want to make their deployments?

    • sexual_tomato@lemmy.dbzer0.com
      7·
      14 days ago

      It’s the recommended approach to replace WCF which was deprecated after .NET framework 4.8. My company is just now getting around to ripping out all their WCF stuff and putting in gRPC. REST interfaces were always a non-starter because of how “heavyweight” they were for our use case (data collection from industrial devices which are themselves data collectors).

    • Caveman@lemmy.world
      2·
      13 days ago

      I like the concept and I think the use case is almost covered by generating API client through generated OpenAPI spec.

      It’s needs a bit of setup but a client library can be built whenever a backend server is built.