1. 11

  2. 5

    If the point of the api is to get data in an out of the db, you could use PostgREST (also haskell :))

    1. 1

      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.

      1. 3

        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:

        • Extend it: I haven’t found myself held back while adding features like OAuth for authentication and a Places Search that talks to Nominatium. I haven’t found anything about PostgREST that makes this harder. I still write back-end code, PostgREST just takes care of the data stuff.
        • Gate access: PostgreSQL actually has great authorization features via roles, including Row Level Security. I’m actually finding myself feeling much happier about my the security of my data now that I’m writing rules in declarative SQL, instead of manually writing app logic. Recent comment
        • do various other things and putting that logic: I mean, sure, I have a login function as a Stored Procedure. The horror! It’s 8 lines of nicely-formatted plpgsql. I have an autocomplete endpoint that does some pretty smart querying as a Stored Procedure, which is longer, but is just a plain parameterizied sql query.

        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)

        1. 1

          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.