Case Study: eCapture

Client Name

Palm Beach Broadcasting, LLC

Industry

Marketing, Sports and Entertainment

Problem Summary

Palm Beach Broadcasting, LLC owns and operates radio stations in Palm Beach County.

The company broadcasts music and entertainment, as well as information on local news, traffic, and weather.

It also offers listeners and advertisers with local marketing resources, as well as provides advertising and marketing opportunities.

The company was founded in 2002 and is based in West Palm Beach, Florida. Palm Beach Broadcasting, LLC operates as a subsidiary of Digity, LLC.

One thing all the radio stations owned by PBB does is event marketing; often in the parking lots of country music concerts and other similar type events.

The common thread among these venues is the volume of foot traffic, which often renders cell data useless.

This presented a problem for PBB which wanted to collect email addresses for marketing purposes electronically, but had no way to save them.

Instead, they reverted to pen and paper signup forms, which were difficult to read and required manual entry after the event; not to mention they were not environmentally friendly.

Solution Summary

Gunner Technology rep encountered a PBB-owned station doing this at a concert and proposed a solution, which was to build an offline-capable app which could run on any Android or iOS device (phone or tablet).

The device would store the data on the physical device until it could get data reception and then it would sync the data to a central repository where all their marketing emails were kept.

Challenges

Fortunately, AWS AppSync makes most of the nitty-gritty of this very easy. The one challenge was building the app so that it could be skinned by an administrator quickly and without an account.

At any given event, the promotion may be co-branded, so the radio station may need to re-skin the app to include the logo of the other company and potentially change the opt-in text.

Technical Approach

This project was tailored for AWS AppSyc.

AWS AppSync automatically updates the data in web and mobile applications in real time, and updates data for offline users as soon as they reconnect. AWS AppSync makes it easy to build collaborative mobile and web applications that deliver responsive, collaborative user experiences.

We use AWS AppSync to build native mobile and web apps with iOS, Android, JavaScript and React Native.

AppSync let us specify the data requirements of the application with simple code statements and iterate quickly during the prototyping and development process.

AppSync uses GraphQL, an open standard query language that makes it easy for applications to request data from the cloud.

AppSync automatically manages all the data operations for offline users. The service supports an offline programming model where application data is not only available for users who are offline, but users can also add and update app data locally as well. This makes it easy to build apps that cache important data locally for offline use, and then synchronize with the cloud when the device reconnects.

The service integrates with Amazon Cognito and AWS Identity and Access Management, allowing us to set fine-grained permissions on GraphQL operations that put strict controls on who can access the data.

AppSync makes it easy to combine data from different sources. With AppSync, we could access data in Amazon DynamoDB, trigger AWS Lambda functions, or run Amazon Elasticsearch queries and combine data from these services to provide the exact data we needed.

Project Management Approach

We started out with nothing (no mocks, no wireframes, etc), so we started with two research sprints.

This was followed by two design sprints in which we mocked out the UI.

However, instead of using design tools like Photoshop, we did it using React with mock data.

After we had a UI we began our usual pattern:

1) One week function sprint where we added new functionality
2) One week QA sprint
3) One week bug fix sprint

Repeat until finished.

This was absolutely necessary due to the shifting requirements and scope mentioned in the challenges section.

Project Roles

Lisa Brignac – Project Manager

Keith Cohn – Designer

Cody Swann – Front-end Engineer

Dary Merckens – Backend Engineer

Proficiencies Used

• agile
• Android
• API
• API Gateway
• Apollo
• AppSync
• availability
• AWS
• AWS Availability Zones
• AWS Regions
• backend
• Bug Sprint
• CodeCommit
• Cognito
• Continuous Deployment
• CSS
• deploy
• Design Framework
• DevOps
• disaster recovery
• distributed service
• DynamoDB
• ES6
• Feature Sprint
• frontend
• functional design
• functional requirements
• git
• Graphql
• HTML
• immutable
• iOS
• iteration
• iterative
• JavaScript
• Lambda
• Material Design
• Mobile Hub
• native app
• Node
• non-functional requirements
• NoSQL
• NOTS
• production
• React
• react native
• Redundancy
• research sprint
• RxJS
• S3
• scalability
• SDK
• serverless
• Serverless Framework
• sprint
• technical requirements
• the cloud
• Tolerant
• uptime
• version control
• fastlane

Lessons Learned

This was an extremely compressed deadline, so we learned the importance of streamlined deployments which is why this is the first project we integrated Fastlane with Fabric and Testflight for automated builds and deploys to QA.

Benefits

PBB has deployed the app to all of their radio stations and has been able to save roughly 10 hours a week they previously spent on data entry.

Additionally, they save roughly $200 per event on print costs and have reduced their carbon footprint significantly.

Why Gunner Technology?

PBB didn’t even know this was possible until Gunner suggested it, so we had a pretty good inside track to getting the gig.

That said, we had done similar work in marketing for Country Shore so we had some case studies to show PBB as illustrations

Project Screenshots

Architectural Description

GraphQL Proxy

A component that runs the GraphQL engine for processing requests and mapping them to logical functions for data operations or triggers. The data resolution process performs a batching process (called the Data Loader) to your data sources. This component also manages conflict detection and resolution strategies.

Operation

AWS AppSync supports the three GraphQL operations: query (read-only fetch), mutation (write followed by a fetch), and subscription (long-lived requests that receive data in response to events).

Action

There is one action that AWS AppSync defines. This action is a notification to connected subscribers, which is the result of a mutation. Clients become subscribers through a handshake process following a GraphQL subscription.

Data Source

A persistent storage system or a trigger, along with credentials for accessing that system or trigger. Your application state is managed by the system or trigger defined in a data source.

Resolver

A function that converts the GraphQL payload to the underlying storage system protocol and executes if the caller is authorized to invoke it. Resolvers are comprised of request and response mapping templates, which contain transformation and execution logic.

Identity

A representation of the caller based on a set of credentials, which must be sent along with every request to the GraphQL proxy. It includes permissions to invoke resolvers. Identity information is also passed as context to a resolver and the conflict handler to perform additional checks.

AWS AppSync Client

The location where GraphQL operations are defined. The client performs appropriate authorization wrapping of request statements before submitting to the GraphQL proxy. Responses are persisted in an offline store and mutations are made in a write-through pattern.

Architecture Diagram