I've completed it!

I have done the 4 required PR's for Hacktoberfest, which means I am eligible for the t-shirt. It actually wasn't as easy as I thought. I could probably have been a bit naughty and broken down my PR's into much smaller pieces of work to try and bump the numbers up, but I would have just been cheating myself out of doing as much work as I have.

So to give a summary of the new functionality I've added to Moodster API over this Hacktoberfest, here are my PR's:

​October 02, 2019 00:44 Added the moods table, including default data.
October 02, 2019 21:31 Added test to cover none type token payloads to
October 18, 2019 18:14 Added team creation deafault admin user
October 19, 2019 16:08 Member mood addition

​So that's it, there has been some great additions there which push the functionality further than what the previous Flask-Restplus verison had. Furthemore I believe that the API is probably now MVP complete. Looking back at the original blog post that laid out the MVP the API has endpoints which would allow the frontend to perform all of those actions.

Next up is to try and push development a bit more on the web/mobile app front to try and get that to MVP.

That's right Digital Oceans Hacktoberfest is just about to kick off!

I'm going to give it a go and use it to motivate me to do some more work on the moodster API.

​I've made some real progress and the FastAPI version of the Moodster API is almost functionality equivalent to the previous version.

Wish me luck!

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

This is not something I normally do and to be quite honest in a work environment I wouldn't do this, but I've decided to re-create Moodster using FastAPI.

FastAPI is a small API focused web framework built on top of a few rather large projects:

• Starlette - An ASGI Web Framework
• Pydantic - Data validation using Type hints

There are a few reasons I've done this:

First of all Flask-Restplus was already giving me issues with data validation as mentioned in this post. They didn't seem to have a proper answer for the correct way to do this yet. On top of that I saw how clean it looked with pydantic to use type hints for data validation.

I have also been hearing about many different web frameworks that are now built with asyncio out of the box and thought it would be a good idea to future proof a little by choosing a framework that was capable of this. Realistically I'm not even going to use the async capabilities straight away as I don't think it's necessary for the scope of the project. It is certainly a plus knowing that it is there if I need to boost performance in that way.

Finally back in this blog post I said one of the reasons I didn't opt for a web framework that was ASGI was due to the lack of the ORM libraries not being async capable. Well the project that the starlette web framework is under also has libraries for async capable ORM's. This final piece put me at ease enough to make the switch.

There is a lot of work ahead essentially re-inventing functionality that already exists but it's also going to give me a chance to do things in a slightly better way as I've learnt quite a bit since starting out the Moodster API project.

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.

I've just started the API portion of the Moodster project and I wanted to talk a little about my decisions for the tech stack.

I've decided I'm going to stick with Python as my language of choice as I have become fairly proficient with it and it does allow you to get things up and running pretty quickly.

I was tempted to try out  Golang for this as I have heard that it is well suited to api's/services. I decided against that in the end opting for something that I already know. This comes back round to the whole idea of trying to actually get something completed.

So I've been listening to the Talk Python To Me lately and heard a hell of a lot about the new async capabilities of python 3. I've been looking around and found Quart, which is a async capable version of the Flask API. 

I've been really tempted to start off with this but I have now decided against it. At the moment of writing there are only some of the Flask Plugins which are guaranteed to work with Quart and I think picking a framework that is still in its infancy could also end up tripping me back in the long run for the benefit of potentially getting some speed increases.

This seems to scream out the old adage "premature optimisation is the root of all evil".

Secondly from what I can see at the moment there doesn't seem to be a great story on using the SQLAlchemy ORM with async which would be the main usecase/potential speed increase for asycn and await.

I've ended up settling on Flask and the Flask-Restplus plugin as my starting point for this project. Flask Restplus gives you some added functionality for pretty much free when concerned with REST API's.

Some of these are:

• Built in OpenAPI Spec Documentation generation.
• Response Marshalling.
• Request Parsing.

That's my overall starting point with this project, who knows what additional plugins/tools I will venture towards later on.