--- title: "Foxwoods: A Premium Experience on a Headless CMS | Shockoe" description: "How a decoupled Drupal CMS and an AWS-hosted middleware let the Foxwoods team manage offers, events, and dining content in its mobile app." canonical: "https://shockoe.com/insights/foxwoods-powering-a-premium-experience/" --- # Foxwoods: Powering a Premium Experience with a Headless CMS > How a decoupled Drupal CMS and an AWS-hosted middleware let the Foxwoods team manage offers, events, and dining content in its mobile app. [← Insights](https://shockoe.com/insights/) [Hospitality](https://shockoe.com/insights/category/hospitality/) How a decoupled Drupal CMS and a middleware layer let the Foxwoods team manage the content behind its mobile app. By Caleb Hatcher, November 19, 2025 | 4 min read The short answer A headless setup separates the Foxwoods mobile app from its Drupal CMS, with a middleware layer in between. The Foxwoods team edits offers, events, menus, and dining content in the CMS, and the app picks the changes up without a new app-store release. Caching and fallback images keep the app fast and complete. *Foxwoods casino lobby under a glowing orange ceiling with the Foxwoods logo* Foxwoods Resort Casino wanted a mobile app that could show guests current offers, events, and promotions. That meant a backend that was flexible enough for the Foxwoods team to manage and dependable enough for guests to rely on. The answer was a decoupled, or headless, Drupal content management system. This article walks through how it fits together and what we learned building it. ## How does the headless architecture work? In a headless approach, the mobile app is separate from the content repository. Foxwoods’ content lives in Drupal. Between the two sits the Foxwoods middleware (MW), which fetches content from Drupal and serves it to the app. That makes the middleware the app’s main source of truth, so the app can focus on the guest experience. | Layer | What it does | | --------------- | ----------------------------------------------- | | Mobile app | Shows content and handles guest actions | | Middleware (MW) | Fetches, caches, and serves content to the app | | Drupal CMS | Stores offers, events, dining, and menu content | Keeping these layers apart means the team can improve the mobile interface without being limited by a traditional monolithic CMS. We cover a related integration problem in [the real cost of a disconnected booking engine](https://shockoe.com/insights/real-cost-disconnected-booking-engine/). ## What runs on AWS? The middleware and its supporting services run on Amazon Web Services, built to scale, stay secure, and need little hands-on operation. The Drupal CMS is hosted separately from these services. Key AWS pieces include: * **Amazon ECS** to host the middleware application. * **Amazon RDS** for the middleware’s database. * **Amazon CloudFront** to deliver static assets such as images, CSS, and JavaScript. * **A managed authentication service** for guest sign-in. * **Amazon S3** for fallback images and files used by the middleware. ## How can the team change the app without a release? Because the CMS is separate from the app, much of the experience is content, not code. The main Explore menu is not hard-coded. Administrators manage it through custom configuration pages in the CMS, and the app receives it through the JSON:API. The Foxwoods team can update and rearrange the main navigation without publishing a new version of the app. The same idea applies deeper in the app. On the Dining screen, each restaurant is a piece of structured content in Drupal, so guests can filter the list by taxonomies defined in the CMS, such as restaurant type or cuisine. We also built a custom Open Now filter. It compares the current time to the hours stored with each restaurant, so a guest can quickly see where they can eat right now. *Foxwoods Activities screen on a phone with category filters and a hotel room photo* ## How do caching and fallback images keep the app responsive? One challenge was retrieving content and its assets efficiently. Getting an image from Drupal took two steps: one API call for the content, and a second call to get the image URL from the media node. With a lot of content, those extra calls can slow the app down. We added a Redis caching layer. When the app asks for content, the middleware first checks the cache. If the data is there, it returns it without another round trip to Drupal. Missing media was the second problem. If an image is not found, or its URL is invalid, the middleware requests a fallback image from a dedicated S3 bucket. Guests see a relevant picture instead of a broken one. ## What would we recommend to other teams? In our view, three habits carry over to any content-heavy mobile app: 1. **Separate content from presentation.** A headless CMS lets editors and app developers work without waiting on each other. 2. **Put a middleware layer in between.** It gives the app one dependable data source and a place to cache and clean up content. 3. **Plan for missing content.** A fallback image costs little and protects the guest experience. Combining a decoupled Drupal CMS, AWS services, and a caching layer gave Foxwoods a flexible foundation for its mobile app. You can see more of our hospitality projects in [our work](https://shockoe.com/our-work/), and our [services](https://shockoe.com/services/) page explains how we approach this kind of build. Planning a content-rich mobile app for your property? [Get in touch](https://shockoe.com/contact/). ## Frequently asked questions ### What is a headless CMS? A content management system that stores and manages content but does not decide how it looks. The content is delivered through an API, so a mobile app, a website, or another channel can each present it their own way. ### Why put a middleware layer between the app and the CMS? In our view, a middleware gives the app one dependable source for its data. It can combine, cache, and clean up what the CMS returns, so the app stays simple and the CMS stays free to change. ### Can the Foxwoods team change the app without a new release? For content, yes. The main Explore menu and the content on screens such as Dining are managed in the CMS and delivered to the app through an API, so editors can update them without an app-store release. ### What happens when an image is missing in the CMS? The middleware falls back to a default image kept in an AWS S3 bucket, so guests see a relevant picture instead of a broken one. *Portrait of Caleb Hatcher* Caleb Hatcher Lead Full-Stack Engineer Caleb Hatcher is a lead engineer at Shockoe who works across the front end and the back end. He builds the cross-platform mobile and web interfaces, and the APIs and integrations behind them, that keep products fast, consistent and connected to the systems clients already run. Update offers, events, and menus without app releases, keeping guests connected to what is new. [Separate content from your app](https://shockoe.com/contact) Related insights ## Keep reading [Back to insights](https://shockoe.com/insights/) Hospitality ### [Elevating the Foxwoods Experience](https://shockoe.com/insights/elevating-the-foxwoods-experience/) 4 min read Hospitality ### [From Insight to Product: Building the Foxwoods Digital Ecosystem](https://shockoe.com/insights/foxwoods-from-insight-to-impact/) 4 min read Hospitality ### [Building a Golf App Design System for St Andrews Links](https://shockoe.com/insights/translating-brand-into-product-building-a-design-system-for-the-new-home-of-golf-app/) 5 min read Source: https://shockoe.com/insights/foxwoods-powering-a-premium-experience/