Architecture

Browser->API: GET me some data
API->Database: data please
Database->API: here is the table of data
API->Browser: here is the data in JSON

+---------+                     +-----+                        +----------+
| Browser |                     | API |                        | Database |
+---------+                     +-----+                        +----------+
     |                             |                              |
     | GET me some data            |                              |
     |---------------------------->|                              |
     |                             |                              |
     |                             | data please                  |
     |                             |----------------------------->|
     |                             |                              |
     |                             |    here is the table of data |
     |                             |<-----------------------------|
     |                             |                              |
     |    here is the data in JSON |                              |
     |<----------------------------|                              |
     |                             |                              |

The browser can also make changes to data using the same flow but with different HTTP methods like POST and PATCH.

The Stack

Multitenant, monolithic, 3-tier application with a MySQL database, Spring Boot HTTP API and React Single Page Application.

Tier/Component	Type	Language	Implementation
DB (Database)	Relational	SQL	MySQL (pronounced "my sequel")
API (Application Programming Interface)	JSON over HTTP	Java	Spring Boot
UI (User Interface)	SPA (Single Page Application)	Javascript	React

Tier Responsibilities

Tier/Component	Where it runs	Infrastructure	Storage & Retrieval	Security	Navigation
DB	Private server (cloud)	AWS RDS	yes
API	Public server (internet facing) (cloud)	AWS Elastic Beanstalk	yes	yes
UI	Internet browsers (desktop and mobile devices)	AWS S3 and AWS CloudFront	yes	yes	yes

You can see the separation in responsbility here but I also want to highlighting the sharing of responsbility with storing and retrieving data.

Security

It is important to "never trust the client". In our application the client refers to the ui and the reason for that is because we can't control client side code - anyone can run anything in their own browser. That's why we have an API so that users can't directly access our database and potentially other organisations' data. I see it as a middleman between the user and the database. It is primarily in charge of enforcing the security as well as preparing the data from the database. When I talk about security i'm talking about users that aren't logged in don't have access and users that are logged in only see their own organisation's tasks.

Monolithic

This architecture is commonly referred to as a monolith or monolithic which means it is more or less deployed as a single unit. I think of it as a monolith though others might argue that it isn't because the ui is separate. It gets a little bit confusing because the word monolith is often used negatively, like in the wikipedia article, because monoliths, like any application, can be horrible but I like this architecture and i'm not the only one. See the majestic monolith for more.

An alternative architecture is microservices where a single application is made up of individually deployed services which mainly offers performance benefits. My biggest issue with microservices is their local development experience though tools like serverless framework are closing that gap. This monolith is designed to be a joy to develop on, something i'm not sure I could achieve with a microservice architecture. This whole architecture can easily be run entirely on your local machine and that's an important part of our development process.

Multitenant

Multitenancy means to store multiple tenants on a single instance. In this case we store multiple organisation's in the same database and access it using the same API. This means there is less isolation between organisations' data but makes this application a lot simpler to manage.

Application Tools

SQL, Java, Javascript, HTML and CSS are still the most popular technologies among developers in 2018. Most Popular Technologies, Developer Survey Results - Stack Overflow and I know them pretty well.

• Database

  • MySQL

    • An older, common relational database that I have the most experience with.

• API

  • Java
  • Spring Boot

    • An easy and opionated way to create Java applications.

  • Hibernate

    • A popular ORM for Java that maps objects to and from the database.
  • Spring Security

    • To authenticate users.

  • Spring Data JPA

    • Helpful abstraction for doing CRUD.

  • Querydsl

    • Creating typesafe and composable database queries even directly from http requests.

• UI

  • React

    • Simple, powerful and popular.

  • Create React App

    • For an opionated, zero-configuration build process.

  • Material-UI

    • Implementation of the popular Google Material Design System in React.
  • React Router V4

    • URL management.

Development Tools

Our number 1 development tool is our development process documentation!

• Version Control

  • Git

    • Popular and works well.

  • Monorepo

    • For simplicity and synced changes across the application.

  • Git Town

    • An abstraction over git to make it easier to do common things.

• Editors

  • Visual Studio Code (vscode)

    • Fast and popular editor.

  • Sequel Pro

    • The best Mac app to manage MySQL databases.

• Deployment

  • Flyway

    • for automated database migrations.