This post covers the process of designing the Back End (server side code) for my scooter share app, Creatures. My back end will manage a database, authorize users, execute application logic, and communicate with our hardware (scooters). I started developing the back end first because it is the core of my application and the other parts, (front end, hardware, etc) all rely on the back end.

This post is not meant to explain in exhaustive detail the problems involved and how to resolve them. For a guide that does cover setting up a serverless application in exhaustive detail I recommend the Severless Stack Guide, it’s great.

I chose to structure my back end as a serverless application, which means I will not need to provision and maintain any servers. To build my serverless app, I will use Amazon Web Services (AWS)

Specifically I will be using these AWS services:

• Cognito - authorization / authentication
• Lamda - application logic
• DynamoDB - simple database for keeping track of scooters
• API Gateway - API to receive communication from clients and scooters

Additionally my back end will communicate with a Cloud IoT service, Particle. My scooters will use Particle hardware. I cover Particle in greater depth in my 🔧 Hardware Post.

Related Links:

GitHub Repository for Back end - Source Code

😡 Challenges

When designing the back end for my scooter share, it was helpful for me to start by writing out the features I wanted to provide for my users. Writing out a features list, should help concentrate my development efforts. The feature list I came up with was focused on must-have features. Since I considered this project a proof of concept I wanted to focus my efforts on creating a minimum viable product.

Here is the list of must-have features

• Scooter needs to be GPS tracked both from scooter side and client side for redundancy
• User needs to be able to create an account and log into it and out of it
• User needs to be able check out and check in scooters
• Rides are based on a set time limit e.g. 20 minutes

Here is a list of secondary features that I would like to have some day:

• User can find scooter on map
• Native apps (IOS, Android)
• User can see battery status of scooter
• User can track ride history
• User can edit account settings after creating an account: name, email, etc.
• User can have the scooter sound a chime to help find it

🤔 Solutions

🔑 Authentication and Authorization

For Authorization, I used Amazon Cognito. The nice part about Cognito is that handles all the password requirement logic, and verification steps. There are two parts to using Cognito:

• User Pools - used for authentication

  • provides signup and login functionality for my app

• Identity Pools - used for authorization

  • provides access to other AWS services that I designate, in my case that will mean authorizing access to my API Gateway resources.

💽 Database

I will use DynamoDB as my database solution. For simplicity’s sake, I will use a single table and each scooter will have a single entry that gets updated when a user checks in or checks out a scooter. The database will be managed by Lamda functions I setup.

Each entry into the table is structured as follows: (one object per scooter)

📜 Logic

For my application’s logic, I will be using Lamda functions. Lamda is the service that makes my application a serverless application. Essentially every time my application needs to run some code, Lamda spins up a container, runs the code, and shuts down the container after the code completes. The beauty of using Lamda, is that I can focus on the code for my app without worrying about the infrastructure; no, setting up servers, containers, or installing applications, just code.

The following table lists all of my Lamda functions. — All functions are written in JavaScript.

Outside of my Lamda functions, there are several functions that reside on the scooter’s IoT hardware, a Particle Electron. Particle’s cloud service provides access to functions stored on the device via a simple API.

💬 API

I setup API endpoints for each of the functions listed above using API Gateway. Authenticated users will have access to all endpoints except for the scooterCheckSelf, that endpoint only the scooters will have access to. In order to provision access to the scooterCheckSelf API, I setup up an API Key that the scooter will use to authenticate.

🙂 Implementation

To help manage and setup my back end resources, I used the Serverless framework as my IaC solution. Using an infrastructure as code framework, allows me to rebuild my back end easily, in case I screw anything up.

A blog about Creatures an open source scooter share project
Started by Joshua Sheridan