Project Overview

Grill’d required a range of applications across their digital ecosystem to access and ingest canonical data easily within the Grill’d architecture, Ideally, this would be achieved through a single API that unified disparate data sources and made them consumable through a single endpoint.

With this in mind, a comprehensive API was required to provide a vast range of granular data, including product data, nutritional information, localised product availability, user preferences, orders and more.

Project Commissioner

Grill'd

Project Creator

Evolution 7

Team

Antony Corrales - Digital Project Manager
Rom Palmas - Lead Developer
Kemble Song - Front End Developer
Thoai Nguyen - Back End Developer

Project Brief

Tasked with providing a collection of data from multiple sources, the Grill’d API required create, update and delete functions across a range of common data sets. In addition to standard restaurant information (opening times, contact details, user reviews and lat/long) there was additional requirement for incorporating organisation-specific dynamic data, such as each restaurant’s ‘Local Matters’ organisations of the month and the corresponding information, allowing the client to upload their monthly revisions and have this pass into the API.

Understanding that consuming applications would often require granular extracts rather than full data sets, easy to retrieve product data was structured as part of a RESTful API, allowing for singular products to be retrieved with corresponding product attributes around pricing, product additions and availability.

Further than the conventional data required as part of an API in this field, the brief presented additional complexity to be handled in other areas. Including member identification QR codes for in-restaurant processing, reward redemption strings extracted from external database’s and user preferences from user management software, the brief required users to seamlessly update their communication preferences and product based data across a range of online properties.

User Experience

The API is consumed simultaneously by thousands of users and is built to handle millions. Being the single source of truth and accessed by multiple devices, it was very important from the start to think about scaling and caching ability.

Speed is one of the most important factors when it comes to user experience and the solution design and hosting infrastructure backing up the API has been built to respond and scale to extremely high volumes of users. At peak times this can exceed hundreds of thousands of daily users. High performance is achieved by taking advantage of AWS API Gateway, backed by the AWS network of edge locations and by utilising caching systems, we avoid unnecessary access to the backend systems and have proved that we can withstand any traffic spikes. Additional caching performance is provided by Cloudfront caching, which utilises the AWS CDN to deliver the JSON results at blazing fast speed.

Grill'd partners need easy access to the API, and a well-documented system that they can integrate with easily. Following best practices, it was built following RESTful architectural style and is REST-compliant to offer interoperability and easy access between computer systems. The API is also fully documented using the Swagger specification, a powerful definition format for easily developing and consuming the API. By enabling those technologies and following logical conventions, it becomes very easy to share the API among all Grill'd partners and vendors.

Project Privacy

Utilising AWS API Gateway authentication controls, access is tightly controlled and any consuming application must provide the correct credentials to gain access, which includes private access keys and an additional API token to be sent in HTTP headers with every request.

Through the different layers of customisation, resources can be accessed by selected users and prohibited to others. By doing so it provides fine tuning and level of granularity to create a powerful mesh of access level for different use cases.

For example, a core Grill'd application, being one of the consumers, requires full and unlimited access to the API whereas a third party vendor or application might only require access to Grill'd restaurant locations and will be allowed to query the API once a day, or once an hour. This can easily be achieved by creating usage plans, to define throttling and quota, and create policy rules to allow access to specific resources like restaurants but prohibit access to user data.

In a matter of minutes, the API can be customised to achieve the required level of protection and revoking access is as easy as one click.