Adding Docker

[abhinavtripathy]

I was wondering if the repo would benefit from dockerizing. I was thinking if this would help with local development and deployment. Would love more inputs on this! I don't want to jump on scaling or using tools that we don't need right now. Any thoughts @abesto @keenanjohnson ?

[abesto]

My 2c: all else being equal, as a rule of thumb, stuffing backend things inside Docker is a Good Idea. However! For this repo in particular:

• Deployment is to Heroku. I can't comment on how convenient or stable that setup is (because I don't have access to Ribbit infra, which is as it should be, since I'm not a core team member). That said: assuming it's in roughly a good place, adding on Docker to run on Heroku makes operations more complex, not less.
• For local development, IMHO currently the biggest painpoint is not system-level dependencies (which is where Docker shines), but Python package management. So to improve the devenv, I'd recommend attacking #82 first.

[abesto]

Oh, one more thing: a big value of a Docker-based local devenv is codifying local infrastructure: test database, cache server, backend / frontend / api server processes, wiring all these up, etc. Now, there are no locally running infrastructure pieces here currently. When you run locally, your development server accesses the production database. There's no local cache instance, there's no local nothing. So we don't gain a whole lot on that front either.

[keenanjohnson]

I know @YoungiiJC was also interested in this.

FYI we're not tied to Heroku a deployment tool, but it is free for us to use today which is nice :)

I'm generally a fan of using docker if it is less painful than configuring the dev env. otherwise (for example, I develop with ROS in this way using VSCode Workspaces). However, things like ROS or an active service have a lot more moving parts than Ribbit Network does today (maybe that won't be true in the future once we have a proper Ribbit API: #64 )

Here are my thoughts and I'm onboard if people feel like there are reasonable wins or ways to mitigate the cons from my experience.

Pros:

• Once it's up and running, it removes a whole category of "works on my machine" for things like specifying python / OS versions, etc

Cons:

• Getting people to install and setup docker + the daemon is almost as painful as getting people to configure python virtual env for example. Perhaps I"m just a newb at teaching people how to do it though.
• Building a docker container takes much longer
• Docker requires your local computer to have a lot more resources (memory, disk space), so it does somewhat limit access for people to contribute.

[abhinavtripathy]

Thank you for the comments @abesto @keenanjohnson . It is clear to me that as of now, we probably should do something like poetry rather than docker. @keenanjohnson can you assign the poetry issue to me, unless someone else is doing it. I would be happy to take it on.

[fosteman]

Docker may be a good idea for the API, obviously not for the dashboard.