Architecture Choices

Google App Engine Flexible Environment allows us to have multiple instances of our flask-restful API, hence allowing the server to handle requests even during peek intervals. Combined with the scalable features of Firestore, we should expect the back end to be ready for 100+ users without noticeable delay during peak.

Why not using Firebase real-time database?

• User has to update an app every time new feature is released or a bug is fixed
• Limited security rules: user data is vulnerable to illegal access or complex and nested security rules must be written
• Does not support composite queries. For example, the front end may have to download most rideRequests from database in order to match into an orbit. This would slow down the app.
• No relational queries. This means it will take way longer to write business logics.
• Transaction support is weak. Sometimes we need operations to be able to rollback when failed (for example, we want to rollback adding user to the orbit if we run into an error adding their EventSchedule)

Why using Firestore rather than MongoDB or MySQL?

• Firestore has a better client library
  • Smoother user experience
  • Data is always updated to the newest version in front end. Otherwise, we would have to use websocket, which adds another layer of uncertainty when in production release
  • Writing and debugging network layer in front end can be challenging
  • Offline data support for event schedule (the user can still view their list events when Gravitate server is down)
• Time required to reach MVP
  • When using Firestore, some services can be accessed by reading from Firestore directly. This still allows us to switch to RESTful service as we add more features and domain models. We are able to expedite the development without looking at more than one set of database developer documentation.
  • Firestore is a NoSQL database. This means that we are able to support different kinds of rides with the same set of code. Also events and locations may be supported for any number of variations. Otherwise, we would need to design complex schema for MySQL which slows down the software development cycle.