In this part of the series we’ll be building a API endpoint to serve our spreadsheet to track crypto wallets! You can find the repo serverless google HERE In case you missed it the other posts of my Serverless series: : (building a Serverless function to run FFMPEG when a file is uploaded to a bucket) This article Part 1 Beyond the over simplistic todo apps and into the world of reality Part 2: Intro **What we want to do:**Whenever we open our google spreadsheet, we want it to check our wallets in real time to see our balance. The result will look something like this: **Why serverless:**We could use serverless in this case to quickly deploy a scalable API to run an arbitrary amount of lookups for various wallets. Also, we’d only call the endpoint when we’re browsing our spreadsheet, so it’s nice to not have to pay for those days the spreadsheet is closed. The Code Luckily this isn’t as advanced as part 1. I know I promised beyond simplistic todo apps, but I think this is a valid use case for serverless, something simple, small, yet very powerful. 1. The serverless.yml This is a pretty straightforward Serverless configuration, we have one handler, it’ll be the one serving back the balance. As you can see in the http path, we’re taking in a parameter , which will be the wallet address. id One thing to notice (as we saw in part 1), is the plugin used to allow us to run things locally before we deploy. Another thing we introduce here is the concept of an . We wouldn’t want anyone to just abuse our system! We also define username and password env variables to check against once we deploy. authorizer for this lambda Sidenote: Type for the serverless framework allows us to just check against normal . You can read more about . request basic auth different authorizer types here 2. ⚡ The handler.js ⚡ In my serious attempt to not re-invent the wheel I found a node module to query various crypto backends/nodes to figure out a balance that an address holds! Great! crypto-balances For those interested in how it works, check out the source. that really intrigued me was how we could pass in any address and that it figures out which service/node to query for a balance. Now I quickly realized this module hasn’t been updated in 2 years and since we’ve had forks etc, which kinda screws with this auto detection! (Always room for improvement). One piece of the code You will also notice we never really add anything in this code for checking auth, this decision is made by the API Gateway to check it for you, which is a really nice separation. As you can see below we’re simply wrapping the result of the call into a response that serverless likes and off we go 🚀 crypto-balances Running it locally should look something like this: from news.bitcoin.com claims the ETH genesis address (0x00…0) has over 7k ETH. Let’s see if we can verify that! This article Our api works! Also, we’ve confirmed the claim. The genesis address does indeed have over 7k ETH :) One thing to note is that in this instance, our dependency chose to use to lookup the balance, it will vary by wallet address we’re trying to lookup. http://api.etherscan.io 3. Auth Alright, so we have a fancy api now. Cool, but what if we want to protect it? Perhaps we don’t want others to spam our poor little lambda! If you checked the screenshot above carefully you’d have seen a parameter to curl in order to pass auth. This is how it’d look if we passed the wrong info: --user test:test We get a nice 401 back! So how can we achieve this? Let’s dig into the authorizing code! We had previous defined an authorizer in the this makes our API gateway run our authorizer before letting anyone through to our lambda. serverless.yml On line 9 we construct our Basic auth string based on environment variables (which again were defined in the serverless.yml) On line 11 we then match with whatever is passed in the header by the caller. If it’s a match we return a crafted policy document, which includes the action (invoking the lambda) and the effect “allow”. authString carefully If it doesn’t match, we throw back a 401. 4. Deploying Let’s deploy this before we continue so we can use it with our google spreadsheet script. Using the serverless framework all we need to do is run: Making sure it works: sls deploy -v 5. The google spreadsheet code Once we have our serverless deployed it’s time to make it easy to query it from our sheet. Below is the complete spreadsheet code we need to paste into our google spreadsheet script editor. To add the script, open up the script editor like the screenshot below: Then paste it in and save! Conclusions I hope you enjoyed of this series going in to serverless a bit beyond the surface! part 2 A couple of real life problems encountered in this part: We learned how to utilize an . We passed in a basic auth header and matched it against the computed string by processing environment variables. authorizer in serverless We also looked at how to connect a spreadsheet with our serverless function to actually use it for something interesting. Thanks for reading! Please spread the ❤ with some claps and stars!
