HOW A DRUPAL MODULE
CONNECTED MULTIPLE SITES FOR AN INTERNATIONAL BRAND.

Keith Caulkins
KEITH CAULKINS

When atLarge starts work with a new client, we aim to learn and discover what’s most important to their business and how we can help in these areas, even if they themselves aren't aware yet.

CONSUMING AN API

The atlarge way

With Feld Entertainment, we quickly discovered that ticket sales and purchasing are at the very core of their business. We learned that they have an API that feeds ticket information to each of their property's websites. This was good news for us, but there were a few problems with the current implementation of it:

  1. Each site consumed the API differently, which means there were different implementations of the ticketing system. As a result, the work done to one website couldn’t be easily replicated to any of the others.
  2. Several of the websites could not cache the tickets pages due to the way they consumed the API.
  3. Most of the implementation was hard-coded on each site, which means only a developer could change settings for the site's ticketing system.

ENTER F2

Feld Force

F2, or Feld Force, is a Drupal 8 module created by the atLarge team that consumes Feld's ticketing API. It was built to be modular, scalable, and usable on any Drupal 8 site created for Feld. It also solved each of the issues outlined above.

F2 was created with the purpose of existing on all Feld sites and to be the answer to any ticketing needs. Because of this, it was created to plug-and-play with minimal requirements, and work seamlessly on Drupal. As a result, any updates our team makes to it can be transferred easily to each Feld site using it.

F2 is extremely cacheable. It consists of several calls to Feld's API, each one individually cacheable. Additionally, a large portion of F2 was built using javascript, meaning a chunk of the work can be done in the client's browser, rather than on our servers.

A settings page within Drupal exists for F2 where most functionality can be controlled. For example, individual cache settings for each API call can be set.

GEOLOCATION

a closer view

Something nearly every Feld site has is a geolocation area. It's usually on the homepage as well as the tickets page and is used to locate the nearest event to an individual user. In the past this had been done through PHP using a service called Maxmind, which creates a caching issue. Users would see shows for cities very far away from them because they had been cached by another user. The only way around this was to turn caching off on the affected pages. 

To fix this, F2 uses Javascript to handle geolocation, so the rest of the page can still be cached. Additionally, F2 utilizes both CloudFlare and Maxmind geolocation services - so if one were to become unavailable the other is there as a backup.

CACHING API RESPONSES

Events

Previous implementations of Feld's API would tend to break if the API became unavailable. Because many of these sites were not cached, there had been a heavy strain on this API that could sometimes cause it to become unreachable. To combat this, F2 caches API responses.

F2 also saves each event from the API as its own node within Drupal. This has two main benefits. The first is that it lets Feld’s content administrators customize events with content or data that isn’t present in the API response. It also allows us to serve these nodes rather than a direct API response, which means we access the API a significantly less amount than with previous implementations.

Another huge benefit for content administrators is that they can customize “widgets” throughout the site with ticket information. They have the ability to display a list of tickets, turn on or turn off geolocation within any page, etc.

LIKE WHAT YOU JUST READ?

Contact Us