1. 10
  1.  

  2. 3

    Hi! I’m finding this super interesting. Like 80% of the work to get a working prototype of an app is the installation of a DB and coding the ORM plus REST in order to access it from the outside and packaging it. Getting it on a container is even more convenient.

    I’ve read the PostgREST docs for the motivation but since you’re the author of the docker wrapper I’d appreciate if you can expand on it a bit more. Did you develop this to scratch your own itch? Which use cases do you have in mind?

    A quick question, I’m not an expert on Postgres. Does the starter kit provide any kind of redundancy or are all containers, well, self-contained? (REST + DB for each instance, data is not shared)

    1. 4

      @carlesfe Thanks for the questions. First of, a small correction. Although I’ve wrote a lot of the core code in PostgREST and have been involved in the project for almost 2 years, I am not the author, Joe Nelson is.

      Before i got involved in the project (2015) I had a similar prototype in Lua which i started developing as you said to “scratch an itch”. I was looking around for something similar, came across PostgREST, liked that it is in Haskell and decided to contribute to it rather then develop a separate thing. Another contributing factor was the emerging of GraphQL (there were only roomers back then) and i though i could get PostgREST to a point where it could be base for a GraphQL backend server ( which i did :) https://subzero.cloud/ )

      The usecases are every API that is primarily talking to a database (reading writing data) which i think are the majority (other actions like talking to 3rd party systems, sending emails, notifications … are still possible).

      This starter kit is a first of all a “dev env” setup to make it easier to iterate on your PostgREST based project which is a major obstacle for new users. When going to production, your db will be in something like RDS while the other components (openresty/postgrest) will run as containers (or not). Openresty and postgrest are stateless so you can run as many instances as you like for redundancy.