6 Tricks for Simpler Cloud CV
By: Joey Anuff
Tags: Machine Learning, Nextjs, AWS, Computer Vision, AWS Lambda

To follow along with this demo, initialize a free Cassandra database at DataStax, whose super-simple new Documents API we’ll be using for our backend. Make note of your username, password, cluster/database ID, region, and namespace. Init a new Next.js app and install these extra dependencies:

npm install aws-amplify axios axios-auth-refresh react-query react-query-devtools react-rough roughjs sass

It was meant to be irresistibly simple: a quick ML app to upload comics to the cloud, perform fancy Computer Vision operations on them (OCR and translation), and correct the transcripts on a personal cloud database.

And it was simple! Well, the code was simple–my two AWS Lambda functions were maybe 10 lines each. Properly configuring permissions for the associated AWS services, though, was another story–I spent two days just trying to log my Lambda console–but mercifully, a story with which I need no longer bore you.

1. YOU MIGHT NOT NEED THE AWS CONSOLE

In my quest to outsource the AWS set-up nightmare, I found something absurdly better: Amplify CLI, a straight-forward command line tool that gently steps you through your AWS cloud service inits.

Consider, just for a few seconds, this unholy mess of a config file:

How much don’t I want to explain what each of these lines does.

Amplify takes care of all of this for us. It even says “WARNING: DO NOT EDIT” on the config file, an order I couldn’t be happier to follow.

A full log of my project inits is in the Github repo.

2. YOU MIGHT NOT NEED LAMBDAS

A simpler Lambda set-up is what led me to the Amplify CLI in the first place. Instead of zipping all your dependencies into “Lambda Layers” and coding inside Amazon’s web dashboard, Amplify lets you code locally and commit to AWS when you’re ready. As it turned out, using Amplify meant I didn’t need Lambda functions at all anymore.

My prototype app used two custom Lambda endpoints, configured using Amazon’s Gateway API: a Node.js function to save images to S3 and a Python function to call Amazon’s Textract OCR service. With Amplify, both of these are one-liners.

3. YOU MIGHT NOT NEED BASE64

My original Uploader Lambda required base64-formatted images. On the client side, I needed a base64 component to do the same thing. And still I wound up fiddling with the string at both ends. Brilliantly, Amplify’s Storage object takes care of both conversions for us.

Tell me you can’t figure out what’s happening here.

4. DON’T USE LAST YEAR’S APIS

My big note-to-self for all of this, I suppose, is don’t use old APIs–and when it comes to cloud infrastructure, last year’s APIs are probably too old.

It’s the same situation with DataStax database I’m using to store my transcripts–with their new Stargate APIs, I can access my scans as REST, GraphQL, or plain JSON, as I do here via their Document API:

(More on my DataStax translation database coming in part 2, stay tuned.)

5. DISABLE SSR FOR CLIENT-SIDE LIBRARIES

It makes perfect sense that you client-side graphics library wouldn’t render on the server side, but understanding the nature of the error (and the fix) took me longer than I’d like to admit.