– Qvault is an Electron based password manager with a focus on cryptocurrency

– The focus has been a secure desktop app but a browser extension is coming soon

– Creating a secure browser extension without sharing your master key

– It’s an open source app, so if you’re skeptical you can compile it yourself

– Motivation for using Golang for the Serverless component

– For personal projects learning something new (Serverless) is worthwhile

– The TL;DR on what Serverless is and how it works

– AWS API Gateway helps map Serverless functions to HTTP requests

– Instead of 1 app with many routes, you have many individual functions

– A Serverless framework called Serverless helps tie everything together

– Tying in a Serverless function to a specific URL endpoint

– Calling these URL endpoints from the Electron app is like any other REST API

– What’s being executed within these Serverless functions?

– When it comes to Bitcoin and cryptocurrencies, it’s all about privacy and security

– Passwords are encrypted client side in the Electron app

– Encrypted vault file gets saved client side and it’s optionally saved server side too

– This data is stored inside of PostgreSQL using RDS within AWS

– Electron app -> API endpoint -> Serverless function -> data gets written to Postgres

– Using a managed database vs managing your own database

– The developer / development experience for writing Serverless functions

– When hacking on a new Serverless function, it just gets pushed to production

– The 2 biggest Serverless wins are function isolation and scaling auto-magically

– Serverless scales to the size of your wallet

– But it also costs nothing if no one is using it

– The turn around time for AWS to spin up an environment to run a Serverless function

– Function warming helps keep spin up times to milliseconds

– There are tricks to keep your functions warm to avoid a multi-second spin up time

– For Qvault’s API, response times were never a problem partly due to using Golang

– The Electron app is written in JavaScript using Vue

– Electron is basically a browser bundled with a specific JavaScript app

– Electron apps can be pretty bloated but it’s super convenient to develop with

– On Arch someone made a package that tries to use what you have installed already

– A recap of which AWS services are being used

– Using Route 53 on AWS for DNS hosting saves a lot of headaches

– Wait, how is CloudFront (Amazon’s CDN) being used on the back-end?

– It’s not, but CloudFormation is (it’s so easy to mix up AWS service names!)

– The TL;DR on what CloudFormation is, how it’s being used and why it’s useful

– Serverless framework converts platform agnostic configs into platform specific configs

– CloudFormation is especially handy for Serverless due to the number of endpoints

– Every Serverless endpoint is being served over HTTPS with Amazon’s ACM SSL certs

– There are no external software as a service dependencies besides what’s on AWS

– For logging, error reporting and metrics it’s all AWS services

– Getting logs from a Serverless function involves using CloudWatch and S3

– One nice thing about Serverless is there’s no long running state

– Strategies for dealing with database migrations with a Serverless set up

– Dealing with long running migrations that surpass AWS Lambda’s 15 minute timeout

– Lane is a big fan of CI / CD and the master branch always matching production

– A CI pipeline is being used for the Electron app with Travis CI

– The Electron app has an auto-update function to check for updates on demand

– The Serverless side of things doesn’t change much and there is no CI pipeline

– The turn around time is nearly instant for a new function version to take effect

– The Serverless framework sets environment variables for secret / sensitive values

– The work flow for changing a sensitive value to an existing Serverless function

– Dealing with disasters and malicious users

– Qvault hashes passwords before it’s sent to the server

– Running all of this on AWS costs in between $20 and $30 / month

– On AWS it’s easy to upgrade to a larger instance size but it’s hard to downgrade

– The RDS instance is running on a t2.micro since the DB is very simple

– Most of the app’s complexity is client side in the Electron app

– There’s 53k+ lines of code but that includes the node_modules/ directory

– The app itself has about 3-5k lines of code across ~40 files

– The complexity being on the front-end is necessary due to security requirements

– Lessons learned? Serverless couples your app logic to your provider, it’s not great

– There’s a lot of DevOps complexity where you trade 1 ops problem for another

– But Serverless is likely easier to set up than an entire Kubernetes cluster

– That being said, Serverless is very cost effective for low traffic APIs

– Lane would likely choose Serverless again for his specific use case

– Another nice thing about Serverless is not having to worry about scaling up

– Should you use Serverless for a traditional web application?

– It really depends on what you care about, such as cost vs development speed

– Serverless can get really expensive at larger scale (more so than regular hosting)

– You can find Lane on Twitter at @wagslane and his app can be found at qvault.io