Docker Integration

Hi,

I like the idea of this project, and I notice in your roadmap you have Docker as one of the upcoming features.

I've done this sort of stuff a few times so would love to take a crack at it, if that's okay? I'd submit a PR with:

A Dockerfile for the front end, in the front end directory
A Dockerfile for the back end, in the back end directory
A docker-compose in the root of the repository, that brings up both and somehow links them together.

Maybe with the docker-compose running the apps in dev/hot reload mode, but have the Dockerfiles build "production" images in a separate, final stage.

How does that sound?

Hey! Thanks for reaching out. Yes, this is something I do have on my roadmap 😃.

That sounds like a fine plan. To confirm we're on the same page, what image will you be basing on for the frontend? Is it nginx? Asking because I'm only familiar with nginx so, if it's something else, I'll have some reading up to do.

Go ahead. I'll assign this to you. Let me know if you need any pointers in navigating the codebase.

PS: I'm told by my peers that I'm quite a bit picky when doing code-reviews. Just a heads-up. 😬

For the development image I'd recommend we base off an official NodeJS image, as it looks like you use parcel to hot reload the files and run it -

prestige/makefile

Line 53 in c74d34a

npx parcel serve src/index.html --dist-dir dist-serve --port 3040

For production, I suppose it depends on you're hosting the app at the moment, is it static files hosted on Netlify? If so, nginx could work, or maybe Docker ought to be just for development purposes?

Ah interesting. I didn't realize we'd have a separate Dockerfile for development. Yeah that would require NodeJS to run Parcel.

For production, you are right. It's just a bunch of static files, built with Parcel, hosted on Netlify. Docker images for prod is actually what intended when I added that line to the Roadmap. So I'd say the development Dockerfiles are optional, but we'd want the production ones.

Hey @sharat87, wanted to let you know I haven't forgotten about this 😄

Taken a look this morning, I've got the frontend working but the backend isn't quite working yet. I've got some ideas on how to get it working.

Can I just check these assumptions are right before I go down any rabbit holes:

The app runs on Heroku, using the release and web processes in the Procfile
The app needs a Postgres DB to run
The app uses Gunicorn

Also what's a good way of checking the API is working? Do you have some sample requests I could use? I can see on your deployment there's a auth check (GET /api/auth/profile), maybe that would be a good one?

Hey @MattTennison, thanks for dropping an update, I was wondering about this myself 😄.

Regarding your assumptions,

Correct. But I'd rather the Dockerfile have nothing to do with the fact that production runs on Heroku today. I'm considering (haven't decided) moving to ECS soon so I'd want the Dockerfile to be self-sufficient.
There is a Postgres database configured for some upcoming features, but it's not used currently. The Dockerfile shouldn't be bothered with this, and in the docker-compose.yml also, let's not add a Postgres just yet. The backend works happily with SQLite just as well today, and that could be the one for dev environments with the docker-compose.yml.
GUnicorn is a production-ready server that I chose based on Heroku's recommendations. I think it's the best choice to be used in Dockerfile as well. But I'll let you explore more if you're so inclined :)

For health check, yeah, let's use the /api/auth/profile only for now, but I'd want a /health endpoint that responds with ok as the response body later on. Not important right now though.

Closing this since a Dockerfile is now part of the project, and it includes frontend, backend as well as docs in it.