DEV Community: Stuart Sewell

AWS API Architecture

Stuart Sewell — Sat, 28 Nov 2020 16:54:25 +0000

I recently worked on a project which involved separating out the API from a monolith application, containerizing and deploying it to AWS. This was my first experience deploying to AWS, so in order to solidify what I learned during this process I've decided to document some of the resources I used and how they interact with one another.

This diagram gives an outline of the architecture and the resources used.

Regions & Availability Zones

Regions are a grouping of AWS resources in a certain geographical location. Within each region are clusters of data centres called availability zones.

Each region contains multiple availability zones which are physically separate from one another to ensure they are isolated from failures in other zones. The zones are then connected through ultra-low-latency networks.

Any AWS resource you create must be placed inside a VPC subnet (we'll cover this), which must be located within an availability zone. It's often a good idea to launch resources in multiple availability zones to ensure maximum uptime.

Virtual Private Cloud (VPC)

A VPC is a private virtual network where you can provision AWS resources - in essence your own private area within AWS. You have complete control over this environment including selecting IP addresses, route tables and network gateways.

Working with subnets we can setup private and public facing environments and control who can access these, and how. A VPC will span all of the availability zones in a region.

Subnets

A subnet is a sub section of a network and can be either public or private. The key difference being, public subnets have a route to the internet whereas private ones do not and can only communicate with other subnets within the same VPC.

One or more subnets to each availability zone, but each subnet must reside entirely within one zone, and cannot span zones.

A quick analogy for everything covered so far

Imagine an office building as being a region - an outer layer that contains many things.

Each floor is an availability zone. A region can, and most likely will, have more than one zone, much like a building and floors!

Each department is a VPC, it can span across floors.

Finally a subnet is the office suite - it can only reside within a single floor.

Security Groups

Security groups act as a virtual a firewall - they allow and deny traffic. They operate on an instance level rather than a subnet level, so you would apply a security group to each instance you launch.

You apply rules to each security group to allow traffic to and from its instances. These rules can be modified at any time and will instantly apply to all instances associated with that security group. Multiple security groups can be added to each instance.

By default all inbounded traffic is denied, and all outbound is allowed.

To continue with our office building analogy, security groups would be the key cards to access different areas of the building.

Application Load Balancer

An application load balancer is essentially a server which fronts the application and forwards traffic to instances downstream - so in our case the Fargate instances. It's used to spread the load across multiple instances whilst providing a single point of access.

It will also perform health checks on our instances and if one instance fails the load balancer will direct traffic to the remaining healthy ones. We provide a route - for example '/health', and if this returns a 200 it knows the instance is healthy.

Other features of the load balancer includes:

Providing support for SSL/HTTPS.
Works across availability zones, so if one zone goes down the load balancer will move all traffic to the other zones.
Separating public from private traffic.

Route 53 && Internet Gateways

Route 53 is a managed DNS - a collection of rules and records mapping IP addresses to URLs. It can be used for both public domain names and private domains - which can only be resolved by instances within the VPC. Route 53 can also provide load balancing through DNS and limited health checks.

Internet gateways provide the VPC with a route to the internet. If you think of your home network as a subnet, your modem would be the internet gateway proving access to your ISP and the wider internet.

Only one internet gateway can be applied to any VPC, and a gateway cannot be detached from a VPC whilst there are any active instances still running on it.

AWS Fargate

The final piece of the puzzle is Fargate - "a serverless compute engine for containers that works with both Elastic Container Service (ECS) and Elastic Kubernetes Service". This is where we provision our API containers.

Fargate is a kind of evolution of Elastic Container Service. It's managed by AWS - removing the need to provision and manage servers, and it scales up and down seamlessly, meaning you only pay for what you use. You can think of it as containers on demand - where everything is managed at a container level.

This quote perfectly surmises the reason to choose Fargate.

Conclusion

Hopefully this provides a high level understanding of some of the resources that go into setting up a containerized application on AWS. Of course, the best way to fully grasp these concepts is to dive in and get hands on.

Here are some resources I have found to be particularly helpful:

Linux Academy - AWS Essentials
A Cloud Guru - Cloud Training
Stephane Maarek - AWS Certified Solutions Architect Associate
And of course, the AWS Documentation

Redux Saga

Stuart Sewell — Fri, 06 Mar 2020 13:21:00 +0000

I was recently given a technical test which required the use of Redux-Saga. Prior to this I’d had some experience using Redux but sagas were a new concept to me. After a run through of the beginner tutorial in the docs and a look from some example code I attempted the test was some success. This blog will attempt to solidify what I have learnt by building a small project.

What even is Redux Saga?

Redux-Saga is a Redux middleware that attempts to manage side affects in a simple and testable way. It takes advantage of generator functions which were made possible in JavaScript ES6, to enable asynchronous code which can be tested as easily as synchronous code.

The Project

The project we’re building is a React app which renders a randomly generated picture of a cat alongside a quote every time the user clicks on a button.

See the finished app here:

Cats and Quotes

Getting Started

This repo is available here if you want to code along, clone it down and run npm install. This will give us a base React app with some additional styling. Alternatively, set up a new React app by running npx create-react-app catsandquotesand implement your own styling. Once the React has finished setting up move into the directory and start the app cd catsandquotes && npm start.

Once you have a React app up and running install the dependencies with the following:

npm i redux react-redux redux-saga

These are all of the dependencies we will need for this project.

Actions

mkdir src/store && touch src/store/actions.js

Let’s start with the actions, as these will be frequently referred to throughout the app. Start by creating a store directory inside src and inside this create an actions.js file.

The contents of this file is shown below. We have three actions API_REQUEST API_SUCCESS and API_FAILURE, by declaring these as constants we protect ourselves against typos later on. We also create three corresponding helper functions which return our actions formatted for correctly for Redux to consume.

Reducer

touch src/store/reducer.js

The reducer is going to manage the application state. It will be responsible for setting the initial state, as well as updating and returning state. We’ll start by creating a reducer.js file inside the store directory, importing our actions and setting the initial state:

import { API_REQUEST, API_SUCCESS, API_FAILURE } from './actions';

const initialState = {
  catImageUrl: '',
  quoteText: '',
  fetching: false,
  error: null
};

Then we set up the reducer itself. We have three options, plus the default which returns the state unchanged.

API_REQUEST: any time we make a request to the API we call the API_REQUEST action which sets fetching to true, and error to null (in case there is a previous error still in state).

API_SUCCESS: if our API call is successful we call the API_SUCCESS action which resets our fetching state to false sets the catImageUrl and quoteText returned from the API’s.

API_FAILURE: should there be an error with the API call, the API_FAILURE action will reset fetching to false and return the error message.

Saga

touch src/store/saga.js

Now onto the crux of the project, the saga! This will be responsible for making our API calls and handling the success or failure of this.

Add the following imports to the top of the file, we’ll take a closer look at call, put and takeLatest further down.

import { apiSuccess, apiFailure, API_REQUEST } from './actions';
import { call, put, takeLatest } from 'redux-saga/effects';

We’ll start by writing our API request functions, I’m using the thecatapi.com for the cat images and ron-swanson-quotes.herokuapp.com for the quotes. We’re using simple async/await functions for this.

const catFetch = async () => {
  const res = await fetch('https://api.thecatapi.com/v1/images/search');
  const data = await res.json();
  return data[0].url;
};

const quoteFetch = async () => {
  const res = await fetch('https://ron-swanson-quotes.herokuapp.com/v2/quotes');
  const data = await res.json();
  return data[0];
};

Next we have our API saga function. This is a generator function which is going to do all of the heavy lifting for us. We define a generator function by adding an asterisk (*) at the end of the function keyword. It’s worth noting here that we cannot define generators with the arrow function syntax.

function* apiSaga() { ... }

We wrap the saga in a try-catch block to enable us to easily handle any errors that may arise.

try { ... } catch (error) { ... }

Inside the try block we perform the API fetches then call the API_SUCCESS action.

try {
  const catImageUrl = yield call(catFetch);
  const quoteText = yield call(quoteFetch);
  const payload = { catImageUrl, quoteText };
  yield put(apiSuccess(payload));
}

Here the first line is calling the catFetch function and saving the return value to a const.

“The yield keyword is used to pause and resume a generator function” — MDN Web Docs. This tells our saga to pause whilst we perform the asynchronous API call and continue when we have a response.

call is part of the Redux-saga API. It “creates an Effect description that instructs the middleware to call the function” — Redux Saga Docs. Simply, it tells our saga to call the catFetch function.

The second line is the same as the first but calling the quotes API. And the third line creates a payload object using ES6 object shorthand.

The final line of our try block uses the Redux-saga put method which “instructs the middleware to schedule the dispatching of an action to the store.” — Redux Saga Docs. We’re telling the saga to call the Redux API_SUCCESS action with payload from the API calls.

catch (error) {
  yield put(apiFailure(error));
}

If there is an error without API fetches we call the Redux API_FAILURE action and pass the error as the payload.

export function* rootSaga() {
  yield takeLatest(API_REQUEST, apiSaga);
}

The final part of out saga file is the rootSaga generator. The root saga is responsible for starting all of our sagas (in our case we only have one) and allows us to export just one saga. We would see the real benefit of this if we had multiple sagas being defined and exported.

Notice that we are using takeLatest here, this “forks a saga on each action dispatched to the Store that matches pattern. And automatically cancels any previous saga task started previously if it's still running.” — Redux Saga Docs. It prevents the same saga from being multiple times simultaneously, by cancelling any previous instances every time it is called.

Full code for src/store/saga.js below:

Creating a Store

touch src/store/index.js

It’s time to bring all of these elements together to build and export our Redux Store. We start with our imports, the reducer and rootSaga we previously created and the rest we’ll cover when we implement them.

import createSagaMiddleware from 'redux-saga';
import { createStore, compose, applyMiddleware } from 'redux';
import { reducer } from './reducer';
import { rootSaga } from './saga';

If you don’t already have Redux DevTools installed on your browser head over to extension.remotedev.io. These will greatly help with debugging, and give a great insight into the Redux process in your app.

const reduxtools =
  window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__();

const sagaMiddleware = createSagaMiddleware();

The first line checks if DevTools are installed, and if so invokes them. The second line calls on the createSagaMiddleware function to create a Redux middleware and connect our saga to the Redux Store.

export const store = createStore(
  reducer,
  compose(applyMiddleware(sagaMiddleware), reduxtools)
);

sagaMiddleware.run(rootSaga);

Finally it’s time to create our Store and start our saga middleware. createStore first takes in our reducer and secondly takes an enhancer. We want to pass in two enhancers — our middleware, and the devtools, so we can use the Redux compose function two pass in multiple options. Inside compose we pass the Redux applyMiddleware function which will connect our saga to the Redux Store.

The final line here calls run on our saga middleware and passes in our saga.

Full code for src/store/index.js below:

Bringing it all together

The final thing we need to do is connect our Redux Store to our React app.

First we update src/index.js by importing Provider from react-redux and the Store we just created. Wrap our App component with the Redux Provider and pass in the store we created.

The final part of the puzzle is adding Redux to our App component. We’ll use React Hooks to set Redux in our app.

import React, { useEffect } from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { apiRequest } from './store/actions';

Start by importing useEffect from ‘react’ — this is the hooks equivelant of componentDidMount, useSelector and useDispatch from ‘react-redux’ and our apiRequest action function.

The hooks implementation of Redux is much cleaner and more precise than it previously was. We can bring in our state and dispatch in just two lines:

const { catImageUrl, quoteText } = useSelector(state => state);
const dispatch = useDispatch();

const handleClick = () => dispatch(apiRequest());

The first line uses ES6 syntax to extract catImageUrl and quoteText from the state object provided by useSelector. The second line set up our Redux dispatch function. The last line passes our apiRequest action to the dispatch function inside a handleClick function.

useEffect(() => {
    dispatch(apiRequest());
  }, [dispatch]);

return (
    <div className="container">
      <h1>Cats + Quotes</h1>
      <div className="row">
        <img src={catImageUrl} alt="A cat" />
      </div>
      <blockquote>{quoteText}</blockquote>
      <button onClick={handleClick}>Gimme more...</button>
    </div>
  );

We’ll also pass the dispatch to useEffect to make sure an API request is made as soon as we load the page. Finally, we return the contents of the App component, passing the handleClick function to our ‘more’ button so the user can load a new picture and quote.

The full App component is shown below.

That’s our Cats and Quotes app complete. Some missing features that I will look to work on in future include handling errors inside the app, as well as some testing of both the React app and the sagas.

Thanks for reading…