Hacker News

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

7 points by clintjhill ago | 4 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!

japborst |next [-]

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.

clintjhill |root |parent [-]

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.

brightbed |previous [-]

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

clintjhill |root |parent [-]

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.