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.
A Poor Man's API
21–30 of 127 posts
Re: A Poor Man's API
#22Re: A Poor Man's API
#23Ehh this seems more annoying than just writing an MVP in (your language of choice) given you already have the expertise.
Personally, I’d give a shout for https://api-platform.com/.
Re: A Poor Man's API
#24Not to be mean, but from my reading this needs Heroku free tier which no longer exists? I am very sorry if I got that wrong.
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.
Re: A Poor Man's API
#25> 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.
REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
Re: A Poor Man's API
#26Earlier quoted context omitted.
Grafana and Prometheus aren't necessary, and Docker is at this point pretty close to a Linux platform feature. APISIX is a reasonable complaint --- the "poor man's API" is "using a big open source project that provides generic APIs", sure, that's not all that clever.
The goal was simplicity and cheapness, not being clever. Using a simple, existing tool is better than unnecessary complication, no?
Re: A Poor Man's API
#27Not to be mean, but from my reading this needs Heroku free tier which no longer exists? I am very sorry if I got that wrong.
NKOTB: https://neon.tech/ Free Tier includes: compute up to 1 vCPU / 256 MB storage up to 10 GiB 3 projects per user
Nikita, their CEO, was a guest on the Changelog[0] podcast a month or so ago. Well worth a listen, great episode.
Re: A Poor Man's API
#28Check 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.
Re: A Poor Man's API
#29Check 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.
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 because MSDN was inadequate, and the source was very much not open.
PHP 4 code bases that heavily leaned on dangerous globals.
J2EE.
Ah, the "good" ol days.
Re: A Poor Man's API
#30> 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.
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?