[Screenshot from demo + "technical details" text]
To explain how it all works, let's go back to that demo. But this time, I will take you behind the scenes and show you step-by-step how it all works.
[3-tier diagram]
We structured our service based on the three-tier architecture. You might remember the layers being called the presentation and business logic layers; here I refer to them as the frontend and backend. Inside those layers, we further subdivide them at the source code level.
Let's start from the top. [Arrow pointing to view] The user goes to a vendor page, [URL bar] at the URL "vendors slash vendorID". [Vendor page] The React framework renders all the components on the vendor page and initiates an action.
An action changes the application state and may have side-effects, such as to trigger an API call. The action we just triggered looks like this. [Redux devtools] It might look complicated, but all it's really saying is: [overlay quote] "User wants the vendor page!"
A reducer sees that action and triggers an API call. It also changes the application state to indicate that our app is busy, which the UI can show with [spinning wheel] a spinning wheel.
[3-tier diagram, pointing to API abstraction] We just passed the state and actions layer, and now we're here, at the API abstraction.
As the name suggests, the API abstraction is just a wrapper around the API to hide the details. This function call, [vendors("e72ac985-3d7e-47eb-9f0c-f8e52621a708") text] "vendors," is converted into an HTTP request, [GET /vendors/e72ac985-3d7e-47eb-9f0c-f8e52621a708 text] "get vendors ... blah blah blah."
[3-tier diagram, pointing to API] Now, we have crossed over to the backend layer. The API is the interface for the backend. It's what allows the frontend and the backend to communicate. For any password-protected resources, this is where authentication is handled.
[API doc] Our RESTful API is documented in an OpenAPI specification. Scrolling down our documentation, we can see that the vendors resource is here. [Zoom in to resource]
Inside the backend code, which is written in Go, the API request calls the [screenshot of Backend.vendor method] "vendor" method with vendor id as the parameter.
[3-tier diagram, pointing to application logic] The application logic layer is what I like to refer to as "where the magic happens." Because that layer's responsibility is to transform API calls into database queries. If any third-party services are required for a resource, they are called from here.
[3-tier diagram, pointing to database abstraction] The database abstraction layer hides the database details. To look up a vendor, we use a MySQL query like this. [SELECT * FROM vendor WHERE ID=?;]
[3-tier diagram, pointing to database] We're finally at the database, where all content data is stored. The vendor data is going to get sent right back up, [arrow on diagram moving up], and the view will render the vendor page for the user.
So I just talked about how it works, but where exactly is it all taking place? What services do we use?
[Iterate through all AWS icons for the services] We will be using various AWS services. The backend will be running on an EC2 instance, the database will be stored in RDS, images will be stored in S3, and OpenSearch will be used for our search engine.
[GitHub logo] The files for the frontend app will be hosted on GitHub Pages. It's free, and quite simple to setup.
[OpenStreetMap logo] Finally, OpenStreetMap will provide the map tile images for our map.
[Testing text] Let's talk about testing. [Unit test bullet point] We will add unit tests wherever we can to test small units of code. [Integration test bullet point] The interaction between various layers will be validated with integration tests. Integration tests will use a local database, and API calls will be simulated. Its actual responses will be compared with expected responses.
[3-tier diagram] We looked at how our web app will be divided into eight different layers and run on various services. This separation of concerns allows us to divide the whole architecture into small responsibilities. When we implement a new feature, we can divide the feature into different layers and develop one layer at a time.
GREAT!