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)
@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.
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)
@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.