🥳 New module release: Hetzner Cloud OpenAPI Client

codeberg.org/small-tech/hetzne…

This is an OpenAPI client for Node.js generated from the official Hetzner Cloud OpenAPI specification using Massimo.

Recently, while reviewing the code for Catalyst¹, I realised that the Hetzner library I was using was deprecated. The only other client library listed on Awesome Hetzner Cloud for JavaScript was updated seven years ago². So I did a bit of research and discovered that Hetzner has an official OpenAPI specification (useful little things that you can generate documentation as well as working client code from). I also discovered Massimo³, a lightweight and easy to use OpenAPI client generator.

So, anyway, a few minutes later, I had a working Node.js client generated but I thought I’d take a little more time to make it into a module in case anyone else wanted to use it.

In the process, I also created a simple web app example with Kitten⁴ where you can enter your Hetzner API key in a web interface, have it persisted to the default Kitten database⁴ and then carry out a simple call to list your servers. It’s 99 lines of code, including comments, in a single file. (Because Kitten loves you.)

The example uses the new/advanced class and event-based way of working with Kitten so you might find it interesting for that reason too (I haven’t had the chance to document this workflow properly yet). It also showcases Kitten’s Streaming HTML⁵ workflow, as well as its built-in support for semantic default styles and its first-class Markdown support.

You can see the source code for the Kitten example here:
codeberg.org/small-tech/hetzne…

The cool thing is that because the client is generated from the official Hetzner OpenAPI specification, it’s one command to update it should the specification change and you can be sure it matches exactly what’s in the API documentation.

Enjoy!

💕

CC @hetzner @lenzgr

¹ catalyst.small-web.org
² github.com/hetznercloud/awesom…
³ massimohttp.dev/
⁴ kitten.small-web.org/tutorials…
⁵ kitten.small-web.org/tutorials…

#Hetzner #HetznerCloud #API #OpenAPI #Massimo #NodeJS #JavaScript #servers #hosting #VPS #Kitten #SmallWeb #SmallTech

About Bluesky and federation:
Edit: There might be some mistakes, and my information could be outdated, but the point still stands - Bluesky wasn't built on 100% federation from the start.

I've been wondering about Bluesky's decentralization again. I can't think of any reason why I'd want to self-host Bluesky in its current form. I cannot 100% self host "my own Bluesky".

Their main selling points for building their own protocol were easier migration and better discoverability, but right now there's no simple way to migrate my Bluesky account to my own instance. And hosting the centralized parts yourself isn't really possible, or if it were, not affordable, they haven't made that feasible, by design, it seems.

Even if you self-host a PDS, Bluesky's Relay only indexes up to 10 accounts from it. You can run more, but they won't federate, the central infrastructure decides what gets seen. They control this (source: docs.bsky.app/blog/self-host-f….). You can self-host a PDS (Personal Data Server), but you still depend on Bluesky's centralized Relay and AppView. There's no production-ready alternative infrastructure from what I gather.

It feels like I'd be renting a room in a hotel that someone else is running anyway, when I want my own hotel.

If Mastodon gGmbH vanishes tomorrow, my instance keeps running and federating with everyone else. If Bluesky PBC vanishes, the ecosystem would need to scramble to stand up replacement infrastructure that doesn't really exist yet.

ATProto keeps getting evaluated on its promises while other systems get evaluated on their merits. The "portability" selling point depends on infrastructure that isn't mature enough to actually catch you if Bluesky falls.

I trust W3C, the builders and fathers of the World Wide Web, ActivityPub and the Fediverse.

#Decentralization #SelfHosting #SelfHosted #Mastodon #Fediverse #Bluesky #Servers