Our Best Practice for your New Front-End
- Sylvain Paillard
Abstract
Monolithic systems are still the norm for many SMB to control the view of the web-site (for e-commerce: Magento, Shopware, … and for Content Web-Site: WordPress, Typo3, and many others).
However, the growth of Headless CMS is likely to signal the end of this era, and without any doubt, this is good news.
In addition to being more performant (better page speed, lower machine resources usage, …) this change in the front-end architecture enables many new possibilities, just to name a few:
Omnichannel content management
Instead of adapting your content for each channel for each marketing activity (e.g.: a campaign landing page, a campaign banner, a campaign newsletter, …), you can define the Headless content once in your CMS and “roll-it-out” to all your end-user touchpoints (different dynamic pages on the web-site, e-mail, push notification, app, etc.).Micro-service oriented architecture
Unlike in monolithic CMS, you can develop your view to only require specific service APIs depending on the situation and avoid many side-effects and inherits latencies that were very hard to circumvent before. In addition, this approach (especially if combined with Boxalino Narrative API as the primary source of Headless content) will reduce drastically the amount of business logic in your front-end and will make your front-end environment agile, slick, high-performance, and easy to maintain.Unified Front-end View
Many technologies developed over the last few years high-jacking directly your front-end with JavaScript injections and modifications. While this approach had the advantage to be effective (especially as any changes implying modification on the server-side of the old CMS implied (often troublesome amount of) effort), it also had many disadvantages: lack of control over what happens on the browser, harder to diagnose and correct bugs caused by this “hybrid” approach with two independent systems telling the client browser what to display, flickering effects on page load which affects the user experience, etc.). With a much more agile and efficient front-end, smart integrations of services such as Boxalino Narrative API providing such types of personalization / ab-test can be elegantly and efficiently integrated as a core aspect of the front-end architecture.
Key challenges
In order to create a front-end architecture that takes advantage of these new possibilities, several challenges have to be addressed:
Hard-Coded integration of content break your agility
Accessing a Headless CMS API directly from your front-end environment will not enable you to bring personalization and ab testing possibilities in your front-end. On the contrary, it will make your front-end integration rigid as it will depend on a specific CMS API integrated with specific controllers with hard-coded business logic.
Your Headless CMS stores content, your Front-end renders these content pieces in your templates, Boxalino provides you the missing piece: a dynamic layer to configure the layout of the page and the mapping of which content goes to which template in each situation, so a change of layout and content structure doesn’t necessarily mean a change in your front-end set-up.
Lack of dynamic control for your marketer
Not using a system like Boxalino Narrative API will force you to manage all your template usages and applications in your front-end code. This is very likely to end up with a set-up that doesn’t give all the desired freedom to marketers to create dynamic landing pages, personalized page sections, etc. As a result, marketers are likely to have similar limitations as before to only be able to create “dumb” static landing pages and fixed configuration of key marketing pages like the home or brand pages.
Marketers need to realize more and more often dynamic changes in your website very fast. Only offering the option to manually change the content of landing pages or limited zones of other pages with static content is not enough. With Boxalino, marketers can integrate dynamic and personalized content changes (including a/b testing by themselves without relying on IT resources to do the job.
Unstructured extensions of the CSS theme
Your CSS theme can be done in a very cleaned and structured way at the beginning but will tend to become messier over time to make room for unplanned, specific changes based on visualization changes done by designers and marketers. Starting from well-structured CSS classes, front-end often end-up with large quantities of in-line styling in different places, some of them directly typed by non-experts, making the web-site sometimes appear suboptimally (for example, when it comes to responsive design).
Marketers need to optimize and adjust the way templates appear visually without requiring changes in the front-end technical setup. By empowering them to use a CSS framework directly in Boxalino Narrative, you can enable them to change many visual aspects without introducing unwanted in-style elements which might break the visual rendering.
The keys to success for your new front-end with Boxalino
Headless CMS: Real-time GraphQL within Boxalino Cloud
Integrating Boxalino Narrative API can be done with any type of content from any source. But integrating content you export to Boxalino API has the disadvantage to not offer a live preview to the marketers and content creators using the Headless CMS.
In order to avoid such a problem, make sure to chose a Headless CMS with an API supporting GraphQL. Boxalino will cache the response (typically for 1 hour) but will support live preview to enable efficient work on stage. Indeed, any millisecond is important for your page speed and Boxalino can ensure that your Headless CMS is typically not accessed in real-time, saving precious network time which will count for your Google Page speed ranking!
Boxalino supports real-time GraphQL queries you can directly configure in Boxalino Admin. This way, no need for an additional data transformation layer to prepare your data in the format needed for your real-time requests, you can directly configure the mapping in the GraphQL query.
Template Engine: A flexible Template Engine with client & server mode
Your front-end templates should be able to get rendered both in your server or in your browser in JavaScript (or TypeScript) without pain. So the last banner template you did for the home page can be easily re-used for an overlay appearing before the visitor exits the page.
Also, a template engine with a minimum capacity for processing logic (e.g.: formatting strings, conditional parameters, etc.) like Nunjucks will facilitate your templates to have the required rendering logic built-in, avoiding the need to have any business logic in your code between the call of Boxalino Narrative API and the rendering in your view.
In addition, Boxalino Template Engines can access directly to your Template Library and manage the displays of overlays throughout the page visit (scroll-behavior, minimum time on page, pause to look at something, etc.) and automate the triggering of calls to Boxalino Narrative API without that you have to program anything while making direct usage of all the templates you have created for your front-end.
CSS Framework: enable marketers to test anything visual in a clean way
Boxalino recommends using Boxalino’s JSON Styles pattern for the styling of your templates. By defining in your templates a CSS classes parameter for each DIV of your template and relying on an advanced CSS framework such as Tailwind.css, you can empower Marketers to make all the modifications they want, on any of the key elements of your template without opening a pandora’s box (like giving them direct access to in-styling on the DIV elements themselves). This might require a bit of training, but it will pay off in a multitude over time and will enable you to keep a very clean and highly controlled grip on your front-end in any browser and devise.
Solution architecture
