Ramkumar Shankar

EyeJack Backend

Serverless infrastructure to support EyeJack Creator and mobile apps.

Project Serverless backend infrastructure to support EyeJack desktop and mobile apps, with integrations to support billing and payment plans.
Client EyeJack
Period Oct 2019 — Present
Delivery Serverless GraphQL api using AWS AppSync, Lambda functions and Cognito to support user accounts. Billing integration with Stripe.


EyeJack is an augment reality (AR) platform for artists. With the EyeJack Creator, the goal was to build the easiest way to create AR art. I was approached to build on the work done for the EyeJack Creator, and deliver a technology platform that can support current and future business requirements. In particular, we wanted to remove legacy cruft and standardise various services, support rapid iterative development allowing the team to introduce new features for users to manage their artworks and support payment plans.

The solution was a serverless backend implementation built on AWS using a variety of services including AppSync, Cognito, Lambda, API Gateway and DynamoDB. This reduced complexity and maintenance effort significantly, and greatly improved the team's velocity and cadence.

EyeJack backend AWS architecture diagram



Access to the API is controlled by a AWS Cognito user pool and federated identities. Client applications only have privileges to access specific parts of the API to support required functionality. Cognito based access is also enforced for AppSync mutations and subscriptions.

GraphQL based API

A serverless GraphQL based API, using AWS AppSync, is the API end point for all desktop and mobile clients. The application also uses pipeline resolvers for complex operations, and Lambda functions implement integrations with external services such as Stripe.

API Gateway & Cloud functions

In additional to Lambda-based resolvers for the API, I also implemented cloud functions to handle post user sign-up, and webhooks from Stripe.


The data layer is implemented with DynamoDB. It was designed based with the necessary secondary indexes, based on the the required query patterns. Many-to-many relationships are supported by adjacency list patterns.