A while ago I began trying to dockerise the moodster API application and it was quite difficult to get started as the project was already under way and I wasn't that experienced with Docker at the time.

Since I'm re-writing the Moodster API I decided I should start off with dockerisation and bake it straight into my development process.

Fortunately the FastAPI documentation already comes with pre-built examples and docker containers for running FastAPI in Docker.

One of the main reasons I've been wanting to do this is that I've recently been looking into the 12 factor app. The 12 factor app is essentially a set of guidelines for how to develop applications that are to be ran as services.

The guidelines in place are to allow you to create services which are as maintainable and scalable as possible. The rule in particular that has driven me to do dockerisation of moodster is called Dev/Prod Parity. This essentially says that the development, staging and production environments should be as similar as possible.

In the Flask-Restplus version of the Moodster API I was using sqlite for development and then I was using PostgresSQL for the unit tests and eventually for deployment. This caused me issues from the off where I was hitting issues with differences between how Postgres and sqlite worked with SQLAlchemy and database migrations. It also made the configuration more confusing as I was having to override lots of things depending on dev vs testing. This is not ideal!

The dockerisation has gone fairly smoothly and I now use docker in development. This allows me to just use Postgres for all the environments and it's just another thing that I now don't have to worry about.

I did find that it slowed some development speed initially but now that I'm used to the docker commands a lot more it's no longer a barrier. Also the amount of time it is going to save me when it comes to deployment means it will be well worth it.

​Cheers

So the API part of the Moodster project is really coming under way. I've realised that altough the initial size of the original MVP was small there is still a hell of a lot of functionality required to even get those implemented. 

Even with that simple functionality there is still 5+ Database Tables/Models that are needed to make this flexible enough to expand on at a later date.

Although Flask-Restplus is really simple for Parsing payload data and also for marshalling the responses as a model it really suffers with things such as Query Parameters. Looking at the documentation there seems to be what is now a deprected ReqParse module which can be used to do this but I am not a fan of using deprecated functionality.

The alternative and what seems to be suggested online is to use Marshmallow to do this serialisation/marshalling instead. The documentation however doesn't really give you a jumpstart on how to use the Marshmallow in Flask-Restplus.

I'm not 100% on what I want to do here but I think it's something I need to sort out pretty soon.

One thing I've found useful whilst doing this project is to have a travis pipeline setup which will run all my unit tests and ensure that I've not regressed any functionality when doing a Pull Request(PR). I've been really keen to start this project off the right way, and blocking merges based on unit tests seems the right way to go.

Also for this reason I've been making sure I am writing all my unit tests for the new functionality I am creating before even creating a pull request. I've also added the "build passing" Travis badge to the README to make the project look that little extra professional.

I am going to look into adding test coverage soon, I really want to make sure that the project follows as many best practices as I can to give it the best chance to be successful once it's released into the wild. If I see an open source project on Github and I see that It doesn't have any tests or coverage I tend to try and steer clear or at least opt for one that does.

Hoping to keep momentum high!

Here's a link to the Project, if you want to take a look.