Although I realize that this may be out of scope for this project, I wonder if postgrest can be modified to provide an option (--static-dir) to serve a custom directory containing static assets (HTML, css, JS).
I would like to use postgrest on Heroku and access it straight from JavaScript (actually, Elm). I would like to run just a single web process for all of this. Normally postgrest is run as "web1" and the static files are served via warp as "web2" - but the later is redundant, and Heroku's free tire supports running single node only.
Another option is to write a small Scotty server and somehow invoke this, while mapping /static/ to serve local files. I'm not greatly experienced with Haskell, but will poke around this option now ...
It actually shouldn't be too hard to implement, just a change in
https://github.com/begriffs/postgrest/blob/master/src/Main.hs#L55
There was some discussion about it in #136 - what's your opinion about the topics raised there?
I don't have a strong opinion either way with respect to the general production use case. I'm only trying to get postgrest up and running for my personal projects (based on self-tracking) where nobody but me would be using the system.
I'm taking baby steps, by first getting postgrest working against Heroku database. The road block I'm hitting is trying to understand and configure the auth system. The configuration seems complicated for my use case. I executed the SQL under "Example scenarios" and the scenario I'm looking for is read-write access to only single user. So much to understand ...
Now I see that it makes sense to let PostgREST focus on providing the REST API - and let nginx or a CDN serve the static assets.
That guy has it. This seems to be an unnecessary bit of complexity given that the deploy should always involve a frontend webserver capable of TLS.
Would like to see this feature just for the development phase where the development occurs on the localhost machine.
It's convenient to have both the API and static resources served from the same URL. Example: create database, start postgrest, write an index.html (hopefully with autoreload on change functionality), query the API from the index.html.
Once deployed, that static/ directory can of course be served by an nginx instance. It's very typical development flow when using other environments such as ExpressJS.
How about a nice copy-and-paste example in the docs of an nginx config file for this use case?
I could, but I don't want/should not need to have to setup nginx on my desktop. What I end up doing is running autoreload-server npm package. It watches for updates to files and reloads the page (websocket connection) and serves it on a separate port. It's convenient; it would be even more convenient if postgrest did this out of the box.
I'm going to be blunt: I don't see why you "should not need to have to setup nginx on my desktop" when you need a feature that nginx has and is best suited for.
I don't want PostgREST to be anything but a REST API server for my PostgreSQL database. Any effort put into re-creating nginx functionality detracts from its core purpose.
@rngadam I empathize with you that installing a reverse proxy on a dev machine might sound intimidating/annoying, but as @PierreRochard says, it's a nice separation of concerns that helps postgrest stay lean.
Installation shouldn't be so bad though - there are packages for linux and brew install nginx should do it on mac (mac howto).
A better option is to just have docker on you dev box (useful in lots of ways) then it will be very easy to start nginx/postgrest from docker, you will just need to have one config file on your disk, no need to install anything else (we can provide that config file in the docs or separate repo).
hey guys sorry to bother and thanks for PostgREST I just want to say I add a static file server in my fork PostgRESTui in case anyone interested
Most helpful comment
A better option is to just have docker on you dev box (useful in lots of ways) then it will be very easy to start nginx/postgrest from docker, you will just need to have one config file on your disk, no need to install anything else (we can provide that config file in the docs or separate repo).