Show HN: attainable – The fastest and easiest way to design and deploy APIs | Hacker News Reader

Show HN: attainable – The fastest and easiest way to design and deploy APIs

attainable.dev

8 pointsclintjhill4 comments

This began as a passion project and an opportunity to learn new tech.

I've always experienced frustration developing APIs, especially the RESTful CRUD style of data APIs. It always felt like I was repeating the same patterns over and over again, and that was tedium I didn't want. A little over a year ago, I wanted to learn more about Go, Firecracker microVM, and Svelte and thought "Could I build an API framework that was just a simple description of resources? What would that look like?"

That lead me to https://firecracker-microvm.github.io/, which landed me on https://fly.io, then https://rqlite.io, and the further I got into it, the more I really liked what I had. It's been over a year of learning and trying out all forms of tooling, CLIs, LSPs, and finally I landed on this.

So I decided to try my hand at making this a product. I'd really enjoy feedback about it and whether it's something folks would use. Here's hoping others feel the way I do about APIs and the developer experience building them!

Open articleView on HN

Cool!

I wonder if this isn't toooo much magic. How does this scale beyond simple use-cases? I fear one might hit a wall at 80%, where the first part is super easy indeed but not customizable enough to get to 100% of all use-cases.

Thanks! It's a great point to make. Early on I worked on a "migration" ability for the resources, so that every change you make automatically updates the underlying database. But the longer I worked on that, the more I realized I could create/delete as many APIs as I wanted working out what's necessary. Then scale it up for longevity. And the time it took to create/delete APIs was nearly as fast as some of the build times I've experienced for front-end applications.

That's ultimately what I think the value is: API development as hyper-iterative as front-end apps.

I'm still clearly working out how to describe this value. I'm developing more examples to help define what I think the best use-cases are.

What’s the difference between the pricing sizes (micro, small, etc)?

Basically those plans represent the size of the clusters that are deployed for your APIs.

All of them come with a minimum 3 node database layer, and each plan increases the node counts. The medium and large plans also increase the CPU/mem of the database nodes.

Reply on news.ycombinator.com