The Threadiverse is growing again, this time offering an effort to build a new Lemmy replacement from scratch, with API compatibility.

Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy’s Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps of choice.

  • Skull giver@popplesburger.hilciferous.nlEnglish
    391·
    10 months ago

    One nice thing about this project is that it integrated an OpenAPI spec generator, something the Lemmy backend lacks. Using this generator, developers can download a file and automatically generate all the code necessary to read and submit data to the Lemmy API without hand crafting a bunch of requests.

    As long as Sublinks is fully compatible with Lemmy, that means you can use this project to make developing Lemmy apps easier!

      • Skull giver@popplesburger.hilciferous.nlEnglish
        8·
        10 months ago

        There is, but it’s barely documented and you practically need to reverse engineer it if you want to use the API in another language. There’s a package out there that will parse and convert the Typescript output to Go code but I had to fix a lot of conversion errors last time I used that, I’d much rather stick to the OpenAPI document.

        • RonSijm@programming.devEnglish
          4·
          10 months ago

          There’s a user made OpenAPI spec: https://github.com/MV-GH/lemmy_openapi_spec - You probably mean that one

          I’ve had similar issues as you mentioned that the dev did fix - but yea, Typescript has less precision than Rust (the source) or the openapi spec. And the Typescript client is build for Lemmy-JS and not build an example for other language client libraries…

          Though the OpenAPI Documents in C# and Java are based on reflection of the source itself, and Rust doesn’t have Reflection like that… So it’s probably difficult for them to add without manually maintaining the OpenAPI specs