If the point of the api is to get data in an out of the db, you could use PostgREST (also haskell :))
Not a great idea since you’ll usually want to extend it, gate access, do various other things and putting that logic in your database is fraught.
That’s a dismissive comment. Have you actually looked at PostgREST?
Here’s what I’ve found from two months of hacking on a project built on it:
I won’t be surprised if I hit pain points if this project becomes a hit and grows to be huge… but from here, that day feels like a long way away, and PostgREST feels really valuable.
(edited to clarify a point)
My comment was not intended as “the thing the article describes is not that good, try this”. The article describes a traditional way of building a rest api, it just happens to be in Haskell, nothing controversial about that. Since it’s traditional, of course it works and there is nothing wrong with it, but since the example shown was about how to get data in and out the db, it’s a good place to use PostgREST. It’s also ok that people dismiss it, the docs do not explain (yet) “the big picture” and how postgrest is only a part of the new stack, not the whole stack. The only objection i have to your comment is the part about “logic in the db” :) because that’s not dismissive of postgrest but of the databases in general (postgresql). Literally decades of work have gone into implementing views/stored procedures/triggers/role system/rls … and you are basically saying that was all for nothing since “putting that logic in your database is fraught” :) If the logic is very closely related to the data being handled, the database is exactly the place to put it.