Re-thinking our approach to the ‘traditional’ website development method resulted in an improved end product and a better outcome for our clients.
Sitting on the Microsoft stack for most of my web development career, I can be forgiven for being of the opinion that the real work happens on the server-side. This has been the convention for a long time as, at an enterprise level at least, application tiers have traditionally been the domain of server-side business logic. Once a traditionalist and a firm believer in the back-end (BE) emphasised approach, I can’t help but be excited about the powerful front-end (FE) technologies in the current market and the promise of an amazing user experience which they bring to the table.
With the arrival of powerful FE technologies, we invested in exploring whether a shift in our internal development processes would allow us, and in turn our clients, to benefit from the advances in FE technologies. Traditional BE-first development with complementary FE ‘prettying up’ is no longer the standard approach; instead, a paradigm shift has taken place which has resulted in more of an equal balance between the FE and BE. In this article I will share the ways in which we, as an agency, shifted our development methods and adapted to accommodate this new world order.
Why Wasn’t the Traditional Method Working?
Traditionally, the approach to web development involved the BE team building based on a technical specification and wireframes. In parallel, the FE team turn PSD files into a collection of assets comprising images, CSS, JS and HTML. At some stage, BE developers integrate the FE assets into their BE application. Historically, this was a pain point.
Once BE developers have minced, sledge-hammered and forced the presentation layer in, it comes back to the FE team — generally broken. Now a dance between FE and BE ensues, involving finger pointing, a chorus of “it’s a back-end issue” and “it’s a front-end issue”, FE updates breaking BE code, BE updates breaking the presentation layer, and so it goes.
Most importantly, it equates to a big chunk of time spent resolving these issues. Not all development agencies may experience this pain point, but in my experience working in several agencies this has been the general approach. There had to be a better way.
What the New Method Achieves
The main driver for our new agency development process was separation of concerns. In the same way the introduction of the MVC architecture revolutionised application development by allowing developers to isolate the business layer and presentation layer; this new approach takes this separation further and gives full control of the presentation layer to FE developers — independent of anything BE related and vice versa.
By allowing both the FE and the BE teams to focus solely on their respective development tiers, each team is responsible for their respective, specialised areas. Moreover, as this introduces a clean separation of concerns between the presentation and business layers, both teams can work independently and are not bound by traditional limitations.
FE developers are not limited to the technology they can utilise and BE developers do not have to concern themselves with maintaining complex Razor views. BE developers are left to focus on providing the best and most robust server-side architecture, whilst FE developers are empowered with the freedom to utilise the FE how they see fit (ala technologies such as Vue, React and JavaScript).
How Did We Achieve This?
Digram 1: Three-part decoupled solution comprising Kentico Xperience CMS, Web API integration layer and a JS framework-based single page application.
PART 1: The CMS
At Revium, we work with all the usual suspects when it comes to enterprise level CMS platforms. When it came to trialling this new approach, we worked with Kentico Xperience CMS. We chose this platform to develop the entire website structure including development of content types, information architecture, online forms, content personalisation and all other facets of a site built on an enterprise-level CMS.
To the CMS user (Administrator to Content Editor), there is absolutely no difference in experience from a traditional CMS setup. Even though we no longer deal with presentation layer from the CMS, through cunning and guile the CMS still provides the page preview functionality editors are accustomed to.
For developers this is where the similarities end, with the main difference being the removal of page layout templates. No widgets, no web-parts, no master page. This is all handled by the FE side of the equation and the BE development team do not have to share this responsibility in the way they had historically. Under the hood, the CMS is being used as if it was a headless approach. So how do we link the BE to the FE?
PART 2: The Content Delivery Architecture
With the Kentico Xperience CMS we have the ability to maintain a decoupled MVC web application. Traditionally, in accordance with Kentico development standards, this would be a public website, complete with business logic to bind CMS-driven content with the presentation layer via MVC Razor views.
However, in our architecture, the presentation layer is replaced with Web API end-points tasked with facilitating the retrieval of all CMS data, based on how each CMS-driven page is maintained within the CMS. For example, the home page might comprise of a banner, three latest articles, a contact form, a poll and might incorporate personalised content based on user personas.
By querying the Web API end-point tasked with serving the home page, the complete page with all elements included is returned via JSON. In essence, the BE is used to provide a solid foundation, which allows for management of content and facilitates retrieval of said content in a contextual way.
PART 3: The Public Facing Website
The public-facing website is based on the Vue JavaScript framework, incorporating Webpack build tools and Foundation for the grid system. A collection of reusable page components is maintained by the FE team, including (but not limited to) banners, content tiles, CTA panels and navigation element variants. These correlate directly to their content counterparts within the CMS. You add a CTA on a CMS-based page, the corresponding CTA is served on the public website via the FE architecture.
What are the Advantages for us, as an Agency?
The architecture will allow us to streamline our development process by maintaining a library of foundational, reusable content components, both within the CMS as content building blocks and as part of the presentation layer by way of our component library. This means for our client projects, where budgets are always finite, we can now offer more robust and beautiful websites, incorporating the latest technologies.
The architecture provides unparalleled performance and scalability which has led to improved Google SEO scores. The approach has also led to better code quality and maintainability and ultimately, due to the component and template-based development, a more streamlined development process.
Our developers can focus on their respective technology stacks. BE teams are empowered to build great server-side applications, in accordance with latest trends and best-practices. FE teams are given the freedom to create magnificent user interfaces the way they envision. As such, FE teams are no longer restricted by limitations of the BE, and vice versa. In effect, it has removed the finger pointing and blame shifting and instead promoted a more collaborative relationship between the FE and BE teams.
Where to From Here?
FE technology is getting more powerful and is being more widely adopted. The writing is on the wall; there is an increased demand from clients, it is reflected in the job ads, and you can see it in the ramping up of skilled talent in digital agencies. The dawn of the headless CMS is pushing us in this direction.
Whether you’re of the mind that this is a trend or a natural progression, there is no denying that the current landscape is reflective of the industry heading in this direction. Sitecore’s JSS SDK is a nod to this notion, and we are likely to see more CMS vendors address this architecture in the near future.
I am of the mind that this is a natural progression, and an evolution of web development. FE technologies are becoming more powerful, matching the BE counterparts (not simply complementing and prettying), and FE systems are now applications in their own right as much as BE applications are.
