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

91–100 of 127 posts

Re: A Poor Man's API

#91

Post by sdiacom »

jagged-chisel wrote: post #87
dmitriid wrote: post #41

Earlier quoted context omitted.

> 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! >.<

The code base certainly looks the part.

Re: A Poor Man's API

#92

Post by falcolas »

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?

There are, but they’re pretty niche because their performance is really bad. Niche enough I can’t recall a single name today.

But really, my advice for early prototyping is split in two: either keep it in memory and serialize to disk, or use SQLite.

Note that even using serialized memory constructs will require data migrations, aka schema updates.

Re: A Poor Man's API

#93

Post by falcolas »

siscia wrote: post #57

Maybe I am biased, but at this point I would find simpler to just give access to the DB. Let user write their own SQL queries and meter how much time they use for billing or abuse prevention.

Did you know that databases can read from disk?

Databases are huge security vulnerabilities and should always have some kind of shim over them. Never expose your relational DB publicly if you want any control over it.

Re: A Poor Man's API

#94

Post by [deleted] »

blowski wrote: post #81
cpursley wrote: post #77

Earlier quoted context omitted.

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.

[deleted]

Re: A Poor Man's API

#95

Post by cpursley »

blowski wrote: post #81
cpursley wrote: post #77

Earlier quoted context omitted.

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.

FWIW: https://github.com/supabase-community/supabase-rb

Re: A Poor Man's API

#96

Post by bee_rider »

jagged-chisel wrote: post #87
dmitriid wrote: post #41

Earlier quoted context omitted.

> 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! >.<

Pretty sure they mean mid-2000’s. So actually MySQL won’t be invented for another 480 years or so.

Re: A Poor Man's API

#97

Post by bee_rider »

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.

“Mitigation” would probably be a better name (and sounds fancier, but maybe not as definitive).

Re: A Poor Man's API

#98

Post by giraffe_lady »

cpursley wrote: post #72
madsbuch wrote: post #68

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

Does supabase do anything particular to address those or just hand you postgres's RLS? It's been a minute since I used supabase but when I last did you were basically on your own with that.

Which is not necessarily bad, RLS is sophisticated enough to handle all real world cases I've come across. But if it's just that I think it's more correct to say postgres already handles all of this.

Re: A Poor Man's API

#99

Post by giraffe_lady »

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?

Yeah it's postgres's jsonb type.

Re: A Poor Man's API

#100

Post by giraffe_lady »

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.

It's not necessarily my preference but the last few years a lot of my work has been in systems that are just a thin api wrapper around postgres.

In practice the biggest issues with it are that the tooling is significantly behind the state of the art of mainstream dev tooling, both for working engineers and ops. It's also not built with this with style of working in mind, so you accumulate a lot of little struggles that are hard on engineering morale and confidence in the deployed system. DBAs have their own practices, but admin is a different discipline from dev and they aren't always directly compatible.

The other problem is that for most modestly sized money-making applications, the database is the single most resource-intensive and expensive necessary part of the stack. Putting a bunch of business logic in there will never help that, and query optimization is a difficult to acquire skill. You pretty much always end up with just a couple of people who can talk the query planner down off a cliff when you get into the shit.

Post reply on HN