“Serverless” Architecture in the Cloud with React SPA
Background
AWS S3 (Simple Storage Service) and Azure Blobs are both capable of hosting and “serving” static files (HTML, CSS, JS, images, etc…) without a need to provision compute instances (think: savings). Combine that with a properly tuned Content Delivery Network(AWS’s CloudFront / Azure’s CDN), and a “serverless” processing offering (AWS Lambda / Azure Functions), and you got yourself an optimized, functional app in the cloud.
Will this approach work in every case? No, but there are definitely scenarios (and I believe this trend will only continue to grow) where this may be the optimal architecture in many cases.
Static Files
Let’s review what static files are and how they are served differently from majority of sites (or apps). Simply put, they aren’t processed on the server by compilers or interpreters to produce HTML as the end result for each request(caching notwithstanding). The files are already in the static format (HTML, JS, CSS) that your browser can understand and display properly. So, quite literally, the only thing that the server needs to do is to simply pass them as they are to the browser.
JS Frameworks
Front-end JS (JavaScript) frameworks like React, Ember, Knockout, Backbone.js, AngularJS, etc, have grown tremendously and are plenty capable of creating beautiful and very functional apps without the need to generate markup on the server. With JS taking care of our presentation layer, the only thing that is left to do is to pass and receive dynamic data, and that’s where “serverless” components (Functions / Lambda) come in.
Serverless functions
In reference to cloud offerings such as Functions and Lambda, “serverless” means that one doesn’t have to provision a compute instance (virtual or physical hardware), or the equivalent of a software server, such as Windows Server, Apache, Tomcat, or NodeJS. All of that is done for you on each respective Cloud(Azure / AWS). One simply writes a function that will handle certain logic when it is called. The drawback is that you are only able to utilize certain languages. At the time of this writing Azure Functions supports “C#, F#, Node.js, Python, PHP, batch, bash, or any executable”, and AWS Lambda supports “Node.js, Java, C# and Python.”
The payment structure differs significantly from compute instances, to the point where you may be able to utilize the service completely for free on both AWS and Azure, where first 1,000,000 requests per month won’t cost you anything*.
Sample Solution(with React)
1. Create a barebones React application (if you don’t already have React installed, you can do so by following the official guide )
create-react-app serverless
2. Open the application in your favorite editor and replace the App.js file with this one
3. We won’t build the solution just yet, as we still need to create a Lambda / Functions function to serve as our endpoint. We’ll come back to this app as we start integrating it into each respective cloud.
Continue tutorial for AWS here.
Continue tutorial for Azure here.
To close this article out, I need to mention that this barely scratches the surface of what serverless computing is capable of. The scenario covered here is architecting an app without a compute instance and supporting it with Azure Functions and AWS Lambda to bring in traditional functionality. But, serverless compute offerings are extremely powerful tools and are able to respond to triggers within the cloud ecosystem and perform tasks based on those triggers – such as database changes, changes in files stored/uploaded, act as mobile back-ends, and much-much more.
* other than storage space for your function, and unless you are delivering huge amounts of data with it