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

81–90 of 127 posts

Re: A Poor Man's API

#81

Post by blowski »

cpursley wrote: post #77
blowski wrote: post #59

Earlier quoted context omitted.

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.

Totally agree that it's possible. But at some level, it may just be easier to use something else. If you're a strong Postgres DBA, I can see how you'd come down on the side of PostgREST. If you're a strong Rails dev, it would make more sense to use that.

Re: A Poor Man's API

#82

Post by ushakov »

senko wrote: post #43

Or just use an API generator like https://apibakery.com , https://amplication.com or another with your favorite framework and call it a day.

Do I have to generate my API from scratch if the schema changes? If so, this solution is a no-go

Re: A Poor Man's API

#83

Post by CharlieDigital »

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.

You might like Directus.

It is nominally a "headless CMS", but it's so close to the SQL that I think of it more like API in a box.

Re: A Poor Man's API

#84

Post by [deleted] »

beachy wrote: post #18
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.

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.

[deleted]

Re: A Poor Man's API

#85

Post by selcuka »

langsoul-com wrote: post #61
selcuka wrote: post #15

Earlier quoted context omitted.

Fly supports PostgreSQL [1], but it's not managed as you would expect. [1] https://fly.io/docs/postgres/getting-started/what-you-should...

Use Laravel to generate the api. The boilerplate get you 90% of the way. Host laravel and pgsql on fly for free. Could do other things like directus (handles the api gen), planetscale has free mysql tier or even using airtable as the db, it provides the api part.

Sorry, what I meant by "not managed" was they just support PostgreSQL as in "yet another executable running on their containers", so they don't actually optimise or configure PostgreSQL for you.

I find Eloquent's approach to disconnect models from migrations a bit dangerous, but it could be me as I don't have much experience with Laravel. PlanetScale/Vitess doesn't support foreign keys, which is nice for distributed (planet scale, ha!) apps, but could be a problem for certain types of applications. I'd rather stick with (stock-ish) PostgreSQL.

Re: A Poor Man's API

#86

Post by tasuki »

beachy wrote: post #18
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.

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.

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?

Re: A Poor Man's API

#87

Post by jagged-chisel »

dmitriid wrote: post #41
EdwardDiego wrote: post #29

Earlier quoted context omitted.

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…

> who used MyISAM I remember reading "High-Performance MySQL" in mid-200s. It was a real eye-opener: all the things you needed from a DB where somewhat randomly available across the different storage mechanisms, but not in any consistent form. Something like: Oh, you need query optimisation? Use one. You need constraints? Use the other. you need fast indexes? Use the first one again. And so on. > Ah, the "good" ol da…

> mid-200s

I am astounded to learn MySQL predates so much technological advancement! >.<

Re: A Poor Man's API

#88

Post by layer8 »

Aeolun wrote: post #73
quickthrower2 wrote: post #52

Earlier quoted context omitted.

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.

No contradiction at all. Imagine a relational database where the only column type is a variant (union) of the usual datatypes, and where new tables and new columns are auto-created whenever an insert/update references them (and, possibly, unused tables and columns are garbage-collected). You’d still use regular SQL and have joins and everything, the tables would still be relations, but there’s no defined schema.

Re: A Poor Man's API

#89

Post by oogali »

411111111111111 wrote: post #69
maartenh wrote: post #67

Hm, using Apache APISIX for DDoS protection on a single node? That won't really stop a real DDoS. Not much you can do on a single server, if a botnet is saturating the network links to your server(s), without help from your infra provider. This setup can be used to prevent the backends from being overloaded, which one can probably already do from a single host, and depending on the speed/amount of work by the backend…

Hasn't DDoS protection always been a small misnomer? You can't really protect against it, you can only have enough bandwidth to handle everything.

The root of the issue has always been the definition of DDoS.

Network engineers define it as one thing: a massive amount of abnormal traffic generated by a large number of sources (distributed) that you need adequate bandwidth to soak up without impacting normal traffic.

Software engineers define it as another thing: unwanted traffic that causes resource exhaustion and should be blocked. They're almost always thinking of DoS but refer to it as DDoS.

That's why when TFA talks about DDoS, the example immediately attached to it is rate limiting at what to me (network engineering background) seems like an absurdly low limit (1 request every 5 seconds).

Re: A Poor Man's API

#90

Post by criddell »

tasuki wrote: post #86
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.

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.

Post reply on HN