 So, good afternoon everyone, thank you all for coming. My name is Adam Zaninsky, I'm from Koriate, an Austrian news agency and daily news publisher. And together with my colleagues Julia Paradel from Hubert Burden Media, we've created a wonderful funder distribution and and Romelk from Platformer's H, who's making us fly. We would like to present you a use case, basically on what we did the last year, over the period of the last year, and I would like to show you what in our opinion is the future for digital publishing. It's not PowerPoint. So some rough figures about us. We are from Austria, we have peaks up to 10,000 concurrent visitors. Some of you might know we tend to have elections and re-elections, so this is obviously an issue. We have around 100 editors working more or less concurrently with the CMS. We have multiple portals, so it's not actually only Koriate, but there is a bunch of verticals, so some call it multi-channel, multi-portal, whatever you name it. There is a lot of brands that we want to serve from this new set of technology, and we have around a million stories. So these are the rough numbers that we are dealing with. So that's why stuff like caching and invalidation and concurrency and SLA will be relevant to us. When you started thinking about the new CMS, what drove us actually and what were our goals? Primarily, obviously, we are thinking about our visitors, of course, always as well to monitorize those visits. So what we want to do primarily was to increase the engagement. We want users to come to our page and be informed, you know, see what's relevant, see what's going on. So especially nowadays in times of social media, where people don't have that close relation to a brand anymore, we want to keep it close and to show the users that, you know, come by and you will see what's going on and it's worth coming by. That's the one. On the other end, of course, of the pipeline are the editors. As I mentioned, it's about 100 of them, and they are writing a lot of stories. But in order to do so, often they have repetitive tasks. So our primary goal for editors was to improve the workflow, to basically save time. So because we have a lot of very, very smart people, luckily sitting in our editorial rooms, we don't want them spending time on stupid tasks like searching for pictures or invalidating caches or, you know, all the things that all of us bring them down from everything's work and distract you. So maybe the biggest point here would be to minimize the destruction editors would have in their everyday's work. Obviously, as workflows tend to change over time, as you might know, the goal was to set a technological base that gives a lot of opportunities, but do not narrow you down. Then, of course, we have to, as I mentioned, publish the stories as well as somewhere. So this is what we call audience development. These are the people that define, I mean, all the, a lot of stories that we write on which page to publish what and in which order, right? So they look at the people, look at their behavior, and again, try to present the most relevant stories to our users and respect the user journeys, of course, as well. This, of course, includes what we, group of people might call page building, and coming from legacy CMS, where basically a lot of page building steps would require calling development. So people were calling us, you know, do stuff, but I don't have time, you know, I have to fix bugs, or actually I'm doing something else already. And then, you know, time critical things, again, I mentioned we are a daily publisher. This wasn't very suitable. So another goal for there was that you can build pages without calling us. Yeah, and there's a lot of other things like sales, again, we have to make money of it, and syndication, which means that we publish stories not only on our own pages, but potentially sell them to others. And there's print, possibly, and all the others. There is, from where we come from, this whole mobile and desktop split, and then come responsive, and it's very good, but it's actually far beyond that. So if you take a look at the web and how you consume news, or actually, how you consume the web altogether, this can be from a desktop computer, obviously, but the rate is lower and lower year by year. Then there is mobile, but it's actually even beyond that. You might have heard of Google AMP, so whenever you search for something on Google, on your mobile phone, you see this lightning sign, right? So how this works is that Google basically needs its own version of HTML. So it's the same context and just another markup. And then there's others like RSS. Of course, you want to publish the social networks and native apps, but not up to chat, but so long story short, there's a lot of channels where you want to reach people, right? There's maybe what's up today and tomorrow it's something else. The truth is we don't know today what will come up tomorrow. But the whole point of this is to be so flexible that in this fast-paced, fast-living world of news publishing, whatever news comes in, you should be ready for it and ideally be one of the first. So in the end, it was quite easy. We have to write a new CMS. And there were a lot of things to consider, right? Do we want to do online only or do we want to do print as well? Among all the products that are on the market, and there's just a lot of products on the market, from software as a service to proprietary, which we had now and I'm not lucky with it, to, of course, open source, a lot of technologies. So long story short, there were a lot of options. Think of some proprietary systems that cost really a gazillion of money. But it turns out that actually we need only a small part of it. So actually we overpay most of that. But on the other hand, we still need some customization. So that wasn't really an option. And of course, we don't want to reinvent the wheel, right? So if there is stuff like doing forms and all the others, then we don't want to do this from scratch. And actually, some two years ago, there was the Drupal Meetup in Vienna. And that's the first time we came in touch with Drupal 8 and its OP principles. And from there, actually, we were very satisfied. I had a good opinion about that, that it's going the right direction. So there was the idea to start with Drupal. And after we started looking for Drupal solutions, actually we came by Thunder, which I would like Julia to introduce. Hi, everybody. I would like to introduce myself. My name is Julia. I'm community manager at Ubud Boda Media. And that's one of the biggest publishers in Germany, maybe even Europe. And some years ago, we faced some challenges when it comes to content management systems. Yeah, so it is a short story of Thunder. At Ubud Boda Media, there are more than 500 websites worldwide. And they used to run on more than 100 different content management systems. That wasn't very effective. Especially as in today's digital world, we are faced with new challenges constantly. Martin Sowell, he said, technology will never again change as slowly as it does today. Change is accelerating. And we need to adapt faster and faster. That's why we have decided to use one CMS for all Boda brands. So this is Thunder. We used Drupal 8 as base, since it fitted our needs almost perfectly. You probably know almost all of this, but it's free and open source. It's a fully responsive front-end and back-end. It's built with PHP, it integrates symphony 2, and it's widely used and highly appreciated by developers on SEO. It is easy adaptable with thousands of modules provided by a global community. So we used Drupal 8 and added some publisher-specific features and configurations to create Thunder. In 2015, we started the first project, which was Playboy.de. They adapted the Thunder core for their website and contributed some modules to the core, which grew as a result of this. And the same happened when Instile and every other Boda website relaunched since then. By now, almost 20 Boda sites are running on Thunder, not only in Germany, but also in the Czech Republic, Ukraine, and India. And also non-Boda websites are running on Thunder. The Thunder sites generate more than 60 million visits and approximately 240 million visits page impressions per month. So Thunder is a perfect solution for Boda. Now let's have a look at our brands again. They are a lot of different business models. You have Playboy.de with paid content. You have the cooking recipe with a huge community. You have My Beautiful Garden, which is an e-commerce and selling product. You have Ubuntu.de with video content. You have Instile, experts for fashion and high class. So we realized that Boda is a smaller representation of the whole publishing cosmos. Also in the end, hopefully Thunder would be the perfect system for everybody. Plus, we are convinced that what matters today is not so much the technology, but the content. With the internet, everybody can become a publisher. What differentiates some guy on YouTube and a big publishing house as Boda is not the technology, but the brands, the minds of journalists, the content and the connections everybody has. That's why we have decided to give Thunder as an open source system to other publishers. Thunder is unlimited and free under the new general public license. The community will enhance the system and therefore everyone benefits by improved speed and reduced costs. Boda as well, of course, but everyone else too. There are no obligations. Every publisher can decide what part of the development they want to share, none, all or some. For example, the Korean, they decided to support the development of a live blogging module for Drupal, which is now part of Thunder. There are, of course, no logos, no ads, Boda will collect no data. It's very important to highlight when you talk to other publishers. Actually there's no need to tell anyone that you are using Thunder. Nevertheless, we hope for a growing community. We want to introduce a culture of sharing and cooperation in the current publishing world. Our intention is to foster cooperation among the industry so that we all are able to concentrate on what really makes a difference, the content. We founded the Thunder Coalition, a community of publishers, industry partners and developers. Coalition members develop valuable modules, use them for their own purpose and share with the community. Together, we want to build the world's best possible CMS for publishers. So that's the idea of Thunder and we're very glad that Korea joined this coalition. And with this, I would like to hand you over to Adam again, thank you very much. Thank you, Julia, not only for the speech, but really thank you for Thunder because I think you've taken the open source thought to the next level and the sentence that we are repeating so often that we shouldn't compete on technology if at all, then, of course, by content. This is actually a great idea, thank you. So I stopped my last sentence, I think, was something like do not reinvent the wheel and via Thunder we actually got much, much more. So now we already have Drupal, which you all know, and we have Thunder, which you might get in touch and talks in Drupal as well, which has from media to paragraphs and to all the other things that just makes life easier. So just the way that Drupal ate basically has just taken some already known working principles and put them together, again, Thunder has done the same. They've just taken some modules that already work, make a best practice of it and publish it and make it available to others. But then I also mentioned relevancy. So what does this actually mean? From a current standpoint, when an editor writes a text, beat it longer, he tends to tag it for no reason, which is very tiresome and can introduce errors because then you possibly have a lot of similar tags that have actually no relation to each other. But luckily, there are systems not too much in depth like possibly Retresco, the AI-driven, and what they do, you give them their content and they tell you what categories it belongs to and a lot of other stuff. There's linking for it and topic pages and it's actually really a great product. But what also comes with it is Elastic Search because it's based on Elastic Search. Now I know that Lucene is very popular among the Drupal community. I can really strongly recommend giving Elastic Search a try. It is based on Lucene, but it's actually way more than that. I might give you a short example here. So what we have here, I have to find it somewhere. Yeah, I don't see it, but you should see it. This is just some JSON, some very rough article. And if we tell Retresco, please enrich it. What comes of it? Not only does it detect Vienna as a location, which is cool because imagine you want to have locally specific news, right? So I want to see when I go from a mobile phone to my local page, I want to see what's going on around me possibly and group stuff together. It actually detects DrupalCon, if I see correctly. So within a click, I could have a whole page about DrupalCon and all the other things. What it also does, it does in-text linking. So automatically within the text, within the article, you have the link to the entity. Read the topic page, read an external link, it's totally up to you. So that's really, really helped us getting an understanding of what kind of content we actually have and how does it relate together. So one way or another, it's really a great benefit. And then I mentioned Elasticsearch. In order to get stuff in there, you need some form of structure. Now again, coming from the legacy system, where most of the content was just HTML, we had to break that up. And luckily Thunder had already paragraphs in place. So although it was some kind of work, now we already have some first form of structure within the article. And going from there, I will show you some example right away. We had a clear structure, again, for our articles. And there is a question about bi-directional. Yes or no? So because we already put stuff to the index and we had to search API backend views or have views in place that already work at top of the index, there was the idea, why not get rid of the database after all? Because it's redundant and no one likes redundancy. So the idea was that as we put the structure data to the index, it would be really cool if several Drupal instances could work on the same index. And solely the index would be the single source of truth, if you want so. So you could take the data from the index, read it and work only on that. It was a great idea. It was almost working, except that some modules tends to use SQL, like hard-coded SQL, and that actually killed us. So long story short, do not set your node storage to null storage. It just won't work. But as I mentioned before, the search API backend and elastic search, everything is a query, right? So we started using the Powerful Access Search for grouping, for indexing, for searching and for making suggestions for editors. And this actually improves the speed a lot because I think again we have around hundreds plus editors that work concurrently. If all the searches and everything beyond, like from page generation to aggregation would go via database, I think this would require a lot more of resources. But then again, going from database to SQL or elastic, how we call it, requires some change of mind, obviously. So we had to get rid of the idea that redundancy is bad. Truth is, if you have control over your redundancy, you can live with it. So it's really worth a try. I can give you an example here of how this works. So this is an article. As you see, there are paragraphs in place. There is markup. There is HTML. There should be images. This is image in German. So let's take a look at the result, how stuff is looking. Oops, there was a wrong one, sorry for that. There we are. I'm making it a bit larger. So the interesting part is here, the payload, the stuff we put here. And again, if you reduce this a little bit, reduce that. So you see data is still less. And here comes the fun part, right? So the paragraphs. Okay, this is a text. This is a slideshow, actually. And here you see the redundant data. Truth is, if for a seldom case that some title or anything changes, it's easier to change something else in the index as well, as long as you have control over it. But for fetching this article, it's just 0.0.01 seconds. It's lovely. Let's put some more to it to show you how important it is to deserialize the data. What you see here, actually, is a very nice thing from the Thunder admin theme. So you have not only paragraphs, but you can add stuff in between. So I want to add a YouTube video, which I found my mouse. So there we have it. It's going to be saved sometime. So what I see here, what we actually only serialize is that we use a paragraph of type YouTube, and that's the video idea, video ID. Why don't we save the rendered iframe? Well, think about our editors that right now paste an iframe into the article editor, and they say with 600 pixel, because you know the desktop article is 600 pixel. But then it comes mobile, it comes app, it comes AMP, and it all crashes down terribly. So I really recommend YouTube paragraphs to anyways, serialize only this kind of data and not the render structure, because it will fall down of you once you have, again, those multiple channels. And then there's the idea, because once we started indexing articles, why not index everything? Right? Because not only do we have articles in search of articles, and then images in search of images, and agency feeds, and all the other things. So that's why I've taken it to kind of the next level. And not only do we index internal stuff, but possibly also others. And the result is actually really amazing. Again, remember, our goal was to save editor's time. So what we've done here, we index, well, you know, social stuff and agency stuff and articles. And then because of Elasticsearch, actually this is a very simple query. It took us 10 minutes to write it seriously. It's called significant terms, because Elasticsearch actually does everything for you. So what we do here, given the period of time, what comes up significantly more often than within the given, you know, full data set, say. So this is called because, imagine this is 10 hours. So editors come to the office in the morning, and they want to know what has happened last night. So they click it. And if there is one George Clooney article a week, then he won't pop out. But if suddenly there is a spike in George Clooney articles, well, it's something might have happened to it. Luckily George Clooney is OK. But let's see. Imagine this is George Clooney, right? So OK, there is an image. Again, think this is George Clooney. There might be something else. There might be an article about him. Hopefully nothing has happened. So let's take a couple of articles, maybe let's take a tweet somewhere and make an article of it. And there we have it. There's the article. There's the image, right? Obviously, starting with admin theme, because we did not have to reinvent the wheel. We could do article stuff. Like, because there is a long text, think about editors writing a word, you know, and then sending other people the text to insert it. And then imagine you want to have a tweet in between. So what we can do here? Which we should do here. Let's put the paragraph. And then again, in between, you could add a tweet and stuff. So long story short, index everything. OK, so now that we have content and our editors are super happy regarding the workflow, and we even provide context to do it. Think about the previous example, that we are enriching content, right, and not the text, but also have a huge data set. Imagine taking this to the next level. Once the editor starts writing about the topic, on the right pane, you can like preview for related content. So when an editor starts writing about, you know, person A gave person B the hand and they met yesterday and they argued about stuff, then automatically you have the current photo for those persons next to it. OK, but truth is, we're not getting money by writing stories, we're getting money by publishing it and people reading it. So, one of our bosses once said, you know, what's the deal? Come on guys, you just write stories, you know, and publish it. Not. Truth is, there are several user journeys you have to respect. So obviously, a huge part is people going directly on the article from what we call search, organic search, or from social media. So that's one part, but there are a lot of other bases to cover. And we have very popular form of entry points, which are called section pages, channel pages, actually. Think about politics or sport, right? So, curiosity is their sport, stuff like that. So how these pages are built. I'm going to skip forward a little bit. This is how a channel page might like, right? Because this is some politic, related content, think of it. There are blogs, you know. And these blogs are fed by stories. So, in order to build such a page, of course, there are several ways. But in the end, we decided to use panels in place edit. And why is that? Because we actually decoupled, and now I go a little bit back, the layout of a page, which would be there is a big picture at the top left, and then there is a list next to it. And then there's maybe some advertisement and some newsletter called to action. So these are all the blogs. But this is basically only the layout. Again, think about what I mentioned before. For changing these things, I don't want to get caught. I want them to do it yourself, themselves. So this is the layout. Then the layout, of course, has to be filled with some content. So then again, audience developers, they could drag and drop stories like crazy. But then, because actually the layout doesn't change, it's an unnecessary kind of work. Especially think of if you have lists that should represent the most commented stories or the newest stories, almost relevant, or you name it. This would be very hard to achieve. So that's why introduced, or actually one thing I've taken from our legacy CMS, is what we call collections. And actually, collections are search queries because remember, everything is a query. So the example here is some collection here, right? That's an automatic one, if I see correctly, hopefully, yes. So what I can do, oh, my mistake, to the left is the static collection. Because think about the starting page, top five elements, editors want to craft manually. So here you have a search stuff where you can just insert your stories and aggregate into a static collection. It's, again, actually a search of those IDs. Under the right one is the more, say, yeah, the dynamic one where you just create a search query, say, it's based on, I don't know, some criteria. And then it's displayed. So let me give you here a short live demo. What I'm trying to do now, I'm trying to build a channel. And say it's about, we call it Drupal. And what we want to do now is to obviously put some content. And that's why in-place edit comes in. So imagine we want to have a list. Hello, Drupal. And it comes from some top stories. So what I have done now, I've created a channel page and said to the left, there's a blog that gets some stuff from some collection. I hope I haven't mistyped it. She's not Drupal, I think it's called Drupal only. I must have mistyped it. So there it is, right? There's the blog and there's some content. Where the content comes from is actually the result of the search query. And this is highly dynamic. So actually this page can go live and the audience development hasn't done anything with it. So whenever a new article will pop in that matches, you know, the search query because it's even newer or has even more comments, it will just pop in. Maybe one more example. And this is why in-place edit is very, very nice. You have also drag and drop possibility. So I could put the list actually, I could, you know, drag it around, stuff like that. Comes in really handy. And maybe I want to place an advertisement on it. And think of it, this is all live, this is all un-cached. But this is the speed that, you know, people will work. There should be an advertisement. Oh yeah, there it is, right? We have Cloudflare, so Cloudflare takes some seconds and that's it, okay? Then comes the question, because actually right now what you have seen is already working frontend. But because we have spent some time on improving our backend, I mentioned syndication and all the other things, like, you know, stuff where we did even more symphony stuff than ripple stuff, we wanted to have a nice frontend. So we engaged a couple of people to make us propositions and how do you actually make a frontend prototype? And this is, again, this is not about technology, this is not about tweak or decouple, whatever. This is just a rough idea, where do we start? So probably people start with rough mockups, which are fantastic because they give you an idea about how things will look like and how they are structured. Actually more about how they are structured. What content types do you have and how many page types do you have? But as we all know, mockups not very looking very nicely. So from there, actually you can increase the fidelity and then make things that look indeed nice. All the adult products, which some of you might know better than me, from XD to InDesign to Photoshop, you name it, and they're all beautiful, except you want to change something, right? Like the boss comes over and says, hey, listen guys, let's increase the font size or spacing and all the other things. So in the end, it turned out this was just a waste of time. Also, yeah, what was better actually was stuff like SC5, which is a Style Guide Generator, which I can actually kind of recommend, except because it solves a real problem. You have already someone writing code, it's generated and it's easy to maintain. But as you know, people that write mockups think about titles, image sizes, they have their idea of test data, right? So they maybe want to write a title that kind of acceptably matches the width because it's looking nice. But the truth is editor won't give up about it. So I'm sure people will write longer titles. So that's why it's very important to use live data, okay? So over the period of time, you see already possible variations and how your site would look like if it had real data again, right? And not only the one that someone thought of because it would look nice. So from there, it was a nice idea, extra angular, what was called two, or only angular came by. And we thought, hey guys, let's make a prototype that already has real code, it has SAS and stuff like that. So I can say, I don't know, my variable dollar font size is 14 and I can reuse it. But also because there's an application behind it, you can have real data. And from there, obviously, you could build a real application. So that's what we did. Something I will come by in a second, obviously, flat from a stage that also helped us distribute these ideas because if I change something locally and wanted to show it to other colleagues or bosses or whatever, it's kind of difficult to distribute applications in a test stadium. But I will come to this right away. And actually the last one is very important, it's never forget to throw away your prototype because all the code you write is better the second time you write it, you all know that. So luckily, angular messed up and from angular two to four, which should be compatible, there were so many changes that we had to throw away the prototype. It was very good. And as we had already angular, to all of you who might know it, it's what's called a single page application. That means that once you have loaded the page and navigate within the page, you don't have to reload all the page again. You only can reload the content part or whatever is necessary to you. So this is obviously fantastic for our visitors because once you've loaded the page, every click from there is just two to three kilobytes. It's just the JSON or even a smaller version of the JSON you have seen before. So the transitions, the page transitions, they go blazingly fast, right? Remember in the beginning I mentioned that we want to increase engagement of people. So once you are on our article, what we want to do is to easily make it navigable. So you can click around because we all know how it feels if you go to a page because there was an interesting article and then there might be another interesting click on it, but it takes two to three seconds and say, hey, come on, okay, never mind, all right, next one. So this is something we want to prevent and hopefully we'll solve using single page applications. And there's another huge benefit which is called, which I call decoupled ad impressions. Again, because we have to serve ads unfortunately, think about the whole page and about ad positions. And think about ad positions that are possibly paid only after specific period of visibility. So someone comes to our page and there is an advertisement displayed which people pay for only if it's displayed for 10 to 15 seconds, for instance. But within the 10 seconds, you as a visitor already have found some nice articles. You click on it and that means our ad was displayed only for eight seconds and we don't get any money. So it's just a lot of benefits. Again, let me give you a short demo. I have a picture prepared. So let's go on some articles and we have your advertisement. And what I will do now just to demonstrate to you that this is the image, I hope so. Yes. So definitely if I would reload the page, this would get lost because this is my manual thing. So what I do now, I will go to another article and there is still the ad, it did not reload. Actually nothing reloaded except this small part. And what's also cool, let's find the network. Let's go to another page. What happened? We loaded a channel page that actually was five kilobytes. So the whole page, the whole content, of course, except the images, it's five kilobytes. I go to another article. This was Uncached, right? No one ever seen it before. And this was what, I think, three kilobytes for the whole article and so further. So this was Uncached again. So because I don't think that so many people are on this page right now, I could go to another one and there it is. What's even cooler, because we cached the result, if I go back, that's it, right? No need to reload anything. So, but what else do we have? Unfortunately, we don't have only classic HTML. We also have, or responsive HTML, we also have new kits on the block like Google AMP, which again means that this is just another representation. This is just another set of HTML, but fed by the same API. So in order to render HTML or to render Google AMP, we use the same JSON that we used before, which we can again heavily cache, right? Think about the million stories. If I'd have to build them from database quite often, this is just wouldn't be suitable. And what's even worse, building it from the database that the editors are working on would of course have a negative influence on the workload for the editors. So this is fully decoupled, right? The editors write their stories back to the database because it's necessary because we are sloppy. Put it in the index and every from there is without a database, especially the front ends you see here, they just tend to be Barbie and Ken. They just tend to be beautiful, but there should be no logic behind it. And that's on purpose. So we don't have redundancy, another type of redundancy. Another great thing that comes with Angular actually, and I can highly recommend it to you is TypeScript. Basically TypeScript is how they call yourself super set of JavaScript. So what does it mean? Every JavaScript is already valid TypeScript, right? But it has a strong type system. To all of you who are writing JavaScript and know the pains, I can really, really suggest, try out TypeScript. Basically you can take any JavaScript, put a TypeScript compiler on it and work from there. You have fantastic things like null checks. Think about most or so many method calls we do and I think in a lot of high percentage of time, the next line always is if result is not null, if result is null, right? Our code is so full of it, actually should be. The cool thing with TypeScript is you can say, we have strict null checks. So if a method says it returns an object of type, well, person, I can be sure as a consumer of the method that there will be a person returned. How is this achievable or achieved? That the compiler does not allow me to return null in such a case. So if I say in my header, my method returns person and I say, well, if something went wrong, return null. You say, no, no, you can't do that because someone is relying on you, on the contract you have, that you are returning a person. Many other things. So I can again really, really recommend it to you. Yeah, then because I mentioned Facebook and Google, there's another thing. Actually when you load a classic Angular application, you would only load the bare minimum and then the application would only kick in and build your page. But think about Google coming by. And I think also that Angular is actually a Google product and doesn't work with Google, but it's another topic. If Google comes by, they want to have meta text. They want to have the content to scrape, already pre-rendered. And that's what Angular Universal is good for. Think about the client, he wants to visit the page. So that was how Angular Universal on the backend is fetching some APIs. In this case of Drupal, you've seen these APIs before. It can do it asynchronously. That's the perfect thing about Node.js. It has this cycle. What does this mean? Think of, you have to make 10 requests to an API in PHP in general, especially if you're on the web. You would have to wait for every single result to continue with the other. On Node.js, luckily they decoupled it. So you're working with callbacks. So basically you can make 10 requests concurrently and just as they chip in, you fill your page. But you can do it more or less in parallel. So this speeds up again, it's really fantastic. And once the whole page and all the API calls from the layout, from the collections and all the other things are available and the page is rendered, then an already pre-rendered HTML is returned to the browser. On the browser, there's something called pre-build. So it makes from this HTML, it makes a real Angular application, it re-angularifies it. And from there, you have the single-page application and when you navigate from this Angular application, we've seen it before, you already only have direct calls to the API. It's actually the same calls that Universal would have do, but you don't have to do all the other things around it. Again, it saves time, we've seen it before. Yeah, let's give it maybe a two-minute shot here. Where is it? Okay, so this is my local, I think if the port is 8888, then this is Universal. So this is my local machine doing stuff. And if we see the page source, where is the page source? Yeah, so it's already rendered HTML. Compared to my other port, which is hopefully 4200, which is the non-universal app. The cool thing is with developing Angular, you have the AngularClean that does the automatic refresh and all the other things. So all you have to do is just change a template or change a style in SAS, and it gets live reloaded. We'll see this right away. But if I see the page source here, so this is the non-universal part. You don't want to serve this to Google. Google needs that, or they want that, they claim. So that's why Universal is a great thing. I think React is something similar. Let me change a color here. Will it work? I just put some line of CSS and hopefully this will compile within three, two, one. I'll see. Oh, it's there. It was 92%. Okay, so I made it blue. Okay. So long story short, for local development, it's fantastic. But then I mentioned we want to present this to others. So, what I've done now, I've just changed this line. So let's make a new branch of it in Scottish. Rupalkon, not really, huh? Oh, come on. And what I will do now, I'll go to platform as H. So what happened here? I pushed it to a branch. It should be here somewhere. Actually, it's not... Oh, it popped up already, look at that. It was faster than my Angular. Long story short, what do we see here? We see a master environment, which is obviously continuously deployed from a master branch. But I pushed another branch here. It's not activated per default, and this makes sense, because given you have like a gazillion of branches and people, you don't want to activate everything. It's not really necessary. Just let it activate the branch. This might take like one or two minutes. And after two minutes, we'll have a nice blue font, which we can send to our customers. From there, can I introduce one more time, Andrew, from platform as H, to give you a bit more in depth about platform and how it's working? Yeah, thanks, Adam. So I think what Adam's showing there is that what platform as H is doing at Korya RT is to bridge that gap between what you can do on your local and what you actually need to have when you're in production, which is what takes me on to that, should take me on to that next slide, that that's what's happening in the background now. And by the time I'm finished, Adam will be able to go back to that. What we do is we give you the ability to clone, byte for byte. So really quickly, everything that you've got in your production instance, and then move that over to a new environment, for example, for a security update, a feature or a bug fix, or as Adam was showing for some kind of QA reason in this particular kind of case where you might, or you might want to show a stakeholder, a new version of the site and so on. And so what we're helping there with is actually, on a low level, you could say, well, we're making things faster, but it's really about being able to actually increase the speed of innovation or the efficiency of being able to maybe update what you're doing on the level of the design, the level of being able to actually get your internal stakeholders or your customers the results they want quicker. And that's something that applies as much in media and publishing as it does in e-commerce or any other area where what you want is primarily agility. So what we also do there is, as well as being able to give you those new environments very quickly, there's a very simple way in which the environments also, sorry, Git will also contain the infrastructure, so it's actually gonna have a very concise description of what the services are that you're running, the configurations that you've got there, and you can actually also deploy arbitrarily complex clusters there. So in the particular case that we're looking at with Korea RT, they've got a backend which is Drupal 8, they've got frontends which are Node.js, they've got a middle, sorry? Oh, well, yeah. Sorry, I wasn't being accurate enough there. But anyway, so, but you know like there's the ability to have those kind of arbitrarily complex clusters as well, so you can also have like side-by-side node and symphony, that kind of thing as well. And of course what's also interesting is perhaps, you know, like you might want backend services too, so I'll come on to those in a moment. We're first gonna just look at the triple redundant architecture that we also have, so we offer a 99.99% uptime and triple redundancy because we use for MySQL and so on, we use a Galera cluster, so you actually have three side-by-side single-tier versions of each of your application three times, so that gives you high availability and dynamic scaling as well. And as I mentioned, you've also got the ability to run all sorts of different services and for example in a single Git repo you can run perhaps Node and symphony with backends where you'd also have Mongo and MySQL and maybe also RabbitMQ, some other backend services, you could also have, for example, the ability to have also PHP workers running as well, that kind of thing. And obviously when we do this kind of stuff that's normally when we've got the kind of cutting-edge customers who actually are asking for this kind of thing and CorreaRT is a great example of that and so I'll hand over back to Adam and hopefully we've got something built in the meantime and we can have a look at that as well, so thanks. Thank you, Andrew. So as you mentioned, let's find it. If not, there's something really cool you can do, there's Eclipse, you can save platform web which opens platform on the web and there we have it. Okay, so I've made some type of this. This is if you circumvent continuous integration, continuous deployment and this is what happens. Let's give a better example, it works. So this is uncached, so it takes some time. It's universal, so it has to gather all the data. But once it's there, it's there. Apparently people were playing around with colors. Oh yeah, there are colors, look. So that's actually really, really cool and saves us a lot of time. And yeah, finally, let's put it all together. What do we have? Would you have Drupal 8, actually Thunder based on Drupal 8, which is like the back end, right? We have only one end of the pipeline, people writing to it. We might have a database, unfortunately, we re-indexed things and enriched things and put it in the last search. And from there, everything is consumed via an API that actually, because we're lazy, is in the same application, but in theory, it could be anywhere. And then it's the front end, driven by Node.js, Angular and Angular Universal. That's client's access, okay? What else is there? Obviously something I missed yet, missed out yet is the users or maybe some other consumer of the API like native apps. But this is the architecture we are hoping to launch soon and yeah, make web even better and faster. Thank you, Q and A, anyone? I have a quick question about how you work with Thunder. So I'm just wondering from the point of view, when you, I imagine that you build on top of the things that Thunder already provides and then when it comes to a situation where Thunder improves something that's a similar thing, how does that work in like an upgrading kind of standpoint? That's just something we've had a lot of difficulty with before with distributions and being able to like upgrade from their system without messing up what we've extended on top. Thank you, that's a fantastic question. The question was how the update stages works and how coupled we are to Thunder. So Thunder provides you, we install Thunder via Composer obviously as a dependency and with Thunder they come with a bunch of modules. But luckily in Rupal you can decide if you want to use those modules or not, if you want to enable them or not. There are some modules from Thunder that we just don't use. There also were the cases where we tried to implement something in parallel because we haven't talked for a month and it turns out they made the same, okay, happens. But that's why there's actually great communication via Slack, via whatever, via email and all the other channels that inform you about the roadmap. And if you're part of Thunder Coalition you can, but not necessarily only limited to that, you can see what's going on on what the roadmap is. And based on that you can think about what you will implement your own or not. But it was really flawlessly, so never had issues. Use Composer. Just a question about caching all the stuff. Do you have them in Cloudflare or just in database? Okay, everything in Cloudflare, cool. Yes, for several reasons actually, actually for one main reason, which is called tech-based, I hate this word, tech-based cache invalidation. So think of, you have several representations of your content, be it JSON, AMP, RSS, you name it. So whenever someone changes that content, you want to invalidate all the resources at once. And that's why tech-based cache invalidation comes in, Cloudflare offers it and we love it. TBCI. Great presentations, thank you. How do you manage the analytics aspects with all these middle channels? Fantastic question, fantastic question. I didn't want you to overdraw this, but truth is we use Google Analytics and we do have the Google Analytics API is coupled to our Elasticsearch. So what we do is every minute we fetch analytics and ask them, hey guys, you know, tell us information about our content. And using Elasticsearch is super cool because you can have partial updates. So I don't have to change the whole article or invalidate too much. I just tell, okay, listen, this article had actually 500 page impressions more over the last minute. So long story short, Google Analytics API is coupled to Elasticsearch. Okay, thank you very much for coming. If any questions? Yeah, yeah, yeah. Great turn. Pardon. It went better than I expected. Yeah, yeah. Yeah, yeah. I was asking if you could do that. Yeah, yeah. Yeah, yeah. Yeah, yeah. Yeah, yeah. Yeah, yeah. Yeah, yeah.