A6 – Application Architecture

Application Design Records

Decision: Programming language
  • Summary: In order to build a responsive frontend for a website, we decided to use JavaScript. 
  • Problem: We have to choose a programming language to write the frontend in. This is important because we want to include custom functionality that can’t be replicated by typical website building applications. 
  • Constraints: The language must be stable and scalable (because we expect the website to be used by people from all over the country), suitable for frontend development (because we’re building the frontend of a website), and also suitable for mobile development (we assume that the client will want to have a companion mobile app at some point to make it easier for users to report litter in the field). 
  • Options: The options are PHP (is easy to learn, but difficult to program and debug in), Python (very popular and good for backend work, but is slower and more memory-intensive), Java (is stable and well-known, but may be too much for a small project like this), C# (is similar to Java, but is restricted to the .NET framework), JavaScript (is very popular for both frontend and backend work and has many frameworks, but lacks strong typing), and TypeScript (has types, but has less resources than JavaScript). 
  • Rationale: We choose to use JavaScript because there are many resources for JavaScript programmers and we all have experience programming with it. In addition, it has a couple of very useful frameworks that we want to take advantage of. 
Decision: Framework
  • Summary: In order to make the development process easier and add mobile compatibility, we decided to use the ReactJS framework. 
  • Problem: We have to decide if we want to use a framework, and if so, which framework to use. This is important because a framework could greatly simplify the development process, but it would also force us to commit to that framework. 
  • Constraints: The JavaScript framework must be scalable (because we expect the website to be used by people from all over the country), component-based (because we expect to replace and add new features to the website as we receive user feedback), and suitable for mobile app development (we assume that the client will want to have a companion mobile app at some point to make it easier for users to report litter in the field). 
  • Options: Our main options are React (is fast, provides reusable components, and has cross-platform support, but is not well-documented and is constantly being updated), Vue (very lightweight and has reusable components, but has less resources for developers), Angular (creates organized code and uses the MVC and MVVM architectures, but is more difficult to learn), jQuery (is well-known and simple, but is slightly outdated), and not using a framework at all (we’re exposed to less potential vulnerabilities, but we have to write everything ourselves). 
  • Rationale: We choose to use React because it’s the framework that we are most familiar with and the only one that provides cross-platform support. We also don’t want to spend the limited amount of time that we have on rewriting existing components. 
Decision: Website Map API 
  • Summary: In order to have a scalable and easy-to-use map API, we decided to choose to use Google Maps API. 
  • Problem: We have to choose an API for the website’s main map. This is important because the map is the centerpiece of the site and the component on which many other features depend. 
  • Constraints: The map must have typical map functionalities (such as a search bar, drag-to-move, zoom controls, and a way to move to the user’s current location), be fast, and cover the entire world. Additionally, the map must allow for an unlimited number of calls per day. 
  • Options: Options include MapBox (provides easy-to-customize maps and can easily integrate into web and mobile apps, but is difficult to learn and may be resource-intensive), OpenStreetMap (is completely free and provides detail on less popular locations, but only provides vector data and has limited features), and Google Maps (is very popular, reliable, and has lots of features, but is expensive).  
  • Rationale: We choose to use the Google Maps API because it is built for scale, provides a familiar UI to users, and has a lot of documentation and tools already built for it. 
Decision: Algorithm Data API 
  • Summary: In order to provide the predictive algorithm with good data to base its prediction off of, we decided to use OpenStreetMap’s location tags. 
  • Problem: We have to choose the API that the litter prediction function will get data from for its algorithm. This is important because without a good source of data, the predictive algorithm won’t give accurate predictions. 
  • Constraints: The API must provide basic location data and information that will help us predict whether a location has litter. In addition, the API must contain data for a large number of locations and allow for a large number of calls per day. 
  • Options: The main options are OpenStreetMap (provides tags of significant locations, but does not have litter information or images), Mapillary (provides photos of streets which have AI-tagged objects, but is limited to roads), OpenLitterMap (provides locations of litter with photos, but has very few data points and is not very active), and Planet Patrol (similar to OpenLitterMap). 
  • Rationale: We choose to use OpenStreetMap because of the size of its dataset, the availability of data that could immediately be used for prediction (the tags), and its project activity.