Hello, everybody. I'm Victor Fernandez de Alva. I'm part of the Plone community and I'm part of the Volto team

which is going to be the default front-end for Plone 6. And I would like in this presentation to talk about how does Plone 6 work internally because we are moving from the classic single monolithic SSR model

that Plone 5 and its processors were. And we are using our React JavaScript server-side rendered front-end in front of Plone. And this brings a lot of questions

on how this really work, right? So I would like to make a quick hands-on, let's say, on how this Plone 6 is going to work under the hood. So here is Plone 5, right? So it's the classic way of monolithic frameworks

and server. So you have a process that is running on Python. And this monolithic server is doing all the work, right? This is getting the content from the database,

then making the calculations that is required, calculate also the other template in giant, how it should look like, and then it sends the HTML to the client that has requested a page, for example.

Plone 6 works in a little bit different. So we still have the classic Python powered process on the back, which is still Plone. We will call it from now on Plone 6,

the classic server-side render. But we still, we have a new component, which is the Volto server-side render, is the new Node.js Express app that allows us to server-side rendering the front end. So CO and other services that require

that the content is not being rendered by the client, so gets the actual data into those services.

So again, what is SSR? From now on, we will use this abbreviation. SSR is server-side render. It allows, how it's done, Volto, it's that it's an isomorphic app. This means that some code, the same code runs on the client and on the server.

This allows, this feature allows to write only one code, one feature, and then this code is being generated both on the server and in the client. So it generates the first request, that's the HTML page.

And as I said, this is for CO, for crawler, web crawlers of search engines that then will make that our page is going to be rendered properly,

and then the crawler is going to get all the information, the same information, in fact, that the client will have rendered in our browser. It also serves their static resources for loading the app in the client and some other things in Volto.

So how it works, so we have to differentiate between the first request and the rest of the request that comes after the first request. And this first request will mean, I mean by when you reload the page.

So when you reload the page, this first request that is happening is that your browser, your client is going to ask the Plone 6 SSR server, the Volto SSR server. And the Volto SSR server is going to call

in this that number is going to make all the REST API call to the Plone 6 classic server-side rendering engine. And the Plone, the backend is going to answer the via JSON with the results of these calls.

Which ones, which calls does the Volto server that? So like it does the main one, which is asking for the content, the current content. It does other calls like the breadcrumbs, the navigation, the content types that are allowed in that content,

amongst other calls that Volto requires. So Volto is going to make all these calls in the server, not on your client, in the server. And it's going to ask the Plone backend via REST API. And the REST API is going to return the answer.

And then the Volto server-side render process is going to assess all this information. It's going to render the page and it's going to return the page into the browser, which will be the number four, right?

What happens from there? So this process is quite quick and we are going to have the browser, the only thing that should have is to read this static page that is going to, static, this HTML page that is going to answer

the server and load it, right? So after the first request, after we have this HTML and all the resources are loaded, the JavaScript client app takes over and the server-side render is not used anymore, right?

Unless you reload the page. This process is called in JavaScript, jargon is called hydration. So it's when, as I said, is when you receive the first request in HTML and all the resources, and then the browser loads that these resources

upon these HTML and hydrates makes the JavaScript live on this HTML, right? Then from this point over, when you click on other,

or on a link of the router, or you change the route via something or whatever, then after hydration, the client, as I said, takes over and we don't need the bolt of server-side rendering anymore. Then our client, this bolt that is loaded in our browser

is going to take over and is going to make the calls, the REST API calls, right? Then what's happening in Plone 6 in production? So in Plone 6 in production, we have this both process.

Remember, we have the classic Plone process in the server still. We are not going to lose that because it's the backend. It's the backend for the client, for the JavaScript client, right? And it can run in a port as usual in,

for example, in the 9001, but we will also need this Node.js process running on another port. That will be the bolt of server-side rendering. The Plone 6 frontend server-side render part that could run, let's say, in the 11001.

Then we have to make them available because, as we said before, we need that our client reach both the backend and the frontend, right? And then what we will make is using Nginx reverse proxy

or the reverse proxy of your liking, you need to point the main URL of your site towards the server-side rendering of the bolt of the Plone 6 frontend. And also you have to make the classic,

Plone 6 classic as a server-side rendering Python process also available because your browser is going to ask for it under the hood via XHR requests, right? So we can put it wherever we want, but yeah, for example, in HTTPS,

as a 2.0 slash slash Plone.org slash API. And both need to be accessible. So that's why we are doing. We normally, the recommended option is to use the same virtual host because then we will avoid course issues.

Both can be scaled horizontally. How many processes that we want provide the ability that we put on the front, the balancers and the infrastructure necessary balance the load between them, right?

We also use a process manager of our choice, your choice, which can be like PM2 or systemd or supervisory to manage these two processes, right?

Then I want to also to talk about a new feature that is upcoming in Volta 13, which will be the next major version that we'll see the light in the next weeks. That is that you no longer require to have your classic API, that backend server,

the Python process in another directory, right? In another path. You can have the same, both the Volta server-side render and the Plone 6 classic server-side rendering under the same umbrella in the same virtual host,

which will be this diagram, right? As I said, now, right now, it's not possible it's going to be a feature of Volta 13 and it requires a little bit of additional engines configuration for correct routing, but it's going to be the default for developing in Volta 13.

And what's happening in Plone 6 in development? In local development, you're going to have this, you also need to have the two processes running for sure. You're going, by default, you're going to have in local host 3,000,

the Plone 6 front-end server-side rendering, the Node.js process, and you're going to have also the classic Plone Python process in the way. You don't have to come, because Volta comes with an internal proxy for development. So, and it's pointing to this default

local host 8080 slash Plone by default, but you can change to whatever site that you're developing or match to your developing likings, right? Yeah. And by default, these proxies pointing,

yeah, as I said, to this URL and their local host 3,000 API. As, and again, from Plone 6, there is going to be this slight change that by default the development is going to use seamless mode so both the Node.js,

the Volta server-side rendering is going to share the same local host 3,000, but the internal proxy will take care, right? So you don't have to take care of anything. Yeah, and that's it.

Yeah, I hope that this talk will have shown some light into how Plone 6 works and happy to hear and see you soon.