The Area is an automation platform, similar to IFTTT or Zapier, which enables users to connect different services, letting an event in one automatically trigger a reaction in another. It consists of three main parts: a server that runs the core logic, a web app where users can access and manage their automations, and a mobile app that offers the same functionality on the go. Together, these components provide a simple and flexible way for users to create and control automated workflows across multiple services.
In order to realize the project, we considered multiple technologies, and thus decided to test them. We listed each of them in the considerations folder, each having their own sub-folders. For every consideration we would create a branch for it, and do a basic tutorial for said consideration. While we would do the tutorial, every person would note some information about the technologie they’re testing, such as how the language felt as a whole or how it could help us upgrade our workflow. Once all that was done, we would create a markdown file for said technologies that would answer all questions and include other information such as the language utility or who in our group had knowledge about this. Once all that was done, we would create a pull request, and ask for at least one persons to review it. They would try the considerations and if it reached what was expected, it would be merged towards the main.
Once that was done, we selected the technologies we preferred and made a POC with them. The POC included a connection page, an OAuth connection and an application that uses the OAuth connection.
For our frontend technologies, we will expand more on React, Vue and Angular.
Of all the frameworks we tried, React is the one where our group has the most experience. While Angular and React are as complete as each other, our additional knowledge of the latter will make for a smoother development. It is to be noted that while slightly harder than Vue, it retains its compatibility with capacitor and our overall higher with it means that the difference is only relative. Thus, we decided to lean towards React as the frontend for our web application.
For our backtend technologies, we will expand more on fastAPI, Express and Flask.
When it comes down to the backend, we let ourselves the choice between Express, Flask and FastAPI. Off the three we decided to go with FastAPI due to iteration speed, and its high versatility in constructing API. We also already build multiple projects with it, including the survivor jeb project. It is also more structured than Express and less limited than Flask.
For our backtend technologies, we will expand more on React + capacitor, Flutter and Kotlin.
In the end our choice went to React combined with capacitor. While it doesn’t have the first class support of Flutter, nor that of Kotlin; our superior knowledge of it is a decent point in its favor. On top of that, the fact that it is React means that it will have a good synergy with our web frontend and will potentially allow us to share some components. Additionally, the ease of installation is a very good point for the different environment our team possesses.
For our backtend technologies, we will expand more on MongoDB, SQLAlchemy and SQLite.
For our database, we decided to lean towards SQLAlchemy. To begin with, it offers a better resilience than MongoDB, a very important factor for a database. We chose it over SQLite due to its scalability, making it better at creating bigger apps.
See ./security_audit.md
In the end, we chose to work with fastAPI,SQLAlchemy and react alongside capacitor. We chose to do so because this is the most adapted stack for our team, while being resilient and easy to use.