Building the Ibexa website: The architecture

This post is the first in a series describing some implementation details of the current Ibexa.co website. We'll go through some of the nitty gritty details in later articles, but in this one we'll go through the high level architecture that runs our public websites.

Architecture in IT refers to a high level overview of components and the structure in a given system. Architecture is a fancy word, but in reality every web app and website has one. For simple needs (like ours right now) it is often defined by the used product itself, but for complex systems and large scale online giants such as Google and Facebook the architecture is immensely complex and continuously evolving.

There are hundreds or thousands of individual components and countless of interactions between those. In addition to the complexity of the business logic, reliability and performance also need to be addressed. This is why the architecture is very important for the long term success of any organization relying on IT systems, but it is also easy to go over the top and make things unnecessary complex. This is an easy pitfall because of the fast pace of change in the industry.

First things first: We're running Ibexa DXP, our flagship Digital Experience Platform. This selection was a no-brainer from a technical standpoint, but also serves another purpose: it provides a feedback loop directly to our design and development teams, as we are able to give feedback on early release stages based on real business needs.

We are running the Ibexa Experience product with Ibexa DXP features such as the page builder in daily active use. In addition to core features from our own product, we use a number of external systems that are integrated lightly. For example, all of our forms are currently built and managed via our Marketing Automation tool that we've had in place for a number of years. There are also other integrations such as Zoom and MA syncs, and some other data wrangling but these are handled by our IT team.

Keeping things standard makes life predictable

So when it comes down to it, our core system is very simple and easy for new developers to get up and running fast. We've deliberately taken a minimal approach to third-party extensions, and rely as much as possible on the core features of our product. This keeps our developer and editor experiences simple and predictable. We are not running a microservices architecture per se, but we do rely on specialized external services to handle domain tasks.

In the future we will introduce some additional integrations like SSO (single sign-on) as well as deploying Ibexa Personalization to help our visitors discover relevant content and services. In general this (somewhate boring for tech heads) de-facto architecture has served as well and we will continue to evolve. The system has proven to be stable and we've been able to onboard new developers to the project quickly.

Similar to the selection of using Ibexa DXP, it has was obvious that the site should be hosted on Ibexa Cloud. This is a Platform as a Service (PaaS) that is specialized to run our software. When using a PaaS all the services like the database, application server and search engine are fully managed. We retain complete control of the source code, but can rely on the Infrastructure as Code (IaC) to handle scaffolding server components. 

In addition to pure hosting, Ibexa Cloud also helps our development workflow by providing preview instances for new features we are developing. All without heavy investment in DevOps personnel or custom hosting infrastructure.

It's 2021. You must be headless, right?

For the front end we're using the rendering stack from Symfony (Twig templating, etc.) mixed with the standard Ibexa DXP helpers and configurations. For design we're using the Bootstrap library built with SASS, more or less out-of-the-box stuff from Symfony Encore docs. You may wonder why we didn't go with a trendy solution like Gatsby or Next.js that would be a good showcase for a headless implementation.

The reason boils down to resources. While it would be cool to try out the latest trends in production, it wouldn't serve its purpose as well as it does now. The ownership of this site in our organization is marketing, and we don't have the same technical muscle as the engineering team does. What we need to do is maintain and develop our communication and online presence as efficiently as possible.

To achieve this we want to use as many default capabilities as we can. In our case we need to maintain a number of dynamic landing pages with language versions, run multiple sites and enable authentication to the partner portal, and much more. All of this could be done using Ibexa DXP's GraphQL API with a JAMStack approach with maybe a bit of serverless magic. But it would take more people to do implement it initially and still some simple tasks like making new landing pages might end up being a developer task.

Ideally developers should not be the bottleneck for day-to-day operations. And with the current setup with the combination of Ibexa DXP and some specialized tools the marketing team can handle most of their daily routines autonomously. Technical development is done, but mostly as flexible and reusable features.

Conclusion

While architecture is often talked about in a heavily technical tone, it is ultimately about creating something that best serves its purpose. In our case we are using a lot of off-the-shelf parts to bolt together something that works great for us. For technical enthusiasts there could be more interesting and exotic ways of achieving this, but for the purpose this has worked well for us. 

This low-maintenance and developer efficient platform allows us to spend our resources on adding useful features. Technologywise we've got quite a clean slate as well. While our core is server side rendered, we're adding more client side rendered functionalities such as a product selection wizard and more. Without a framework like Next.js in place, we've actually got more freedom to choose to integrate tools like Symfony UX, Web Components and whatever the latest thing is tomorrow.

I think a similar approach would work for a large number of smaller organizations that You want to be able to provide first rate services, but don't have the need or the resources to replicate what Silicon Valley giants are doing. If you think you could be one, please don't hesitate to contact us to learn more about us and our products.

Photo by Daniel McCullough on Unsplash