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.
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.
Query Parameters in Flask-Restplus
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.
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.
Travis CI/CD Unit Tests
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.
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.
RSS Feed
