On-Demand Webinar: FirstSpirit Hybrid CMS

diva-e lecture

Headlong to success - With Hybrid FirstSpirit and NuxtJS to the optimal customer solution

Based on a concrete customer project, we will show how to use the advantages of Hybrid FristSpirit in practice to realize a modern and conveniently maintainable website. We explain our system architecture and explain the basic building blocks of our approach. Last but not least, you can of course see the resulting solution.

Transcript of the webinar: FirstSpirit Hybrid CMS

Presentation

Angela Meyer: Welcome to today's diva-e webinar with our partner e-Spirit. Today our experts will show you how to make the best decision for a content management system or a digital experience cloud in these times. The webinar is divided into two parts. First, Tim Rother from e-Spirit starts with his presentation on e-Spirit's FirstSpirit Hybrid CMS, "Being prepared for what the future brings". And after that, we'll answer your first interim questions. And this will be followed by Niklas Krauth from diva-e with his presentation "Headlong to success with hybrid FirstSpirit" and Nuxt GS on the optimal customer solution. I'm glad you're with us today. (5 sec.) We'll start with a little technology check. To your right is a control panel with a question box. And it would be great if you would now give a short sign, write a hello in it, so that we can also check whether the technology is working. That looks very good. Lots of hellos, Hey, you're looking forward to the webinar. It works, the technology is running, then I would say, we can now also start with the content or with a short round of introductions on our part or by me first. My name is Angela Meyer and I have been a member of the diva-e marketing team for about four years, I am in charge of the webinars and I am your moderator today. Right, now I would like to pass the floor to Tim, who can also briefly introduce himself.

Tim Rother: Yes, welcome from my side as well. I'm Tim, product manager in the global product strategy department at e-Spirit. I don't have a real IT background, but I recently got an MBA in digital business. And before that I worked for a relatively long time in product management, project management and sales in the manufacturing sector. I'm already a little bit involved with e-Spirit and I'm really looking forward to the webinar today with our power diva-e.

Angela Meyer: Very nice, thank you Tim. Yes Niklas, a few words about you.

Niklas Krauth: Yes, hello first of all from my side. My name is Niklas Krauth, I'm a software architect at diva-e with a focus on web applications, including this CMS topic Fail Finding, frontend topics and before that I've been working in software development and software architecture B2B and B2C for quite some time. Unfortunately you can't see me today because I'm only here via cell phone due to the lack of a go to meeting Linux client, sorry for that.

Angela Meyer: We can manage that as well. Yes, then I would say, yes, then I would say, Tim you start now with your first part on the topic of FirstSpirit.

The FirstSpirit Hybrid CMS

Tim Rother: Okay, then I hope for now that you all see my screen? And I'd also like to repeat the thank you for the invitation here to the webinar, that we can participate in the webinar here today as e-Spirit. And of course, I also welcome all of you who are interested, who are probably in your home office or wherever you are, who have dialed in this afternoon. And I'll be spending my, yes, about 20 minutes on giving you an understanding of FirstSpirit Hybrid CMS, with the aim that at the end you know everything, know why FirstSpirit Hybrid CMS is the content management system of choice and can accompany you into the next few years with a secure future. So that's also the title Being prepared for what the future brings. And I would like to use the 20 minutes in detail, if you can talk about real details in 20 minutes, with a very short introduction from e-Spirit about the company. But the main focus then of course very quickly on that, on Hybrid CMS. What is it and why do I need it? Likewise then a bit of the topic of high level architecture, FirstSpirit Hybrid CMS to bring you closer for the details. There won't be enough time today, but we'll be happy to do that a bit later on. And since this is also a developer-focused webinar, what's in it for me? So what's in it for me as a developer and why is the hybrid CMS also good for me as a developer? To me we have already said enough in the presentation. The only maybe below again my e-mail address, for those who do not want to ask the questions in the plenary. Or, if again with a night over it sleep you still ideas come, simply gladly afterwards then also again announce. Yes, let's come very briefly to the presentation of e-Spirit as a company.

About e-Spirit

We are one of the leading content management system manufacturers and have been on the market for just over 20 years now, so we celebrated our 20th birthday last year, have our main location in Dortmund and a second large location in Boston, in the USA. And also since last year in Apec, that is in Singapore and in Oakland, yes, in each case agencies that serve the local market there on site. We have a wide range of customers. So we've done over 10,000 different projects for over 1,000 different customers over the last 20 years and I've brought you a small selection of customers here. Whereby it is not so important which names are necessarily there. You will probably recognize one or the other. The message I would like to send here is that it doesn't really matter which industry or branch of industry you are in. We as e-Spirit, we know our way around everywhere, yes. Whether it's in the public sector or manufacturing, banking or even e-commerce, where we serve our customers very successfully together with our premium partners Salesforce, SAP and also Spica, to name three. Yes, I brought the slide, not to scare you guys. It's rather something for the follow-up, for the handout. But from my point of view, it's a very successful attempt to put the highlight features of our FirstSpirit software on one slide. And I don't really want to go into detail here. The only tip I would like to give you is, from the inside out, then the whole thing will also make sense and then you can deal with it again afterwards. Because to really go into it in detail would definitely go beyond the 20 minutes here today. Because I would rather like to tell you a little bit about the topic of hybrid or hybrid CMS and why do we need it at all?

The hybrid CMS and why we need it

Because there are headless systems, there are the traditional, monolithic systems and what is hybrid CMS and why do we need it at all? To get to the bottom of that question, I want to start with the term Vuca. Vuca has been around for about a year and a half in the business world and has not yet really caught on in many areas. Or now, due to the situation that has arisen, where we are all sitting at home and no one really knows what the future holds in two weeks' time, it has taken on a whole new meaning. Vuca, what does that mean? The terms are down below, but again for a very brief explanation. So the both activity, it's going up faster and faster and it's going down faster and faster. There are trends that come and go at an unprecedented rate, which in turn leads to some uncertainty. Am I doing the right thing? What's next? Am I making the right decisions about that, too? There is a lot of talk about destructive technologies. What does that mean for me as a company? Yes, and certainly for every individual in private life the topic of insecurity. When can I visit relatives again? Yes, this uncertainty is now omnipresent. But uncertainty is also closely linked to complexity. The world is becoming more and more complex, has become more and more complex over the years, and there are no longer any simple decisions. The fact that everything is so interwoven and interconnected means that even small decisions, or even small decisions, can have major consequences that I can't even grasp today.

And that's despite the fact that more and more decisions are also being made data-driven. That's where ambiguity comes in, this ambiguity as well. And the scope for interpretation that data also provides me with has also increased to an unimagined extent, so that this in turn leads to additional uncertainty. And that actually almost calls for people to crave certainty, to crave something predictable. That's one side of the coin. On the other side, and everyone should perhaps put themselves in their own position as a customer, we always want more, more, more, more. So, we want to be reachable via more and more channels. I would like to ask my Alexa. What's the weather going to be like tomorrow? And don't want to get up and look for my tablet. So, I'm reachable through more and more channels, mobile way, voice. I want to get relevant content. So I want to get personalized information that is tailored to me, and I don't want to be bombarded with something. And that simply creates certain tensions, on the one hand the desire, these uncertainties, the desire for security, and on the other hand this more, more, more. Which, to date, neither a Q-Headless CMS nor a traditional monolithic CMS can really manage.

Because all these challenges, especially the more, more, more, of course also requires a new flexibility from companies and also automation in processes, in order to get to grips with all the additional content that has to be made available. That is, let me say, the high-level view. If I now go a little deeper and look at it at the enterprise level, there are also these two worlds. I have drawn a spectrum here and each of you is certainly familiar with these tensions that arise.

On the one hand, there are people who are not disrespectful, perhaps a little bit of the eternal yesterday, yes. Who like to stick to the things they know, who are, who are not so open-minded to new things, who are content with what they have right now and what they are doing. And then on the other side, there are the people who chase after every new technology, who back the latest horse, and who really have fun doing that, even in, yeah, just trying out different things. And I wouldn't be surprised if maybe that's the way it is in some companies. That is, there are not only the people who move more to the right or more to the left. But perhaps also that the marketing department is super innovative, but the editors are a bit, yes, rather reserved when it comes to new technologies. And then again in the developer area, which is now also typical with the headless CMS, where the latest technologies are to be used, where people enjoy working with modern things. And here, too, a natural field of tension arises, which creates friction. Because perhaps people don't understand each other and don't really know what the other person wants from me. And we at e-Spirit offer a solution to this with FirstSpirit, our hybrid CMS, in that we have created a modern, future-proof CMS that covers all areas. Yes, on the one hand the security needs of people who like to have a constant, who like to work with the familiar and have familiar environments to deal with. But also, at the same time, future-oriented, using the latest technologies, microservice-based, microservice-based working and the expandability and scalability for future customer requirements. We have learned that customers always want more, more and more is added. And here, too, the expandability and the high integration capability of FirstSpirit, for other systems or in other systems, have created a modern and future-proof CMS. But there is a third level. So we had the high level, then the enterprise level and, if we now go into headless and traditional systems a bit more. Why are they actually so opposed to each other? I have picked out a few advantages of headless systems.

Advantages of headless systems

With headless you are much more agile. You are multi-channel capable, which means that I can put something on my website, but I can also use this content to play the whole thing out in a mobile app or via Alexa or even an oven, so it's also IOT-friendly. Those are the business use cases. But for Micha, as a developer, that means I have frameworks that I can use. I can use the latest technologies and I don't need specific CMS know-how. So I can really take care of the frontend and don't have to look at what work is going on in the backend. On the other hand, the more, yes, I call them more traditional content management systems, have a certain simplicity of use, are always previous based, preview based work, which is of course super important for an editor. So that he knows, what does the content look like that is being played out? And these so-called enterprise capabilities. At this point, multi-language or multi-side are mentioned, which is the challenge for large companies. How do I manage my content, which is distributed all over the world? Or forms management or rights management, i.e., which user is allowed to do what in my system? Multi-level workflows for content that is critical, for example. These are things that are not as pronounced in headless or are even missing. And I'll come back to the topic of deep integration and security later.

But you can see, I have two things here that kind of oppose each other, and they bite each other a little bit. And that's because headless content management systems are built primarily for developers, whereas traditional systems have always had a focus on the user. And that's the natural tension I mentioned at the beginning, which we resolve with FirstSpirit. Because with us, the system combines on the one hand the power, but at the same time simplicity of enterprise class content management system and on the other hand it also offers state of the art, architecture or headless architecture microservice based. That means, I don't have to decide if I would be with Matrix now. Do I take the red pill or the blue pill? I may take both and that is the main advantage and the reason why Hybrid CMS is the most future-proof CMS, with which you are definitely still well positioned in the next years. (4 sec.) So and that was the introductory part, kept a little bit more global, with a little bit of background on Hybrid.

Definition: Hybrid

There were already some explanations about what hybrid means. Nevertheless, I would like to explain again with the help of two examples, how and why the whole thing is called hybrid. First of all on the basis of integration players, through the man-. This is now classic architecture. So there is a content management system backend and there is also a content-as-a-service that consumes data from the backend and provides an AP, which is then used by the various touchpoints or output channels to pull the required data, the required content, and then publish it. That is the standard for every headless content management system. What is a bit different with e-Spirit and comes on top is what I described earlier as deep integration. This means that we create native objects for selected channels. For example, we can edit a product catalog of a store in the backend or we can work preview-based in a system and edit content there directly in the frontend, yes, even though the whole page, yes, that's always the case with the store, of course, that the store is the leading system, so it's not CMS-led. And with, yes, FirstSpirit, I still have the possibility to maintain, edit, and change content based on previews. This is a huge, huge advantage, especially for users, which is not offered by classic, pure headless CMSs. And of course, especially in the frontend, we are a bit agnostic. So I don't have to throw everything away if the frontend technology changes. There is a second reason why the whole thing is also called hybrid CMS and that is the topics of static and dynamic.

I used to have the classic static way how websites were built and how it comes back a bit now. So you have a data storage somewhere and you have statically pre-generated and statically generated websites. Because that's still the case today, there's nothing faster than a website that delivers statically generated or statically generated HTML. Yes, I can still add a little bit of dynamics to that if I want to. Then there's the application server interface in between.

In addition to the speed of the static system, I also have security, because I don't have to access the backend here. Disadvantage is, it is for websites. So it's quite difficult for me to tell my Alexa: Please read the HTML here and return this as language. That's why there's the second way, which I outlined earlier, that, then the headless way is with FirstSpirit, the Content-as-a-Service for dynamic generation, which then also has this issue of multi touchpoint capability. By the way, the way HTML statically generated out is experiencing a bit of a renaissance right now. If you look at the Jamstack topic again, this is the attempt by headless providers, even pure headless providers, to statify the dynamically generated content again. That comes with the hybrid CMS from e-Spirit, out of the box, I have both options. And this is an example of how a website can look. That is, I have the pre-generated content that is statically generated out and a dynamic or even personalized content.

Here is an example of news. But that can just as easily be a weather forecast, personalized advertising, whatever I want to query through the rest interface in CaaS. So I also have the possibility to benefit from the hybrid CMS on websites. (6 sec.) Yeah, that was kind of the high level architecture. As I said, you're welcome to contact me again afterwards for more details. Or we at e-Spirit also offer training courses, architecture training courses, where the whole thing is really explained again in epic breadth and brought closer to everyone. Finally, however, I would like to go back to the question of what are the things that really help me as a developer? So I talked earlier about enterprise class capabilities, that they make the difference. And if you remember, those were on the right side, that is, the one in the business user area. But good news, it's also for developers that these Enterprise Class Capabilities make the difference. So because with our hybrid CMS, it's like I can choose the architecture. So I have a freedom of choice which architecture I take. And with that, I can then also meet the challenges that are coming at me, that are coming from marketing, that are coming from other people, depending on how it's needed at the time.

I can choose whether I take the cloud or a premise. Very important point, the integrated CICD and I always get three instances of DQP, yes, so development, quality and productive. We work with the technology and the Kubernetes cluster. And what has also been mentioned before, it is super easy to make extensions with FirstSpirit and to integrate other systems and we attach importance to correspondingly good documentation. Should be standard these days, but again, a separate note on that. And if I were to put that together, mix it up and hold up a sign, it would come out that it's also a new kind of agility and productivity for developers that we're delivering with it. That's the second slide that I don't want to go into. That's something to read afterwards for home as well. That's kind of the, again, summarizing the highlights. I think the next slide is important again to conclude, because this is a little spoiler, also our FirstSpirit Experience Accelerator. I mentioned earlier, there is the approach, I have a headless, CMS and a frontend and some work in CMS and the others do something in the frontend. And then we thought, that has to be better somehow? And the result was FSXA, the abbreviation for FirstSpirit Experience Accelerator, because it is so difficult to pronounce in the long run. This is a, yes, cloud offering, where we deliver reference projects, very importantly not demo, but fully maintained, transitioned products for a classic website and a PWA implementation including CICD and everything you can imagine can be used productively. For you as a developer, that means I don't have to start from scratch, I can, I have references that I can build on, that I can reuse and I can sort of start with phase two and do the things that are really, that I enjoy, that are cool, that are hip. Not to say I can start doing the awesome shit and the other stuff has already been taken care of by e-Spirit namely. But there will be more about that in a webinar, which my colleague Daniel will prepare for you. It will take place on April 23rd, where he will discuss how I can really realize projects with FSXA. Afterwards, Niklas will tell you how he did the whole thing on foot and still managed to be successful. So at this point many thanks from my side and I look forward to your questions. Either live here now or afterwards.

Angela Meyer: Yes, thank you Tim for your input on e-Spirit Hybrid CMS. I would continue here now directly with the Niklas. I hope you are ready to give your presentation here now. I'm going to transfer over.

Niklas Krauth: Yes, if you transfer my screen, then I have had it.

Angela Meyer: Quickly the screen still, exactly.

Implementation of a diva-e customer project with the FirstSpirit Hybrid CMS

Niklas Krauth: Yes exactly, once more full screen and then we are ready. Exactly, yes, first of all thank you very much, thank you Tim for the introduction to the general topic of Hybrid FS. We've already heard a lot about the benefits. I would now like to tell you, Tim has already indicated, a little bit about what it means when you actually implement everything in a concrete customer project. And since, I think, we are just now also already with the time, I go directly in medias res and we start times. Exactly, before I tell you a little bit about what exactly we did and how we did it, I would like to explain to you why we decided on hybrid FirstSpirit and why also concrete hybrid FirstSpirit in combination with Nuxt. But at the beginning of all our projects is always the customer, because I think this line from the well-known song by Freddy Mercury reflects a very healthy customer attitude, yes. The customer simply wants something, he has a high demand, and our task and also our claim is of course to make these things possible, to fulfill these demands of the customer, these expectations. What does that mean in concrete terms in our case, for our project? Well, on the one hand, there are of course the requirements, as Tim has already said, that are always placed on CMS, especially by large customers, classic CMS qualities. Exactly, the whole thing should be secure, it should also be somehow tested and reliable. On the other hand, of course, it should also offer a high level of comfort.

The CMA, what you see is what you get, for editing by the editors is simply an important requirement here, so that we don't have to click through a desert of forms. The whole thing, however, which was also the concrete requirement here, should really be combined with a state of the art frontend. It should be away from the classic, what we know, that individual pages are loaded statically. Instead, the whole thing should be as if it were cast from a single mold. An application, an interactive application, which animates fluidly, I say, creates transitions between pages and simply conveys a modern visibility. In the meantime, it is always a requirement for all web projects that it is implemented in mobile first, i.e. that it supports a broad class of devices, from cell phones to tablets to 34-inch monitors. And finally, always welcome is of course a broad browser support. In our case, thankfully, only down to IE 11, which makes the thing still so halfway manageable, but still of course always a challenge. And the topic of SEO optimization is very interesting. The diva-e has here also strong expertise in terms of content point. In the SEO optimization of interactive pages, which you are nowadays with, basically written as a JavaScript application, is of course always that JavaScript and search engine indexing always have a bit of a conflict potential. Nicer is then of course, as you also have with the classic FirstSpirit, if you have static pre-rendered pages simply in use. Exactly, and finally, one requirement is always, of course, that the whole thing should be cost-efficient and also have a certain future viability. In our case concretely the requirement that different smallest, with the same content should also be supplied later in the follow-up. Not only the website, but there is also an intranet and there is also a management app, for example, which should partially integrate this content. Cost effective, the old website had an integrated careers page, these should be taken out and two separate pages should be created. Here, of course, with the goal of achieving maximum synergies as well. And finally, we simply needed a high scaling in the development mode, because originally there was a relatively tight deadline, which was then postponed again for other reasons. Why hybrid FirstSpirit from this point of view? Well, we already have the classic CMS qualities right out of the box, so we're on the safe side. But why hybrid?

The central point here is the decoupling of content and presentation. This allows us to use modern, established web frameworks on the front end for the presentation and to get all the state of the art features. We can get high synergies between the two websites through the image system. We get content reuse out of the box through the hybrid CMS and finally, very importantly, scalability. We need much stronger frontend skills now. We can develop the frontend detached from the FirstSpirit part in an RP First approach and thus get a completely different scalability into our project. Why the Nuxt combination? There are, I have a whole bunch of Angular React Vue at established frontend frameworks. Nuxt itself is essentially based on Vue, which I think is currently the best MBWM framework in frontend development. You can develop Vue components optimally detached and in parallel. Why not Vue directly? Nuxt offers a whole range of very useful conventions here, useful above all for the implementation of such classic websites, in my view. For an app, I would probably rather rely on Vue? On the other hand, and this is very crucial, Nuxt offers us server-side rending and pre-rendering, which allows us to provide our dynamic single-page application SEO optimized as static content also for search engines, without much extra effort, so really a huge added value. Before I show you how we implemented all this in detail, I'd like to give you my impression of what we ended up with. I have made the whole thing a bit anonymous here, because the customer can't be named either. Here we see, here are so a bit diva-e branding, our, the created website. We see, we have here below quite classically a footer, in between we have here the content area, consisting of various components and here above the header with a quite elaborately made stage, which represents the top navigation level. If I click on it here, we can also see, we have animated page transitions.

The whole thing is highly responsive right in the browser. I can change the language right here at the top. There's no page reload, so the whole thing is highly interactive. If I also just pop in the mobile view here, again, we see the whole thing is mobile first design. We see up here, the bar folds dynamically, goes away dynamically or comes back dynamically depending on how we scroll. We have classic a classic burger menu here where we can also dynamically change the language again. And so we have actually really implemented the requirement that we have for the frontend for now. What does the whole thing look like for the editor in FirstSpirit now? There I would like to draw you, for the sake of simplicity, I have shown it a bit before. I'll show you this in the video. Here we log into our FirstSpirit in the classic way. What we see here, I'll pause for a second, is we have the application frame here, the classic FirstSpirit frame. Our application is embedded in this frame via iFrame, the application from within communicates with the content creator around it. And we can, our content can be edited here just like in classic FirstSpirit.

For example, let's change the image on the left side here and we see the application reloads directly and we have edited the whole thing live. Here we benefit from an advantage of Nuxt. You can not only run the application in server-side rendering mode or pre-rendered, but also as a dynamic single page application. And this is exactly the mode we use here for editing in the Content Creator. So, how did we do the whole thing? I have already said that the advantage of the hybrid is also the decoupling of CMS and frontend. And accordingly, we developed the whole thing API-first and we start here with the API design. As a quick reminder, we maintain the content in FirstSpirit. First Sprit then plays that content out as JSON to the CaaS and from there we fetch it with our application, yes, through the Rest Interface and integrate it into our application. Here on the left side, we basically see the process when the page is first visited. Our application, the user visits the page, the application first of all fetches a JSON fragment from the CaaS, which is what they route. That is, the URLs that our application supports, describes, it fetches from the CaaS. Then we fetch what's called global content. That's about the part of the website like navigation, header, footer, which are sort of identical for every page.

And finally, afterwards we pick up the actual content of the page of the JSON, which describes the actual content of this concrete page. Then on the right-hand side, we see what it looks like when we navigate in our, on our web page to another subpage. The routes, the global content are always constant, so we only need to retrieve the page description. So what do these individual pieces look like specifically? The routes are simply an array, a list of individual route entries, always consisting of a breadcrumb, this breadcrumb contains the name of the page and all parent pages. The real ad manen, so you can be used on client side also for display. Added to this is the client URL, the URL where this page should really be available to the end user on our website. As we can already see here, that's basically generated from the breadcrumbs more or less, which allows for very nice, speaking URLs to us. And finally, the content URL, that's the URL where we can actually retrieve the content of that page from the CaaS when we need it. What does our global content look like? I've shown the navigation here now as an example. The navigation is basically a nested tree structure, consisting of the individual entries in the navigation menu. Each entry is described by a name, by the name as it is actually displayed in the menu and the client URL. The URL for the content we can always look up from our, yes, in small, kept route file, so we don't always have to supply that again. The last part is the individual pages. Those consist of metadata, like the title of the page, the type of page as it's maintained in FirstSpirit, so we can certainly do different displays there on the client side depending on what kind of page it is. Metadata like the robots, the information for the page, the translation of the page and finally a list of components, we'll get to that now. The components are the actual content of the page. They can be things like headings, text, images, more complicated things like teasers, expandables, tables.

So everything that such a page can consist of, which we make available in FirstSpirit to a component, for the editor. And each component is in turn described by a type that tells us: Okay, what kind of component is this? Which front-end component do we use to display this FirstSpirit component for the user? The Previous ID, which we need to edit this element later in the Content Creator, and the actual content of this component, which describes this component in terms of content. Here we have a very simple case. A heading, there we have a level, that's a third level heading, that's the content of the heading and here there's still optionally such a subheading that can be given to our heading component. How did we implement this API with FirstSpirit and CaaS? Basically the whole thing works like this, classically we define our HTML output channel in FirstSpirit to produce the actual HTML output. In our case, we define a so-called CaaS output channel that outputs this content as JSON. Example, quite classic for the page, we create an object in our FirstSpirit output channel, iterate over the content in FirstSpirit, collect it in this object and at the end call a to JSON to serialize this content, around this object and play it out to the CaaS. Now, due to the shortness of time, I just want to talk about a more interesting case here. Namely, how do we make the routes, this route file, the route JSON? Because that's a bit tricky. I can only hope for the Experience Accelerator on that one as well. How does the whole thing work? We make a mapping here, Content-URL to Route Object. A Route Object is an object that contains exactly these three properties, Content-URL, Client-URL and the Breadcrumb. We fill this object here by calling this template. We'll take a look at the template in a moment. And once we have this object, we actually don't do anything other than create a, our JSON mapping where we only have one property Routes. That just strips out the values of this mapping here are and call our to JSON. So all the magic is here in our call to Routes. How do we make this mapping content URL to routes objects? To do that, we use the FirstSpirit CMS Navigation function, which we call in time map mode.

What this function does is, it runs across the entire tree structure our content in FirstSpirit and for each Page, it calls this function at the end, which we can define ourselves here. What does this function do? This function creates us exactly this route object for each page. We store it here in this variable and create the route object by calling the FT-Route function, which already gets the current node, that is, the reference to the current page and the content URL. Now this is this function FT-Route. And what it does is it creates an object, it gets this object in from the outside and it attaches three things, a breadcrumb, a content URL- a client URL and the content URL. The key thing here is the breadcrumb. We've already seen, the client URL, that's exactly what's happening here, it's ultimately created from the breadcrumb parts through a certain normalization of these components. We already have the content URL in hand. We just entered that from the outside and we're actually just doing some end URL coding here. How do we make the breadcrumb? That is the array of the page and the name of the page and all of its parent pages, we do that again by calling here, the navigation function, just in a little bit different mode.

We don't have the sidepack mode here, we call the whole thing with Expansion Visibility Purepath, which makes sure that for the node that's currently in context, we just traverse the direct path from the route, from the CMS route to this page. And what we do then is simply, for each element in that path, we add the breadcrumb down here, just the display name, the language-specific display name of that page. (Click.) (6 sec.) So much for the FirstSpirit part in a nutshell.

Frontend: NuxtJS

Now let's move on to our frontend page, the Nuxt SPA. Here we see a bit, yes, an overview of the components that our SPA has. First of all, there's the routing middleware, which actually determines what should happen when a certain URL, a certain path is called on our page. What should happen? What should be changed? Normally, it hands off here to the shared layout and the generic page, which are responsible for the actual rendering. Add to that our store, which would have the current state of our application. And a CaaS client plugin to dynamically retrieve the content from the CaaS. This is a somewhat simplified representation, but for now it shows all the main components of our application. When the application is initialized, here's what happens. We retrieve the routes and global content from the CaaS client plugin and store it in our store. The routing fetches the routes we loaded from the CaaS to later decide what should happen when individual client URLs are called.

The shared layout binds to the global content to provide headers, footers, and the application framework. Now when a specific URL is called, we get into the routing middleware up here. The router looks, okay, is there any general error? That might be the case, for example, if either our routes or global content couldn't load at all and we can't actually do anything useful, then we show a generic error page. In the other case, we check against the routes from the store, is it a supported, known route with meaningful content? In that case, we render that page by displaying the generic page here, which I'll get to in a moment. If this is a route we don't know, we display a 404 page.

Rendering our own page is, of course, the normal case when a valid URL is called. We first change the split layout, what all pages have in common, using the globally described content. And then into this global layout we'll put the actual, the actual page, which in turn is actually just a sequence of components from all the components and are loaded by the CaaS when the page is called, at runtime. The trick is basically these dynamic components. That's something where actually Vue comes in handy for us a lot. All of our pages are basically built the same way. They're a list of components and we get by with very little code, in effect, very generic code that we see here. This is actually, there is, the core of all the display logic of our application. What we're doing is, we're iterating over the components of the page here. And for each component, we dynamically bind a Vue component on the client side, we do that here with this Tec component.

And here via IS we say what kind of Vue component do we want it to be, a header, a text block, an image, whatever? Here basically the FirstSpirit Type is mapped to our Vue component type with this function. And in this way, dynamically every component that we support is instantiated in the client. This is basically enough to render all the pages. So much for rendering the pages. But of course, we still need to integrate our application with the content creator. We saw earlier, the application is embedded in an iFrame in the Content Creater framework. Now, to enable communication between our application and the Content Creator, which is simply necessary at certain points, SnapJS provided by FirstSpirit is integrated into our application. That exposes within our application an object TPP Snap, which allows us to interact with the content creator. Here is, I'll say, the basic framework of what we need to successfully integrate our application with the Content Creator times out. What we do is simply, at basically initial, when the application loads say, we register a callback for the Content Creator's InitEvent and say. When the Content Creator is successfully loaded, then we register certain event handlers, which I'm not going to show in detail here now.

That's where we're talking about topics, we can register events like, a new page has been created, a content has been changed, the navigation has been changed and then we can react to that in our application accordingly and we can do certain configurations on the Content Creator. Which we also do, for example, create additional buttons for certain elements. In addition, the editing feature that we saw earlier, that we get the boxes to edit the elements, we simply get that by attaching an attribute Data Preview ID in the HTML to the elements that we want to edit and out of the box we get those editing capabilities. Build and Enviroments, we have a web pack build in use here. This gives us various advantages, minification, tree shaking, transbelation hinting, just many of the things we need to provide a performant and modern application. We see an environment here above as an example. What we do is we define for our different stages, Depth, Test, Production different ones, we can configure different environments and inject them into the application through the Webpack build. And that way we can very dynamically actually configure that application, for the different environments. And at the same time, the Wepack build also allows us to basically dynamically, depending on the environment, inject different assets into our application. For example, different styling, different fonts, different components.

And we use that to build two different applications, one for the website, the other for the career portal, from the same code base, with minimal adjustments. That means we have maximum synergies here via our Webpack build, via our modern tooling, in terms of reusing our code for the two websites that we support. The last thing we see is deployment and prerendering. We version our content both frontend and FirstSpirit with Git and deploy the whole GitLab CI automatically to our stages. Prerendering is a bit of a special issue, of course. What we have to do is when content changes in FirstSpirit, we have to render out our pages again completely statically and put it on the web server. The whole thing works in such a way that the FirstSpirit server triggers our little prerendering service, which then completely rebuilds the pages once again, as soon as content changes on it and we then store this content as static HTML on the live web server. So, finally, of course, the all-important question. Was it all worth it, all that effort? Let's take a look at how the whole thing looks on the content page.

Here above we see the content that is loaded when our page is initially called up. What we can already see, even on the first call, most of the content actually falls on images. That is, on the actual content of the page, on which we have no influence in the sense. If we look down here, JavaScript, SCC and fonts together are about 300 kilobytes, which is really very compact. And what we also see, by using cashing and cash facing, we actually manage that already on the second call of the page and of course anyway, as long as you only navigate on small pages, we don't have to reload anything except the real content, the HTML and the images. So we actually have 300 KB initial load and after that no overhead at all for our application. Accordingly, the whole thing is actually worth it for us. We see here the, so already downright scary Page Speed Scores, which Page Speed Insides spits out for us. Once on the left for the mobile page and on the right for the actual website.

And I think it also shows that we've really provided a very performant and highly optimized solution here. Let's go back through and look at what we actually have in total now. Yep, it's secure and established all the way. We have the good FirstSpirit in place, Visevic Editing we saw earlier in the video, works quite wonderfully. We have an interactive application with animation and everything without pay preload from the server. We have also seen Mobile First Design live earlier. We have the good browser support through our webpack build which gives us polyfills, transpilation and so on. We have CEO optimized pages through our static prerendering, which means we're actually delivering pre-rendered pages to Google that look the way they're supposed to look completely without JavaScript for now. And we have the reuse of content for other clients through the use of hybrid FirstSpirit via CaaS. Synergies between corporate side and website, again through our build for different environments. And we've managed to bring a high velocity to our development by decoupling frontend and FirstSpirit developments and decoupling component development. So that, all in all, we can say that the use of hybrid FirstSpirit was definitely worthwhile for our project. Yes, I've gone a minute over, but I've actually already hurried more than I actually wanted to. (Laughter.)

Q&A

Angela Meyer: Yes, thank you very much Niklas, (Niklas Krauth: Here you go.) you also with your input on the customer solution. So, now feel free to ask any questions that are open here now. And I'm just going to take a look at the chat here. Otherwise, of course, the time is already advanced and questions can be asked in the follow-up, also to webinar@diva-e.com. So, I scroll through here briefly and take me times a question here with. Namely,

Does e-Spirit or diva-e provide support for a hybrid architecture and the integration of multiple touchpoints or clients? And which clients are integrated in the project presented, for example?

Niklas Krauth: (6 sec.) In our project, we were initially only responsible for connecting the website as, let's say, the primary client, and we only implemented this part. In principle, of course, we are always willing and able to connect other clients. But in this specific project, we actually only connected the website as, let's say, a first-class citizen and primary client, yes. And on the e-Spirit side, we explicitly have a professional service that is available to customers at all times and helps to accompany projects from the initial phase through to implementation.

Angela Meyer: Okay, very good. So, if you have any specific questions, please feel free to contact our experts. We can provide assistance. So, yes, then I would like to promote our next webinars that we will be holding with our customers and partners over the next few weeks. Just check out our website and there you will find our diva-e webinars, webinar series and we look forward to your participation. Then thank you Niklas and thank you Tim for your interesting input today on FirstSpirit Hybrid CMS. And yes, thank you very much and I would say see you next time.

Niklas Krauth: Yes, thank you very much and have a good time everyone.

Angela Meyer: Thank you, you guys as well.

Niklas Krauth: Thank you.

Tim Rother: Thank you. Ciao.