Live data from Hacker News

A Poor Man's API

blog.frankel.ch

61–70 of 127 posts

Re: A Poor Man's API

#61
post #15

Earlier quoted context omitted.

No free psql tier

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.

Re: A Poor Man's API

#62

Reminds me of datasette, which does similar things for SQLite (and much more, too). Docs at https://docs.datasette.io/en/stable/json_api.html Example: Retrieve JSON for https://fivethirtyeight.datasettes.com/polls/president_prima... simply with https://covid-19.datasettes.com/covid/ny_times_us_counties.j... (I added a filter for Texas)

Big problems with the design of the response here, too. Example: https://fivethirtyeight.datasettes.com/polls/president_prima...

The schema is ad-hoc and requires a human to interpret it. Link relations (at the bottom) are expressed the wrong way: a machine could understand the "next" or "license" relations, but not an arbitrary "next_url" or "license_url" JSON key.

Recommendation: adopt relevant IETF/IANA standards and reformulate the response to take advantage of them.

Re: A Poor Man's API

#63
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.

Absolutely. It is shameful how much stuff needs to be run before you can even get started.

Just be thankful javascript isn't involved!

Re: A Poor Man's API

#64

This is far from what I'd call "poor man's" thing. I'd want to host it for free, so Vercel and Netlify comes to my mind. But to go real poor man style, I'd use Google sheets as a backend and throw some caching layer on top of it. Firebase or one of its competitors is also a good idea to get some API up and running for free.

Stick it on the Render free or cheap tier. Or Supabase for free in just a single click: https://supabase.com/pricing You're better off starting with Postgres than having to migrate from some kind of no-sql setup later.

I'd love to have the migration problem because it indicates what I'm building has something to it.

If nobody uses it then no regrets doing it stupid fast.

Re: A Poor Man's API

#65
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.

API Bakery requires a user to tediously and manually replicate the DB schema. In my eyes, that makes it worse than the solution under discussion.

Re: A Poor Man's API

#66
post #65
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.

API Bakery requires a user to tediously and manually replicate the DB schema. In my eyes, that makes it worse than the solution under discussion.

Oh if you have a database already and want to expose it, then yeah, it does make sense to go with the API adapter bolted onto it.

If you're starting from scratch (as the post is, since PostgreSQL is advertised as part of the solution), then you have to manually create the DB schema. I would argue that a Node developer would find it easier to do that in Prisma, or a Django developer in Django ORM, than to do raw CREATE TABLE queries manually.

Re: A Poor Man's API

#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 backends done, not a lot of bandwidth is required to overload most systems that have a limited amount of request processing capacity.

I would argue that this is load management/shedding though, and not DDoS protection.

Re: A Poor Man's API

#68

> 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 using serverless functions – or an API written in code.

Personally I err to the side of just writing some code, maybe because I enjoy that part of the project. Then I might be more inclined to use no-code solutions for the frontend, where others want the freedom and flexibility.

Re: A Poor Man's API

#69

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.

Re: A Poor Man's API

#70

Earlier quoted context omitted.

Stick it on the Render free or cheap tier. Or Supabase for free in just a single click: https://supabase.com/pricing You're better off starting with Postgres than having to migrate from some kind of no-sql setup later.

I'd love to have the migration problem because it indicates what I'm building has something to it. If nobody uses it then no regrets doing it stupid fast.

It's more than just a migrating issue, it's thinking about the structure of your data from the beginning. Your data is your application. Web framework flavor of the day should be a secondary consideration.
Post reply on HN