During the course of our software development, we constantly had to consider different types of frameworks and APIs in order to develop our code. So first, we tried to search for already existing projects that in concept shared some similarity with our project.
One of them was the NHS Contraception Choices website which uses a very similar design to what was needed for our project. Therefore, for design, we took inspiration from this website, where based on a questionnaire, the three best-suited methods of contraception would be displayed along with further information about them. The question-box is situated to the left from a list of methods of contraception, all questions within are easy, straightforward and do not require text input. After each given answer, the list of contraception methods changes, so it is easy to see the effect of each answer on the list. The methods that are not suitable don’t disappear but become faded, and there is a ranking algorithm in place that instantly ranks the methods based on the answers provided. This requires a web coding language that allows for information change without the resubmission of the page.
The list of contraceptive methods is very informative, displaying in large the most important pieces of information, such as the photo, and their beneficial quality based on the last response. If we hover over the pictures further information is shown and a link to find out more about the particular contraceptive method.
The other project we looked at was the Decision Support Tool for Academic Advising at Effat University. This tool has a very similar purpose to ours, as it is trying to make student advising more effective and to lessen the pressure on university advisors. This project works similarly to the one by NHS as well, however they deal with a bigger load of information, do a more significant role is afforded to AI.
We ended up implementing a very similar design to the NHS web application, because it suits both the type of data we have, and the amount of information to be processed as well. It ensures a pleasant user experience as well, as every question is easily answerable, and it is possible to explore different combinations of answers to get different courses without reloading the page, so React seemed the appropriate choice for the application.
Since our decision tool was supposed to be in the form of a website, there is a large variety of frameworks to choose from. This includes choosing the correct front end, back end and hosting service. Our choices of software are justified below.
As previously described in the design section of the report, we chose to use React because it is a well-established front end backed by Facebook, so we knew there would be a lot of support and good documentation, which we could refer to if we got stuck. Furthermore, it seemed easier to learn than some other options such as Angular, and is quite efficient due to its virtual DOM. Moreover, using the ‘create-react-app’ meant that we could easily test our app using ‘Jest’, without needing to install any other dependencies. However, the biggest reason we chose react was because some of our team already had experience with it, so we thought it would be best to play to our strengths, making it quite obvious that react would be the best fit for us. We constructed the table below when considering which software to use:
| Factor | React | Angular | Vue |
|---|---|---|---|
| Developer Experience | Yes | No | No |
| Easiness to Learn | Easy, due to JSX resembling normal HTML | Not easy | Easier than Angular |
| Popularity | Most | Second | Third |
| Efficiency | Very fast due to virtual DOM | Slower than React | Slower than React |
We decided to use Fast API to construct our back end. None of us had any experience in developing a back end, so when we were researching different frameworks, we were attracted by Fast API’s concurrency and efficiency, making it one of the fastest frameworks available. This is because other frameworks such as flask are based on WSGI, whereas Fast API is derived from Starlette which uses the more modern asynchronous ASGI standard. We were also attracted by the fact that they had automatic documentation creation, which we thought would be quite useful for our project. The main alternatives we were considering were flask and django, and we again used a strengths table to choose the framework we thought was best.
| Factor | FastAPI | Django | Flask |
|---|---|---|---|
| Developer Experience | No | No | No |
| Automatic Documentation | Yes | No | No |
| Popularity | Third | Second | First |
| Efficiency | Fastest | A little slower than Flask | Much slower than Fast API |
In order to evaluate which framework was the fastest, we researched their performance online. This can be found in our Evaluation section under the efficiency title.
One of the pain points of using Fast API is that it is a much less popular framework than both Django and Flask. This meant that there were fewer online resources and tutorials for us to use and learn from. Thankfully, this was somewhat offsetted by the fact that they produced great documentation for Fast API, so we had something to refer to if we got stuck. Moreover, Fast API has quite a simple easy structure, which was beneficial as none of our team had written a back end before.
We also had to research the best method of hosting our project. At first, we were considering using githubIO pages. This is because we were in our early stages of development, and we thought our whole project would just comprise of a React front end. However, upon further evaluation, we decided to switch to host our code on Azure instead. This is because Azure has many additional benefits and tools, such as quick scalability, which makes it superior to GitHub pages. However, our biggest reason for switching was the data analytics that Azure supports, as It allows us to gather crucial data such as the number of active users. (This switch was quite fortunate, as our project then grew in size and required a back end and other components, and using Azure's resources greatly helped expedite our development).
We then experimented with Azures resources to try and find the best way to deploy our (at that time) single react page. Unfortunately, this experimentation actually backfired, as we created a linux resource, then deleted it to create a new one for our actual project. We were unaware that you were only allowed to create one free linux resource per subscription (the F1 limited resource server), so we were forced to pay for a more expensive one. We tried creating a windows server instead, but this was not compatible with our node.js based react page.
Further on in the project, we also chose to use Azure’s “MySQL” resource to host our database, as we wanted to try and use a variety of Azure resources. This actually worked quite well for a while, and our decision tool was working fine. However one day the code broke, and our resource was canceled. We tried creating a new resource, but we kept getting an error message which stated “The location you selected is not compatible with your subscription”. We tried every server location, but kept getting the same error message. We even tried a different Azure subscription but this did not work either. We then consulted with an Azure expert at UCL, Dr Yun Fu, and he told us that this was an issue with Azure. As a work around, we then decided to create an Azure Ubuntu VM to host our database. This acted as an effective substitute, as we were able to use SSH to conduct queries.