Skip to content

Instantly share code, notes, and snippets.

@MakotoE

MakotoE/final presentation.md

Last active June 15, 2022 13:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save MakotoE/28b6868c3fea2770bba1bbbe4733cc57 to your computer and use it in GitHub Desktop.
Save MakotoE/28b6868c3fea2770bba1bbbe4733cc57 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
final presentation.md
  • System architecture
    • Clear distinction between the frontend at the top half and the backend at the bottom half
    • Keep It Sweet and Simple
      • When working on a big project, it's easy to overengineer solutions. But that only makes our jobs needlessly complicated.
      • For this, we just needed a working proof of concept.
    • Scalability is not necessary
      • The final product is a proof of concept. We just need to support a handful of concurrent users at a time - the developers and testers.
      • There's no need for a load balancer and we only need a single EC2 instance.
    • Use familiar technologies
      • We had to decide between MySQL or MongoDB. We choose MySQL because we are most familar with that.
      • We learned a ton of new technologies, but we started with what we already knew to provide a foundation.
  • Backend Architecture
    • Server is hosted on EC2
      • Server is written in Go
    • The database is MySQL that is hosted on RDS
    • We needed a search engine for the search feature, so we used OpenSearch
  • Highlights From This Project
    • Managing our time
    • Asking for help
    • Thinking about how to divide a feature into managable tasks
    • TODO: Mobile app

This is the architecture diagram. As you can see, there is a clear distinction between the frontend, which is the top half of this diagram, and the backend half of the diagram. We had three guidelines when designing the system. Keep it sweet and simple was the first. When working on a big project, you can easily overengineer solutions. But that would only make our jobs needlessly complicated. Because we created a proof of concept, we knew that scalability is not a requirement. We would only have a handful of concurrent users - the developers, the testers, and such. And so there is no need for a load balancer and we only need a single EC2 instance. The third guideline is to use technologies that we are familiar with. There was a point in which we had to decide between MySQL or MongoDB, but we decided to use MySQL since we know that the best. Of course, we learned a ton of new technologies throughout the year but the techonologies we were already familiar with provided us with a good starting foundation.

Let's dive into the backend architecture. The server was written in Go, and it is hosted on EC2. The MySQL database is hosted on RDS, and we decided to use OpenSearch for the search engine.

This year, we learned a lot about working and collaborating in a team. From managing our time, asking for help, and thinking about how to divide a big feature into managable tasks. In the TODO note there, it says mobile app because we didn't have the time to create one. If we had all of the time in the world, we could have created a mobile app. In the limited time we had, we decided to focus on the web app only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment