Skip to main content

Technical Decisions

Table of Contents

Outstanding decisions to review and discuss:

XX/XX/XX - Topic#

N/A

March 2020 - Why Development Backend is hosted on Heroku?#

We were using AWS, but the Backend stopped working (500 error) after one specific deploy, which we could not investigate due to not having appropriate access for it (AnitaB.org IT team has the credentials). So Isabel decided to deploy it on Heroku, so we could continue having a Swagger UI endpoint for the REST API that people could access it for testing purposes. So until we have proper access to AWS, we are using Heroku.

August 2018 - Why use AWS?#

AWS is being used since other previous projects were using AWS as well, such as systers/portal. Although other projects in the community use Heroku.

July 2018 - Tasks data model implementation#

Due to concerns regarding a problem of scalability with saving Tasks into the relational database as an entity, we identified the potential issue.

Problem: Tasks of a mentorship relation are easy to grow in number. Let's imagine at a certain time in the future we have 500 relations and each of them having 50 tasks (50 per each relation). That’s in total 500*50 tasks scattered through the Tasks table, and to get tasks from a specific current relation, a cursor will have to iterate over the whole table. This causes a scalability issue.

Potential solution: We agreed that we would search a solution for this besides saving as a string.

After some research about this Isabel found that SQLAlchemy allows to use of JSON objects, and MySQL since version 5.7 allows this to happen:

Here's Task Scalability Google Docs where Isabel tried to document a discussion at the time with mentors. We decided to go with JSON format to store the tasks list, but we agreed to review this model later after GSoC.

Some ideas were thrown since then: Using Postgres directly instead of the SQLAlchemy abstraction, using indexing, creating the Tasks model anyways?!

By the way, this was implemented on PR #128.

May 2018 - Why use Flask framework?#

The GSoC student did not have experience with backend and the mentors had experience with python. One of the mentors suggested Flask framework since it was fairly simple to pick up and quickly bootstrap a REST API application.

May 2018 - Why use Flask-RESTPlus?#

Flask-RESTPlus is the core of this backend. The REST API is built using this flask extension. The main advantage is that it supports Swagger Documentation. With this tool, we can develop the API while using annotations that help to generate the Swagger UI.

You can know more about how to use Swagger in this page.

May 2018 - Why use Flask-JWT-Extended instead of just Flask-JWT?#

Flask-JWT-Extended provides great support for JSON Web Tokens (JWT) based Authentication. It provides a lot of flexibility

You can learn more about how User Authentication is done in this project.

Initially, we started using Flask-JWT, but as the development progressed we started having challenges to solve that required a more flexible library. One of the issues that made us change to Flask-jwt-extended was the need for extra verifications while login in a User into the system, specifically verifying if the user had the email verified. After looking into flask-jwt source code and docs to see if this could be done easily the GSoC student concluded that it would require extra work by having to override some functions, as done before, and that this would overcomplicate code. Ultimately, it was agreed with the mentors to use flask-jwt-extended that provided more flexibility to implement the Login API. The official documentation of flask-jwt-extended shows an example of the basic usage of the extension, where it shows the flexibility to verify extra fields and properties and provide custom error messages.

Edit this page