Menu App Case Study
Menu Technologies is a Swiss company helping large restaurant chains streamline omnichannel ordering. Current clients include Burger King and Popeyes.
Omnichannel ordering has increased the complexity for large restaurant chains. Ordering options now include proprietary channels (kiosk, web, and mobile) digital marketplaces (Uber Eats, Doordash, etc.), and social channels (like Facebook Messenger). Not all options integrate with point-of-sale (POS) systems, necessitating manual entry.
Menu integrates all orders into one data hub. This hub connects to payment processors, POS systems, and analytics tools. This simplification reduces operational complexity while improving data gathering and analysis.
Platform Architecture Development
Develocraft was expected to deliver Menu’s first working MVP in 30 days. We took just 20.
Develocraft then began expanding Menu’s features.
One Menu client requested help improving their Marketing Website operations.
The client wanted to empower their marketing department to quickly and easily create SEO-optimizable landing pages capable of handling millions of visitors.
Menu approached Develocraft to help develop a custom static site generator. For scalability and flexibility, the solution had to be headless, horizontally scalable, and able to support millions of unique sessions.
The site generator also had to support multiple simultaneous users (multitenancy), internationalization, make content management simple, and handle advanced user permissions and access.
The time constraints meant we needed to leverage existing code to build a platform.
The main challenge was to find an available CMS solution to form the core of the system that would meet requirements.
To test the potential solutions it was decided that we first needed to research possible solutions and build a proof-of-concept (PoC).
Project requirements led us to use Jamstack architecture with a Static Site Generated (SSG) frontend.
Our system has three elements:
- CMS - generates JSON files with the content, branding, internationalization, and so on
- Builder App - receives JSON file as an input to the frontend application - in this case Nuxt.js
- Front-end - served from CDN
With this approach, we do not have to worry about load balancers for the API, scalability, or expensive machines. It’s also easy to find developers to work on each element (e.g. CMS developer, Builder App developer, Next.js developer).
To mitigate the need to build and deploy for every content update, we introduced incremental builds.
Choosing a CMS
Our first choice was to test Strapi as a possible solution. Being a certified partner – one reason Menu Technologies approached us – and big fans of Strapi’s CMS we were eager to see whether we could use it.
The table below describes each CMS we considered.
|CMS||Multitenancy||i18n||REST API support||Ability to self host||Open source|
State as of January 2021
Most CMSs lacked at least one crucial feature. However, Headless Wordpress proved workable with easy support for multitenancy and internationalisation.
In Jamstack WordPress is merely a CMS.
Here are the considerations that ultimately led us to propose Wordpress:
- It was the only viable, deliverable solution in 30 calendar days
- It was easy to integrate multilingual support
- it includes RTL and non-Latin support (right to left Text)
- The availability of multisite support
- Out of the box drag and drop support for a page editor
- User-level support out of the box
- A rich ecosystem
In our setup, Wordpress would only be used to create content and deliver plugins. Once content is created, this starts up a Node.js builder that processes the site. The builder fetches the data that pages will pull in by extracting queries from the code and executing them. The result is static HTML and JS files ready to go.
With the architecture decided, the team started work on the MVP. The deadline for the initial MVP was very short with the first version due to be presented to Menu’s client in just 20 days.
Once the MVP was accepted, we started expanding the features and capabilities. This meant creating a rich component library. Additionally, we set to work preparing the back end to handle multitenancy. The business in each country became a separate tenant as with internationalisation supported.
Some technicalities In this chapter we will briefly discuss the technicalities. Rather than being totally unique, these details reflect our adaptation of a standard Jamstack approach as well as of GitFlow.
Our AWS infrastructure requirements were simple. For this project, we used the following services:
- EC2 machine (for CMS and builder) - 1 machine per environment
- S3 buckets (one per domain)
- CloudFront (one per domain)
- We have one Lambda @Edge function to handle redirects - neither Nuxt SSG nor Next SSG handle 301 / 302 redirects well (as per January 2022). It was simpler to introduce the Lambda function. We have valid 301 redirects.
During Develocraft’s work, the Menu marketing team was in the process of refreshing their own website. The aims were faster performance and a modern aesthetic. The marketing team also wanted the ability to build their own landing pages from existing components without engaging developers.
These were basically the same requirements that Menu’s client had. The decision was made to use the existing platform internally, too. This had several advantages:
- Most of the heavy lifting was already done
- We could receive more feedback from the internal team about the platform
- The Menu tech team did not want to support yet another CMS or tech stack.
Launching a new website allowed the marketing team to be much more agile in marketing without jeopardising the website speed and performance.
We decided to let the results speak for themselves.
The Menu Website lighthouse report:
We currently have a roadmap for the year ahead and believe that the sky's the limit. There are many opportunities for this project to expand and we hope to be an active part in it.