This document serves to define the Architecture of the Corgi Flight Statistics Web Application.
- Provide a high-level architecture of the Web app
- including the technologies tobe used and their justification.
- Identify one or more value-added features to be offered through the Web app(optional).
- Graphical representation
- User reported delays?
- The use of a database for persistence is optional but recommended.
- We design with the intention of keeping the levels of effort to implement a database being only that of implementing the database itself.
- Include diagrams
- Add json/csv output for EVERYthing in docs
- Add csv representation in code
- Add HAL for HATEOAS solution
- Fully available
The process is simple, but please refer to our install instructions in: install_info.md for up to date, step by step instructions.
Clients fetch data from the server. More servers can be spun up to handle scaling in future, predicated on having abstract data access layer. Initially for early development, all data was stored within memory. This allowed for keeping costs down during initial development since there are no extra server costs. We expect a low amount of requests per second following release, with a slow ramp up, so we decided to begin with a single CockroachDB server. If the web app begins to show signs of exponential growth, the abtracted data access will be quickly expanded with extra nodes, automatically. The time to implement this would by only that of setting up the databases themselves.
The frontend will fetch data from the server, and manipulate it client side to render charts and graphs, as well as store smaller chunks of data in the cache for faster loading each time the user opens the site. Since some of the data rarely ever changes, and takes a relatively small amount of space, we can store the codes and name of the airlines and airports directly within the cache. Only when the user needs up-to-date statistics will they need to fetch information from the server again.
View, rendering of data in charts, sorting, etc, occur (mostly) in the client. Can optimize and refresh data that is out of date. Could be extended to smartly cache to reduce fetching for graph generation.
Our front end will deliver the basic requirements, plus the ability to render statistics in graphical charts, as well as submit new reports for delays. These reports will contain information that will allow us to add the delay, but ensure that it is not entered more than once if multiple people report the same delay. As this would cause inflation that does not match the actual delay statistics.
Part of our extended API feature fetches a summary of the airport from Wikipedia as well.
We are using Rust for our backend. This language strives for the trifecta of concurrency, speed, and saftey.
Type saftey, speed, familiarity in team, general saftey, and security.
We implement our web app backend in Rocket for Rust. Rocket delivers some key features that we wanted:
Rocket is extremely fast. Compared to Node.js (via Restify), Rust could handle approx. 10x the number of requests per second. This means for us, that we can keep our customers happy with short waiting times, and keep costs minimal with fewer servers required to handle the traffic volume.
From request to response, the Rocket server will ensure at compilation that everything will work without hidden errors, runtime errors, or unexpected results.
We can ensure the security of our endpoints with gaurds that protect the handler from running unless certain conditions are met by the incoming request metadata.
We are able to serve different data types with less effort by wrapping them.
We don't like Javascript. We were familiar with Rust, so we chose the better of the two.
This is a library that we include to manage our HATEOAS reponse body. It manages the links and references of our objects and will automatically output a formatted json for a request.
Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.
The Serde ecosystem consists of data structures that know how to serialize and deserialize themselves along with data formats that know how to serialize and deserialize other things. Serde provides the layer by which these two groups interact with each other, allowing any supported data structure to be serialized and deserialized using any supported data format.
Diesel is the most productive way to interact with databases in Rust because of its safe and composable abstractions over queries.
Diesel eliminates the possibility of runtime errors, incorrect database interactions, at compile time. It is a high level query builder with a focus on performance. The extensible design is designed to be abstacted over. Which enables us to write reusable code and think in terms of the problem domain and not SQL.
CockroachDB is a fully featured database building on top of postgres. It is fast, secure, and highly scalable with automatic redistribution, load balancing, and error handling. It offers analytics, and a very user-friendly UI, displayed below:
Solves JS problem (AKA, don't use it). We do not like JS. As with our backend, we wanted to find a frontend framework that is not JavaScript. So we set out and found ReasonML, which is an OCAML framework.
Functional Reactive Programming. Messages, state, model, reactions. It also serves to get us extra points for our final submission, since it was demonstrated in a tutorial.
Generates a nice UI for us.
Recharts is a library that allows us to display statistical data in a clean, beautiful way. It is fully featured, and can plug and play.