Usman Sadiq

We will be using git for version control. In particular, we chose GitHub as it is the largest platform for version control. It integrates really well with several applications such as Heroku through Heroku’s command-line interface which will make it efficient and less time-consuming.

We will use Visual Studio Code as our text editor due to its great support for web development. It is a very fast editor which aids the developer in using proper syntax hence cutting down time spent on programming.

For communication, we chose Slack as it will let us collaborate effectively and coordinate our work from anywhere. With features such as impromptu video and voice chats as well as quick polls, Slack is great for quick questions and decisions and keeping everyone feel connected and in sync over time.

We will be using JavaScript and ReactJS on the frontend. React consumes much less development time in creating the user interface as it allows us to write modular and clean code which can then be reused later on. This modular code also allows us to easily maintain and update the application. React also creates declarative user interfaces which can result in more engaging and interactive user interfaces hence improving user experience. Furthermore, with features such as virtual DOM and server-side rendering, we can create applications that are really fast. Compared to Angular, React’s data synchronization process between Model and View is unidirectional which means bindings are not assigned watchers. This results in no additional workload created. React is also one of the most popular JavaScript frameworks worldwide and has a strong community supporting it. The flexibility offered in which structure to choose for the application also sets React apart

MongoDB's document-oriented paradigm is nicely suited to the results of our ML model. We felt that this compatibility offered some time savings on figuring out and implementing an extensive data formatting and processing system. MongoDB's flexible schemas schemas (due to it being non-relational) were also attractive as a source of additional agility for our development process. The MongoDB ecosystem also has great GUI tools to simplify testing.

We chose PostgreSQL as our database due to it being relational. Given that our data is structured and limited, it would be easier to build schemas, divide the data into categories and define relationships between data points. These relationships will have constraints which will promote a high level of data integrity. Moreover, it is very easy to navigate around the database and join the tables to get whatever we desire. Our data would also comfortably fit in rows and columns and the data transactions would be very secure which makes a relational database a better choice. We picked PostgreSQL as the relational database because it is fast, it supports a wide array of extensions, and has high scalability. Being an object-relational database, PostgreSQL includes features like table-inheritance and function-overloading which will be beneficial. In addition to that, all of the team members have prior experience in using it. It is also very easy to connect the database to Python on the back-end with pyodbc which makes it extremely easy to work with.

We chose Python as the primary language on the back end as it is easily readable, user-friendly, versatile, and has strong cross-platform compatibility. Due to it having a large and active developer community, it also has many libraries available which would cut down on time spent manually building everything from scratch. Most modern human pose estimation technologies are implemented in Python, so since much of our project revolves around pose estimation, using the same language for other components of our application will make it easier to integrate everything. In addition to that, Python is easily extensible as it has a number of web application frameworks. Python’s maturity is also attractive from the perspective of long-term support. Moreover, our team has a strong background in Python which means we would not have to spend time learning it from scratch.

The web framework we chose is Django due to its speed, safety, and stability. Django is very stable and robust and was created for fast development of complex web applications. Furthermore, Django has been around for a long time which means it has a number of extensions, plugins, and third-party applications.

We will be using Gunicorn as our WSGI application server. Gunicorn would handle everything that happens between the web server and the web application. This means that it will take care of reacting to a lot of web requests and distributing the load accordingly, communicating with the web-server, and keeping multiple processes running for the application. Therefore, the deployment will be more stable as well as be fast and handle more requests at once. Gunicorn is also the recommended HTTP server for use with Django on Heroku. It can run multiple Python concurrent processes within a single dyno which makes it the superior choice.

We decided to migrate our web framework from Django to Flask for a number of reasons. Firstly, Flask is a light-weight framework which makes it easier to use for simpler cases and to build a quick prototype. It gives developers full freedom for what they want their application to look like. With a coherent and neat API, Flask allows easy and flexible configurations along with integrated unit testing support which makes it a great tool. By using Flask, a simple application can be later changed to add more functionality and make it complex. It provides flexibility to expand the application quickly which is harder to do with Django where requirements change dynamically. Moreover, Flask is a minimal yet powerful platform with easy database integration which gives us the opportunity to easily develop and maintain applications. On the other hand, Django has a high learning curve and is a higher entry point for simple solutions. In addition to that, Django requires roughly more than 2 times more lines of code than Flask for the same functionality. Django is suited for bigger projects that need a lot of functionality. For simpler projects like our application, the features might be an overkill. Putting all these factors into consideration, we decided it was best to switch to Flask from Django

We plan to use OpenCV due to its clear leadership among computer vision libraries, and due to most modern human pose estimation technologies being built on top of it. It is one of the largest computer vision libraries available which can be incorporated with a number of open-source languages. Moreover, OpenPose has the additional advantage of simple integration with several mature numerical analysis libraries like numpy, which will support the continuous addition and improvement of pose-estimation-based analysis features in our application.

For our cloud platform, we will be using Heroku. Heroku allows us to focus on the code and innovation rather than the infrastructure and operations, and have a unified dashboard for the team, hence improving the team’s productivity. It also has broad support for many modern technologies, making it easy to integrate whatever building blocks might be required for our application. Moreover, a strong command-line interface makes it easy and quick to use.

In order to store our videos, we will be using Amazon S3, a very durable and accessible storage service which integrates cleanly with Heroku. It is a secure object storage platform with a simple web service interface that can store and retrieve any amount of data at any time. This will make it extremely easy to store a large number of files on Amazon S3 and use them with Heroku when needed. Furthermore, it lets us preserve, retrieve and restore every version of every object in the bucket which would be beneficial for getting older versions of our data if needed. There are also many options for cloud data migration which makes it simple to transfer large amounts of data to Amazon S3 or out of Amazon S3

There are two main reasons for changing our storage provider. First, Cloudinary’s setup appears to be much simpler than that of Amazon S3. This was important to us given our lack of prior experience with either service. Second of all, Cloudinary's free tier is very attractive, giving us many times more storage than Amazon S3. We felt this was important given how space-intensive our libraries of uploaded videos might turn out to be. An honorable mention: Cloudinary's API and docs also appeared to be less overwhelming, allowing us to be more agile in the development process.

Given that we gained significant experience with the MERN stack in the past several weeks via another project, we decided to prioritize our experience over theoretical comparisons of merit. This move also permitted us to to reduce our stack's complexity by replacing two tools with one. Moreover, Express is battle-tested whereas Flask is a somewhat less mature library.