Step 1: Come up with that revolutionary app idea. Step 2: Learn mobile development and build the app. Step 4: Profit!
Wait…what about step 3? While your app may be simple enough it only needs Android/iOS development, odds are there’s more to it. You might need user authentication, friends lists, or other information to be passed to your app from an API that gets its info from a database somewhere outside the app. Depending on what your app idea is it’s possible your app simply can’t exist without help from the outside.
So, does that mean it’s time to learn how to build your own server? Manage your own database? Not quite. There’s an easier alternative for us as developers: Serverless apps with Amazon Web Services.
What Does it Mean to be Serverless?
* Note if you are already familiar with what a serverless app is and the AWS components, feel free to skip forward to implementation steps *
A serverless app is what it sounds like (an app without a server) but requires a little more clarification. Technically it’s an app with a temporary server. There is no permanent server you have to manage, but when you are making an API request a server is created to handle your request. Once your request is handled that server is deleted. Rinse and repeat and you get an app that never has to pay for a server unless a user is actively sending in a request to it.
There are several benefits to using this architecture with AWS. First and foremost, it’s simple to get started (we’ll have a functioning API by the end of this article). It’s incredibly cost-efficient since you’re not paying for a 24/7 server but rather one that will charge a small amount per request. And finally, you don’t have to worry about keeping a server operating/up to date. It’s hands-off, cheap, and simple to implement. Win-win-win.
AWS Serverless Pieces:
There are two key parts to building a serverless app with AWS: API Gateway and AWS Lambdas. API Gateway is where you create the wireframe structure of what API calls you will want to use in your app. You can add as many individual paths as you would like and assign rules around them such as their type (GET, POST, etc) or if they require authentication. It allows for one place where you can see a clear description of all your paths.
If you’ve worked with lambdas before in Java (or closures in Swift) then the concept is the same with AWS Lambdas. And if not, a lambda is a function. You write the logic for a lambda and it can be applied again and again for use with whatever calls it. In the AWS context, lambdas are where you will write the logic for an API. This determines how the API will handle what you send in and what response body it should give back.
Putting these two pieces together we’re able to create a fully functioning server that (just like lambdas per usual) is only used when we call it. Alright, enough background. Let’s build the real thing:
Setting Up API Gateway:
First off, you need to create an AWS account. Click here and then use the bright orange Sign in to the Console button to create an account. At the time of this writing there is a free 12-month trial period for individual developers, so definitely take advantage of that. You shouldn’t need anything beyond it to build an API.
Once you’ve created an account, open the Services drop-down and search for API Gateway. On this page, select Create API and then you’ll be presented with several options for API types as seen below. Click Build under REST API.
On this next page select New API and give your API a name (Here I’ll use FreeMobileTutorials). Click Create API and you’re done. We officially have an API, just nothing useful yet. At this point under the Resources tab, you should see one “/” only. This is referring to your base path and where we’ll be building upon for our individual paths.
Just above that “/” select the Actions drop-down and choose Create Resource. Give this resource the name SamplePath and create it. Now in your path list you should see “/samplepath”. Select it, then in the same drop-down select Create Method. Choose GET and then click the checkmark to finalize your change.
Select Mock as the Integration type for this path (we’ll come back to this later) and save it. Now onto building the lambda logic for this API.
Setting Up Lambdas:
In the Services dropdown, we used earlier search for AWS Lambda. On the left-hand side navigate to Functions and then select Create function. We’ll create an Author from scratch lambda and give it a name as well as selecting Node.js 12.x as the runtime language. Note that there are a number of languages you can use here including Java, but Node.js is the default. Create the function and move on.
At this point, we have a functioning lambda with boilerplate code. Under the Function code section, you can modify your logic to be absolutely whatever you would like. With the sky as the limit, we’ll make this one say “Welcome to my first serverless API”. Breathtaking, I know.
Once you’ve updated your index.js file, save it and select Deploy. We’re now ready to hook this lambda up to API Gateway. So back in the Gateway tab let’s select our GET request and open the Integration Request that we had created with the type MOCK. Change this to Lambda Function and enter your lambda function name to match the one you just created. Make sure the Lambda Region drop-down matches your region and check the Use Lambda Proxy integration checkbox. Now press save and select ok for the permission dialogs that come up.
The Big Push:
Are you ready? In the Actions dropdown we’ve used to create our path, select Deploy API. At this point, you’ll see a dialog window asking you to select a Deployment stage. We don’t have any yet but could make multiple if we wanted to build a test environment along with our production APIs. Let’s give this the name “prod” and select Deploy. You should now see an Invoke URL at the top of your page. Copy this and paste it into a web browser. Make sure to append your GET path “/samplepath” to it and then try to load the URL.
Congratulations, you’ve officially built your first serverless API!
Not so hard is it? Now that you’ve seen it done once you can probably create another API in under 5 minutes. Building out the real logic of what you want your API to do is the hard part, but now your serverless app is up and running! It technically isn’t, since you aren’t actively making calls to it, but you get the point.
AWS offers a multitude of great options like this for other features such as user authentication. I’ll be posting another article soon explaining both how to create/manage users via AWS Cognito Pools as well as how to use those pools to authenticate/protect the APIs that we built together here.
If you found this post helpful and want to read more like it check out my other posts at FreeMobileTutorials.com. Claps and coffee donations are always appreciated so I can continue taking the time to make these.
