NEXT.JS 10 // AWS AMPLIFY CLI // DATASTAX DOCUMENT API
6 Tricks for Simpler Cloud CV
(or How Not To Build A Comic Book Parser, Pt. 1)
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 sassIt 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:
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.
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.
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:
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.
6. MIND THIS NEXT.JS vs. AMPLIFY GOTCHA
Next.js 10 has a surprising ability to reflect style and code changes without triggering a browser reload, but sometimes a hard reload is unavoidable. Doing that a few times, I’ve found, is liable to cough up this show-stopping error from Amplify:
Error: Pluggable with name AmazonAIPredictionsProvider has already been added.
Until they update their Predictions plug-in to handle SSR–as they’ve already done with their Storage plug-in–here’s my quickest fix: just comment out the two lines as below and save.
This will instantly trigger a new error:
Error: More than one or no providers are configured, Either specify a provider name or configure exactly one provider
Which is your sign to uncomment the lines, reregistering the plug-in and allowing you to proceed as normal.
