akarasz.me

In the previous piece we redesigned the store interface for the backend in hope to have a better DynamoDB implementation to it. After the changes we have to provide a Load method that returns our Session object with the current version of it, and a Save method that will get the ID, the modified Session object and the (assumably) current version that matches the one we still have in the database; if the provided version does not match the current version, the method should return an ErrVersionMismatch error.

Originally I was planning to have the content of this post together with the previous one but while in the making I realized it was getting too long for a single post. On the flip side, now that the post was splitted in two, I have the chance to show some things in more details that I originally planned 🎉!

In the previous post we were wrapping our backend server into a lambda function. It is working just fine, but without a persistent storage layer there is no much worth to it; and the in-memory solution we have right now is everything but ideal for a serverless architecture.

The store interface we work with for the storage layer is a rather simple one:

• there is a Load method, which returns the Session object from the database if it’s present, otherwise returns an error
• and a Save, that inserts a Session with given ID

Couldn’t get any simpler, right?

The in-memory implementation uses a simple map for storing and retrieving the data and it’s prefect for the job; so let’s give a try for AWS’s flagship, key-value database, the DynamoDB - which, if you strip away all the fancy features, is just a simple map after all…

In this post we take a look on how optimistic locking is different from the usual, pre-locking approach and prepare the store interface for optimistic locking. In the next post we’ll have the DynamoDB implementation of this store that is using optimistic locking.

At a first glance it might sound controversial that I want to wrap a REST server - a typically long-running process - into a serverless function. I’m sure this trick won’t work with any services; in our case luckily there are some aspects of the pajthy backend that make this possible:

• the web server is included in the executable (for an excluded example think about standalon tomcat instance with a .war package)
• minimal ramp-up time before able to serve an incoming request (again, just compare your minimal java webapp startup time with a golang app with the same functionality).

Also there is an extra surprise in go’s standard library that comes handy, more on that later, I don’t want to spoil the fun! 😉

This time will walk you through how I moved the pajthy frontend - a single page site written in react and packed on top of an NGINX server in a docker container - into AWS.

SPA stands for Single Page Application; it’s a setup when all the assets that are in the application’s domain are loaded with the first request. It has the same purpose as why some games have loading screens: it will reduce the time of content loading during in-app.

The pajthy frontend is an SPA, just a collection of static assets. Also since CORS headers are set up properly in an “allow all for everybody” way it does not matter where the site is hosted; if it can be downloaded it can be used as well.

Saying that, the plan was to set up a new domain for pajthy (up until now it was using a subdomain for akarasz.me), have some of the signature AWS service, S3 (short for Simple Storage Service 💥), upload the artifacts and that’s it, we have lift-off!

Since I was a tad over-excited while drafting out the previous post, I had to split it: it would’ve been just too much for one. Instead I tried to separate the two posts so the first one starts explaining what this is all about while the second (this) one goes a bit more into describing things you probably already familiar with:

1. what I mean when I’m talking about “cloud”
2. comparsion of the basic building blocks for computing

and one that’s not that obvious: why did I moved from one cloud to another.

Serverless architecture is a recent interest of mine; in the last couple of weeks I was involved in a new project at work that’s running entirely in the AWS cloud. Since my most hands-on experience with the cloud so far was having a few virtual machines at Digital Ocean, I figured it’s best if I start exploring the Amazon Web Services at the beginning: with the ramp-up guide for the entry-level AWS certification, “Cloud Practicioner”.

Needless to say my motivation for finishing the entire course was dropping fast, but it was just enough for me to read through the (currently) 72 pages of “Overview of AWS” whitepaper listing all the available AWS services with a short (and very useful 🙄) marketing pitch. While reading the guide I realized, that the “lambda” service I heard about first a few years ago (and that time after a quick research I classified it as “useless”) is actually a quite interesting and useful tool when combined with additional services in the portfolio.

So what should one do after reading a few pages about something new and shiny? Tries it out in practice!