We’re extending our approach to front-end with a full-stack MACH architecture to deliver better user experiences.
We founded De Voorhoede 10 years ago to create better user experiences on the web. We decided to focus on front-end only, to put the user first and not be locked into a specific back-end technology. Back then we made products cross-browser (remember IE6?) and cross-device and viewport (CSS media queries had just landed!). And we had to explain why front-end development was a dedicated job.
With all these advances in web technology our work has changed as well. We’ve been building serverless projects for a few years. Our next logical step is embracing the new MACH architecture - Microservices, API’s, Cloud native software and Headless - to power our front-ends. We call this our full-stack front-end approach:
Ok, that’s not new. We’ve been doing this for 10 years. It’s our mission to build enjoyable and responsible products. That means user-friendly, fast, beautiful and at the same time accessible, privacy respecting and energy efficient.
Headless (the H in MACH) is the decoupling of front- and back-end. It enables us to build the front-end around the needs of the user instead of working from the philosophy and restrictions of a specific back-end. We select the technology and framework that best fit the project. We can build mostly static JAMStack sites, use a single page app framework (like React, Vue or Svelte), use an isomorphic framework (like Next.js, Nuxt, SvelteKit or Remix), build progressive web apps or anything else we can think of.
Cloud native back-ends
Cloud native (the C in MACH) software-as-a-service provides us with powerful back-ends off the shelf. These include hosting platforms - both (Node.js) server and serverless - like Netlify, Vercel, AWS and Cloudflare; databases like hosted Postgres, Firebase, Supabase, Fauna or D1; CMS’s like Contentful, DatoCMS or maybe even a headless WordPress or Magento setup; media services like Cloudinary, Imgix or Mux; email services like Postmark or Mailgun; and we can go on. Our job is to be familiar with these services, select the ones that are right for the product based on required functionality, reliability, cost, etcetera and configure them to the product’s needs.
API’s (the A in MACH) allow us to connect our front-end and all services together. We typically use REST with OpenAPI and GraphQL schemas as a contract between the services, combined with serverless or edge functions (Node.js, Deno, Cloudflare) and WebSockets for real-time applications. Everything from querying content, to persisting data to a database, deploying new versions of the product and communicating between web apps is achieved through API’s.
In truth, much of this new approach is something we’ve already been doing for years. So rather this is a logical extension of our current work. Our next steps in becoming front-end full-stack are actively training our team (part of us used to do full-stack before specialising in front-end), actively searching for experienced back-end developers and taking on more full-stack projects.