I am excited about the idea of helping more people become web developers. One way I think that new developers will be able to start learning faster is if they don’t need to deal with servers. So, that’s why I’ve been following the growth of the “serverless architecture” concept lately.
I thought the term “serverless” had a faint smell of BS. I imagine cloud hosting salespeople trying to pry control out of the hands of the “real” developers. But here is the thing, when I am trying to quickly solve a problem, delivery value or build a lean MVP, I don’t want to have to know about any more layers of the system than I absolutely have to.
At the core of most user-facing web applications is reading and writing data to some persistent storage. You might be writing an MVC app and your controllers need to have access to a SQL database for reading and updating the models. Or possibly your are displaying a set of data fetched from an API, either your own or an external service providers.
If you don’t have a “server” to handle passing the right data to the browser and processing the user’s input through business logic.
Auth0 and Rules
Auth0 offers something that might help, they are a hosted user authentication service. They can keep a database of all your users for you, or integrate with other identity providers. So when you click “log in” your users are going to their servers and they are sending the user’s browser back to a specific page when they prove they are who they say they are. I have been trying out their email magic links and I think it’s really simple and nice for users to never create, save or remember a password. When a user enters their email address on the sign in form Auth0 immediately sends them an email with a unique token link, clicking that link proves identity and sends them back to my application. Since access to the user’s email inbox is, in reality, a skeleton key that unlocks every account anyway, I think email magic links are the best option.
So anyway, Auth0 has “rules” that you can run when a user successfully authenticates. This is the perfect place to run server-side code to get a one-time key.
For instance Azure Table Storage is a cheap persistence layer very similar to Amazon DynamoDB. I wanted to learn how to use some of these databases because they are an excellent option for a serverless app. With Azure Table Storage you can request a “Shared Access Signature”(SAS) which allows an end user application to work with a limited subset of data. I created a rule in Auth0 that uses my master key to request an SAS that allows full access to records whose “partitionKey” matches the current userId. This newly generated token is passed along to the web application url