Live data from Hacker News

A Poor Man's API

blog.frankel.ch

101–110 of 127 posts

Re: A Poor Man's API

#101
That's what I actually admire about Supabase [0].

The folks created an almost full fledged Firebase replacement by clipping pieces together (similar to the article, replacing APISIX with Kong) and it allows them to iterate super fast.

Pragmatic, and nice if you're on the receiving end of it .

[0] https://github.com/supabase/supabase#how-it-works

Re: A Poor Man's API

#102
post #86

Earlier quoted context omitted.

Perhaps I'm a zealot: HATEOAS is one required part of REST as per Roy Fielding, who came up with both. What does "REST" mean to you?

It seems like when taken to an extreme, strong HATEOAS would mean you could write a universal client that works across all APIs. I don't think service developers take HATEOAS super-seriously. From what I've seen, returning resources with a URI rather than an identifier is about all many services do to be HATEOAS-ish. Clients are coupled to the server, but that's often okay.

> strong HATEOAS would mean you could write a universal client that works across all APIs.

It would be hard not to make that client behave like a browser from the user's point of view.

Re: A Poor Man's API

#103

Earlier quoted context omitted.

Postgres is amazing, but there are some issues you quickly hit with systems like this: 1. Side effects: Want to send an email when something happens 2. conditional permissions: Need access to data under certain circumstances not modelled by the security language? 3. Subset access: Access to parts of the row / document. 4. Aggregate access: Access to eg. a count of rows you can not access. These are usually solved usi…

Supabase handles all of this. I handle #1 with by listening to database changes then reacting as needed with a change capture / event-like system: https://github.com/cpursley/walex

The problem with event driven systems is that they can end up being a kind of spaghetti. It can be hard to track down all the side effects. There's no place where you can read some code to see what happens sequentially.

Re: A Poor Man's API

#104
post #60

Earlier quoted context omitted.

Supabase has a free tier with all this included, plus more. It's the best install of postgres I've seen and I'm obsessed with how it makes triggers, auth, etc., all included.

I think they should create a tier between the free and pro with a price of USD5 that doesn't pause projects and has backups

Agree on the backups piece, that should even be in the free plan as that much space is not likely to be expensive if they used cold storage.

Otoh, if you aren’t sending 1 request per week to an installation, it’s really not active at all. The overheard of supporting this niche is probably too much for a company that clearly is in ruthless prioritization mode.

Re: A Poor Man's API

#105
post #24

Earlier quoted context omitted.

Supabase has a free tier with all this included, plus more. It's the best install of postgres I've seen and I'm obsessed with how it makes triggers, auth, etc., all included.

Did a user group presentation on Supabase, no one in the audience had ever heard of it. I came away quite impressed. Plan on building a complex API with it soon. If I was currently employed as a backend developer I'd be worried.

This just removes the need for some backend engineering, but will leave the actual hard work (schema design, etc)

More and more, developers need to add value to the business, instead of being the key holders of arcane invocations. It used to be that knowing how to use a computer was a technical skills; now it’s evolved into understanding the business.

Re: A Poor Man's API

#106
post #74
post #38

> PostgREST is a fast way to construct a RESTful API. That's false. The responses don't even have hyperlinks.

If you already have relationships between tables, then it shouldn't be that hard to add right?

Right. The problem is not difficulty, but motivation. The responsible programmer begriffs does not have the understanding why it is a good idea to do so, despite bug reporters on Github having spent years in discussions.

Re: A Poor Man's API

#107

Earlier quoted context omitted.

It seems like when taken to an extreme, strong HATEOAS would mean you could write a universal client that works across all APIs. I don't think service developers take HATEOAS super-seriously. From what I've seen, returning resources with a URI rather than an identifier is about all many services do to be HATEOAS-ish. Clients are coupled to the server, but that's often okay.

> strong HATEOAS would mean you could write a universal client that works across all APIs. It would be hard not to make that client behave like a browser from the user's point of view.

Exactly. HATEOAS implies as much flexibility as a browser, and as much understanding of the server data as a browser. So if you want a HATEOAS API, just make it output HTML and go with the crowd.

Re: A Poor Man's API

#108
post #86

Earlier quoted context omitted.

Perhaps I'm a zealot: HATEOAS is one required part of REST as per Roy Fielding, who came up with both. What does "REST" mean to you?

It seems like when taken to an extreme, strong HATEOAS would mean you could write a universal client that works across all APIs. I don't think service developers take HATEOAS super-seriously. From what I've seen, returning resources with a URI rather than an identifier is about all many services do to be HATEOAS-ish. Clients are coupled to the server, but that's often okay.

> It seems like when taken to an extreme, strong HATEOAS would mean you could write a universal client that works across all APIs.

And if you go with HAL or JSON-LD, you have to use a specific clients for those formats, so not universal anyway.

I tend to agree with "HATEOAS is for Humans"[1], HATEOAS makes sense when interacting with HTML.

[1]: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

Re: A Poor Man's API

#110
post #11

Check out this simple, easy API replacement: just set up Docker, APISIX, Grafana, Prometheus, etc. Does anyone else miss the old days of just editing your site's code and adding new columns to your MYSQL database while people were surfing your website? That was fun. Tip: Another way to turn your DB into an API is to just connect to it and then write SQL queries.

Or use https://github.com/mevdschee/php-crud-api and skip writing queries (for basic CRUD).

> Howto: Upload "api.php" to your webserver, configure it to connect to your database, have an instant full-featured REST API.

Post reply on HN