Full-stack Front-end

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.

But a lot has changed in 10 years. Browsers are harmonising (hello Chromium, farewell IE), what used to be custom back-end work is now available as hosted services and many things, such as CMS’es, are now totally headless. JavaScript made it into server and serverless runtimes with Node.js. And other web API's are making their way into server-side runtimes (go WinterWG!).

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 (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.

Microservices (the M in MACH) as the name suggests are small dedicated services. We use these to add product-specific functionality that’s not readily available through an existing cloud service. Our go-to programming languages are JavaScript and TypeScript. But since these are small standalone services we can also select another language if that’s more suitable for the job. We can use Rust to create WebAssembly modules, use Python for a data / machine learning service or Go Lang for a specific high performance service, and so on.

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.