Building an image processing app with GraphQL and async serverlessHere’s how I used GraphQL to build an image processing app that converts an image to sepia asynchronouslyRishichandra WawhalBlockedUnblockFollowFollowingMar 25TL;DRImage processing is best done asynchronously so that the state is not lost when the app is refreshedServerless functions can be used to run the image processing logicRealtime GraphQL helps you be in sync with the processing stateHasura GraphQL Engine gives instant realtime GraphQL APIs over PostgresSource code: client, image processing logicIntroductionIn this post we’ll build a basic image processing app that lets you upload an image and add a sepia tone to it asynchronously.
We will not go into the code subtleties as this is more of a philosophical rant about how async image processing apps can be built using realtime GraphQL and serverless.
We’ll use:Hasura GraphQL Engine as a free realtime GraphQL server over Postgres.
Hasura gives you realtime GraphQL APIs over any Postgres databaseAn event sourcing system to trigger external webhooks on mutationsPrerequisitesKnowledge of consuming a GraphQL APIKnowledge of some front-end framework.
An example is given with ReactJS, but you could use anything.
ArchitectureThis app follows the 3factor.
app architecture pattern.
3factor app is an architecture pattern for resilient and scalabale fullstack apps.
It involves:Realtime GraphQLReliable EventingAsync serverlessOlder architecture vs 3factor architectureIn case of our image processing app, the flow of the application would be:The client uploads the image to cloud and inserts the image URL into the database with a GraphQL mutation.
The client then watches the changes in the database for that particular image with GraphQL subscriptions.
When the image URL has been inserted in the database, Hasura’s event system calls an external webhook with the image detailsThe external webhook converts the image to sepia tone, uploads the converted image to cloud and updates the database with the converted image URLThe client receives the update when the converted image has been uploaded to the database (GraphQL subscriptions)BackendFirst step is to get a realtime GraphQL server running in the form of Hasura GraphQL Engine.
Click here to deploy it to Heroku’s free tier with free Postgres (no credit card required).
Data modelWe need only one table for this app.
When you create this table called images, Hasura provides the following root fields in its GraphQL schema:images: To query or subscribe to the list of messages (comes with clauses such as where, order_by, limit)insert_images: To insert one or more images into the images tableupdate_images: To update one or more images in the images tabledelete_images: To delete one or more images in the images tableImage processing logicWe need our image processing logic that takes our uploaded image and adds a sepia tone to it.
This could be written in any language or framework and deployed on any platform.
For example, in NodeJS, you can write this logic using JIMP and serverlessify it using Zeit.
Pseudo code looks something like:The above function simply takes an object of the following form, converts it to sepia and stores the converted image at /tmp/<id>.
png.
{ "id": 233, "image_uri": "https://mycloudbucket.
com/image"}Once the image has been converted, you also want to update the converted image URI to the database.
Event sourcingHasura lets you define event triggers that listen on mutations and invoke an external webhook with the mutation data.
We will create one such event trigger that listens on insert_images mutation and calls the webhook that performs the logic discussed above.
With this, our backend is ready.
FrontendMost of the logic happens on the backend, so the front-end stays fairly clean.
The front-end has two screens:Upload screen: Uploads image to cloud, inserts the image URL in the database and redirects to the Convert screen with URL param id=<image_id>Convert screen: Waits for the image to get processed and shows the converted imageUpload screenThis screen does the following:Takes image from userUploads image to cloudInserts this image in the database with GraphQL mutationRedirects to the new screen with URL parameter id=<image_id> where image_id is the unique id of the inserted imageThe GraphQL mutation for inserting the image to the database looks like:The above mutation inserts the image URI to database and returns the id of the inserted row.
Next, you redirect to the Convert screen where you wait for the processed image.
Convert screenIn the convert screen, you look at the id of the image in URL parameters and make a live query to the database with GraphQL subscriptions.
The subscription looks like:While rendering the UI, you would check if the received converted_image_uri is null.
If it is, you show a loading indicator, or you show the converted image.
If done in React with Apollo's Subscription components, it would look something like:As you see, in the above component:If there is an error in subscription, we render some error UI.
If the subscription is in loading state, we show a loading UI.
If the subscription response is empty i.
e.
there is no row in the database where id is equal to the given id, we say that the id in the URL parameters is invalid.
If we get a response but the converted_image_uri is null, we assume that the processing is still in progressIf we have a valid converted_image_uri, we render it.
Finishing upWe discussed a pattern to build async image processing applications.
You could use this architecture to build mostly all kinds of async applications.
Check out 3factor.
app and hasura.
io to know more about building resilient and scalable fullstack applications.
If you have any questions, stack them up in the comments and they’ll be answered ASAP.
Originally published at blog.
hasura.
io on March 26, 2019.
.