Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Poor Man's API

blog.frankel.ch

Post reply on HN
Print view View original

71–80 of 127 posts

Re: A Poor Man's API

#71

Post by Aeolun »

EdwardDiego wrote: post #29
55555 wrote: 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.

I miss aspects of those days, because I made a good bit of money from people who used MyISAM because "it's more performant" (or just because it was the default, yes, I'm dating myself here), and then corrupted their data because MyISAM didn't enforce constraints. Other than the easy money, nah, don't miss the old days that much. Having to use Reflector to decompile a core .NET library to figure out wtf it was doing b…

It was all more fun at the time because of those reasons. You didn't need anything more than 'barely adequate' to be at the top of your game.

Re: A Poor Man's API

#72

Post by cpursley »

madsbuch wrote: post #68
colonwqbang wrote: post #20

> when you’ve validated the requirements, you can keep the existing façade and replace PostgREST with your custom-developed API. Why? What is it about postgrest which makes it unsuitable for "real" usage? The author doesn't mention it.

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

Re: A Poor Man's API

#73

Post by Aeolun »

quickthrower2 wrote: post #52
k__ wrote: post #49

Earlier quoted context omitted.

I would go the other way around. Why start with an SQL database? When I start something new, I don't want to fiddle around with tables every time I change my model.

I agree but the baby of “joins” is often thrown out with the bathwater of “schemas” Is there a relational schemaless DB I wonder?

Sounds like a contradiction in terms to me.

Re: A Poor Man's API

#74

Post by Aeolun »

bmn__ wrote: 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?

Re: A Poor Man's API

#75

Post by cpursley »

k__ wrote: post #49
colonwqbang wrote: post #20

> when you’ve validated the requirements, you can keep the existing façade and replace PostgREST with your custom-developed API. Why? What is it about postgrest which makes it unsuitable for "real" usage? The author doesn't mention it.

I would go the other way around. Why start with an SQL database? When I start something new, I don't want to fiddle around with tables every time I change my model.

Then use a Postgres jsonb column. Makes it easier to migrate to a table when you have you model down.

Re: A Poor Man's API

#76

Post by KronisLV »

Here's a page that talks a bit more about Apache APISIX: https://apisix.apache.org/docs/apisix/getting-started/

I find it a bit ironic that they don't support Apache2 as the web server, you know, it being an Apache project and all, instead going for Nginx or OpenResty (though admittedly they're great projects).

Even nowadays Apache2 is pretty okay: https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-... (especially if you disable .htaccess for less disk I/O and use it with a single file based config)

Re: A Poor Man's API

#77

Post by cpursley »

blowski wrote: post #59
cpursley wrote: post #51

Earlier quoted context omitted.

What are the particular pain points for you? For me - using a similar system (Hasura), it's migrating things dependent on views. Feels like this should be a solved problem (database migration issue, not due to Hasura). But I still prefer it over writing CRUD.

At some point CRUD goes from being pure CRUD to mostly CRUD with a few special requirements - e.g. complex RBAC rules, decorating data, API versions, integrating third-party APIs, scaling. They're easy to do in most app frameworks (Laravel, Django, Rails), tricky in something like Postgrest. I haven't use Hasura.

You can get really far with database views (decorating data, especially), functions (all sorts of biz logic) and Postgres roles for RBAC. But I hear you on integrating with 3rd party APIs, etc. Fwiw, there's a number of PostgREST backend client libraries to help with that.

Re: A Poor Man's API

#78

Post by morelisp »

kreetx wrote: post #30
beachy wrote: post #18

Earlier quoted context omitted.

If you're talking about HATEOAS (which many zealots equate one to one with REST) you may be pleased to know there is no reference to it whatsoever in this article.

Or is it the other way around? I seem to remember that Roy Fielding did actually mean HATEOAS when saying REST, that REST isn't only CRUD but a discoverable and self-describing API. EDIT: And the corollary of above is that most people when saying REST actually mean HTTP with correct method use. If not, then is there a good source on what you mean by REST and HATEOAS?

A lot of people confuse HATEOAS, the idea, with HAL, some attempt to standardize it.

Re: A Poor Man's API

#79

Post by morelisp »

quickthrower2 wrote: post #34
tasuki wrote: post #17

> Creating a full-fledged API [...]. You need to think about [...] the REST principles I can assure you you don't need to do that. And most people don't. It's perfectly possible to create a useful API without adhering to the REST principles. [Edit, having read the rest of the article]: Case in point, this very PostgREST tool promoted in the article appears very useful, while not thinking about the REST principles.

What is the acronym for when something needs to be done, so you create an endpoint to do that thing, maybe return HTML if convenient (if it is a page request) or JSON if it is XHR, and then move on to the next user story?

HTTP. And it works fine up to a dozen entities and maybe a hundred endpoints, which will cover more use cases than people think.
Post reply on HN