 So let's get started with the session. So for today, we are having a session for the new recipe of decoupling with Drupal 8's Symphony and Slimfame work. Introducing myself, I am Jyoti Singh from Shrejan Technologies India. I'm working as a senior Drupal developer in Shrejan Technologies. I've already been to many Drupal camps and been a speaker in Baltimore and Drupal Khan Vienna. So let's get started. So the topics we are going to cover in this session is headless or Drupal architecture. We've been following in my project. This presentation is basically a case study of my last project that I've been using with Drupal headless architecture. So some of the topics are the problem statements that we faced in my last project for which we turned out for the Drupal headless architecture. The solution and the implementation that we adopted for my project, the Drupal stack layer, the logic layer and the framework that we are going to use as a front end in my project, and a quick walkthrough of the demo that I've prepared for this headless session. So moving forward, we are going to have a discussion about what is headless or decouple architecture. How many of you have already worked with the headless architecture with Drupal 7 or Drupal 8? Great. So basically what headless Drupal actually means is that we are not actually using the whole of the Drupal itself. So we are just using the Drupal for maybe storing the data as just for the editor to go there and store some of its data, but not actually using the head of the Drupal. What headless basically means is we are not going to use the head of the Drupal, that is the front layer. So I'm not much of a Drupal 8 person, Drupal 7 person, but in Drupal 8, we usually use a tweak templating engine. So what we used in our project is we were not using the actually tweak templating for Drupal 8. We were just using Drupal 8 to store data, giving access to the administrator or the editor user to just save some of its data and using our framework of slim architecture for the front-end rendering. So what headless actually means is that we are not directly using the Drupal as an interaction for the responses and the request and having an interface between the Drupal and the front-end layer to have their interactions. So how do we achieve a headless architecture? So there is a traditional database-driven CMS, whether we use Drupal 7 or we use Drupal 8. We'll be using it to just store the data, giving the permissions to the user to save some of its contents, tech ceremonies, and other entities. And then moving on, we'll be exposing the data of the Drupal to give the accessibility to the user to access it from some other interface other than Drupal. And lastly, we use this architecture to mainly give application field interface to the users. So that's the plus point for the headless. So this diagram is a really basic diagram I've made for the people who are really new to headless. One of the basic things that it really has is Drupal architecture, how it interacts with the user. Because there is no interface between this architecture, the user usually interacts with the Drupal directly. All the responses requests are being directly sent by the user interaction towards the Drupal. But in the headless architecture, what we are trying to achieve is to introduce a new front-end framework that will act as an interface between the Drupal and the user. So user won't be directly using Drupal as a whole, but just as a CMS to store its data. So we've been hearing a lot about Drupal architecture, about decoupling. So I've seen most of the Drupal companies are pushing the clients for going headless. So what's actually about the headless so interesting may be not as we think. Because before moving to headless, we need to really think about some of the things that are really important. Because headless itself is a really tedious work for everyone. Developers, other team members, everyone. So some of the key features that we should really think about before moving to headless architecture are these. Because there may be many project managers here, many developers here. Who would be thinking that should we actually move to the headless architecture or not? Is it performance? What is the plus point we are having if we really move to headless? Because what we usually propose to people is that headless would really take more time from the solution architect or having just Drupal in your system. So the budget of the project, obviously, if the budget is limited for your project, headless won't be a really good option for you. And if your project is just for showing the editor editorials or just an organization site, so it won't be a good option for you to move in for headless architecture. Secondly, for the team, skill set and resource management is really very important. Because the last project we delivered headless, we adopted for a slim architecture and a symphony architecture. But we didn't have people for AngularJS and NodeJS. So we did not opt it for the AngularJS framework for the front-end. So that's also a considerable point by going for headless. Next is time. Headless, of course, would take you much more time for building your site rather than having a simple Drupal site running on your system. Flexibility of team member and the project also matters. And at last the maintenance of the site because a headless site would, of course, need a maintenance from the people who are actually in your team. So why go headless? So it's still confusing now that should I go for headless or not. So if you really are looking for a site wherein you want to give the flexibility to your front-end developer to have the full content control of your site, then it's a better option to go there. If you really want to move away from a nested structural architecture of Drupal, you should really go for headless. Because the whole control of the content, not only the content rendering, but also the data that you are going to show to the user is totally under your control. Speed of the site really is enhanced through headless because there is a caching mechanism that you can integrate with your site. Though Drupal itself provides a great caching mechanism, especially Drupal 8, but still with headless you can even add additional functionalities to your caching itself. And then for true interactive experience, because even if you are having a multi-site and you want to have an app-like feel for your site, then you can go for a headless architecture. But if you really have a simple site wherein you just want to show some data to your user without more of the dynamic functionalities and you don't want to think of more of spending much time, much money and invest other resources, so you should really avoid for the headless architecture. And people who are thinking that why we should not use Drupal headless architecture is a really simple thing because we are too lazy to do it. Whether we have time, whether we have resources or anything. So if you are thinking that you don't have resources in your project, if you think that you are really time constrained in your project, so headless isn't going to be a really good option for you. So next moving on, I am going to talk about the case study of my project that I delivered, the last project wherein I used a headless architecture. So these problem statements were listed down by the companies that they were facing and we propose a headless architecture to them. So what was happening in their current site is the dome structure was too heavy. Actually when we really analyzed the dome structure and the document structure, it was really heavy with the assets, the CSS, the JS, the external libraries they were using that was making a really big impact on the performance of the site. And then when they were actually using Drupal 7, so a lot of dependency was on the theming and the rendering part of Drupal. So they actually really faced a problem, especially with the performance issue in their site. They also had third party integration, that the site was a gaming site wherein they use a third party integration for the login and then they also had Google analytics and other third party integration with their site. And DDoS also was an issue for them because they really faced a caching issue, especially for the logged in user. Because what they were facing was they had really a big list of people and the user rather than anonymous users and the caching was an issue for authenticated users for them. So the proposed solution by our team was to have a three layer headless architecture. So this is a different architecture other than the architecture we are being using in headless normally because you must have heard of the headless architecture being used by Drupal, Node.js, Angular.js, that's the best being sailed in the market today. But what we proposed to the client was to have a three layer architecture with Drupal, a logic layer and a front-end layer. So a Drupal layer was a simple layer that was being used to store data. And logic layer was a data exchange layer basically made up of symphony wherein we used to cache all the data and retrieve the rest of the data from Drupal. And at last for rendering the data we used a combination of slim and twig framework. So this was the architecture being proposed and most of the people asked us that why we didn't go for Angular.js or Node.js because the client didn't have much resources for it. So we had to move for a architecture wherein we were thinking about to use their resources. So this is the architecture that we proposed to them. So there is a Drupal layer as you can see here. There is a database for the Drupal and a caching that we will be using. Then in the intermediate there is a symphony component being used to cache the data and interact with the front-end layer. And there is a slim framework and twig template engine being used for the system. So this is the basic architecture we'd be following. And since this is a basic session for the beginners, so we won't be much going through all the details for this architecture. So starting with the first layer that we've been having for Drupal is, it's a really simple architecture for the Drupal that we've been following. Since we are moving for the headless, the first thing that came on our mind was API first approach. We'll be exposing the data from Drupal so that it can be accessible through the symphony and the slim framework. Next was the security. So security issue was main concerning the authenticated data users. But since the project has the requirement of not saving the data in the database of Drupal, so we didn't have to much worry about the security at the Drupal end. And for each of the layer we were using separate databases. So the plus point of using a separate database was that if there is a, the database will always be a fallback for each of the each of the layers. So if there is a fault in any of the layer, we will having our database intact for each of them. And specifically they wanted this implementation for a multi-site, for the multi-site requirement. So we proposed this solution to them. And of course it was a mobile first approach to have the site responsive. Next moving on, the next layer was a logic layer for the symphony. And the components that we used for symphony was there's a Drupal layer, a utility layer that would be provided by symphony, a logic layer acting between them and the integration of the third parties, third parties that we are going to have in this project. So the logic layer would be acting an interface between all the layers. And the best thing that we had provided them was with the caching in the logic layer. So what the, how the performance would increase is the data would be already cached. The non-dynamic data like footer, header and some blocks that are the static data for the site that would be already stored in the cache. And whenever the user, authenticated user or anonymous user would be accessing those data, that would be retrieved from the cache rather than having another request response flow. So the caching mechanism is the basically point that we've been focusing upon on our projects. So the caching we call it as a pre-baked caching wherein all the data that is not dynamic for the users would be stored in a cache. And the symphony layer whenever accessing the data from the Drupal would actually access the cache data rather than creating another request response chain. So the caching was really helpful at our end. The last is the front-end layer that is the slim and the twig layer that we are talking about. So slim were used as a normal framework for the rendering part and the twig was used as a templating engine for the slim. So any of us who have worked on the slim framework already, because Drupal itself is having the twig functionality and the symphony itself. So the first question that was is that why are we not using the Drupal 8 symphony, PS4 architecture and not using the twig template for the Drupal 8 itself? Because whenever you see the views twig and the note twigs generated by Drupal, it's a really heavy document. Whenever you see it, it's having a really nested divs with a lot of components that you don't want it in your system. So segregating all of this architecture really gave a control to the user as to what I can show to the client or the users. So this is the thing that we really wanted to achieve in the project. So what things we achieved by using this architecture was the page weight was reduced since everything was controllable at our end. Every component that was being displayed by twig and the slim architecture was totally dependent on the developer itself. Another browsing caching dependency was also being strong since we were using the reddish dash and there was again the page load was really quick. The responses were really enhanced and the overall performance was also increased because the dynamic content was disabled initially. Then whenever the user was logged in or whenever there was a session for the user, we enabled it again and we tried to move the JavaScript to basically to the footers so that it's always loaded after the page load. And for this project, we did not use jQuery. We used vanilla JS to really improve the performance at our end. So a plugin was created for the JavaScript to ease the usability of vanilla JS. And same for the inline, we followed some of the rules, guidelines for the development and reduce the number of inline script and PHP codes that were being used in the site initially. So moving on, I'll just move on to a quick demo. So here is the folder architecture of my server. This is a Drupal layer. This is a logic layer and this is a slim layer that's being used here. So all the three components are individually handled. If we go through the architecture of logic, this is the symphony architecture that we've been using. So people who have already worked with the symphony architecture would be already knowing this architecture. This is the app folder where all the configuration of your site lies. We have all the configuration files that we want for our local, for the environments. And then again since it's a PS, it's a symphony component, we'd be having a routing files, we'd be having services and app kernels files, etc. And then moving on, SRC is the main folder that we'll be having all our controllers, all our event listeners here. And the variable is where all the cache data would be stored for your site and all the logs and sessions will also be stored here. So this is the Drupal site, a demo site. So REST UI is a contributed module that's available for Drupal 8, which is used to expose the data of your site. So if you want to access the configuration for the REST UI, we need to go to the configuration, then we need to go to the REST and all the exposed data that are available for your site are available here. It's the content, all the node content will be available through this URL and all the custom menu links, views and everything would be available here. So what we were trying to achieve with this project was we were trying to expose views, menus, other entities just through an endpoint from Drupal, symphony and a front-end framework. So there won't be any other things that would be bootstrapped just like Drupal does, which makes the templating engine quite heavy. So if you want to access the content, we need to have this REST UI enabled. So if I want to enable, say like, if I want to enable the user to be used as my endpoint, I just need to enable this UI. So the request methods that are being available through Drupal are get, post, delete and patch and the request format are also available here by the Drupal and we usually go for the JSON format because it's really light. And then the authentication that are being provided by Drupal is the basic authentication and the cookies. So if you do not need any authentication for your user, you just need to have your cookies available and a JSON format along with a get or post method you want. So if I enable here get and save this configuration, my endpoint for the user would be enabled for the site. So the user is already enabled here and you can edit all the configuration for the REST UI through this interface. So how we are accessing this data through symphony, I'll just show you. There is a configuration file of symphony. So just a basic understanding of how this works. We need to just have few configuration for the symphony architecture and basically the working, the accessibility of the workflow of symphony can be accessed through the routings available for the site. And inside this SRC folder is our actually work wherein this is a controller. We have a default controller and a Drupal controller and in this bundle we also have a Drupal bundle. So what we can have in our routing.yml is we can create as many bundles as we want. Like for node I have created a separate Drupal bundle inside which we have the node controllers, we have the menu controllers, we have taxonomies controllers and whatever you want for your site to be displayed. So it depends totally on your requirement. So I'm going to basically access a simple node controller that we have created here through symphony. So this is what the files look like. The basic things you want to have it to have a node controller here. Define the annotations where you want to access this through. Like for the Drupal endpoint we have your Drupal base URL and slash node and whatever JSON format or XML format you want to have. And for this we need to define the annotations according to the symphony framework. Then I have a function that gets the alias from the URL and it caches your data. Here we are getting the cache data and whenever we are having a response for the first time it's setting the data again. And for the next time whenever user is going to access the same URL it would be getting its data from the cache. So here we are checking that is the data already available in the cache or not and if it's already in the cache then we are simply rendering it through this function. So the rendering part or the endpoint that I have been provided from symphony is through the FOS bundle. This is a required bundle for your symphony site. So we can add a dependency to our ComposerJSON file for this and have it running for your site. So this is an important component for your symphony. And this is the basic basic file required for your Drupal site to render this data. So whenever we are hitting this URL let me copy this URL we are going to access the node of the Drupal that we have created. So there is already an existing content here. If I check for the content it's a normal node and if I want to if I want to access it through symphony I need to just have it as the URL or the annotation that I have mentioned in the symphony file and then when I access this data you can see that it is in the JSON format. You are getting all the request all the responses in the JSON format. So you can see that the request is successful. An idea of the node all the fields that you have passed. So this is giving you control of what all things that you want to have in your system. Next comes the slim architecture. This is the slim architecture. What we get started with is for the people who really want to have this setup in your site. You just need to have a slim install for your site. And it will give you architecture like this. So you need to just have few configurations here. So all the things would be running from your bootstrap files. So this is just an overview of few sites, few things that have been required by slim. So we will be having a container. We will be having a routes and we will be having some parameters here. So in the container basically all the functionalities or all the services you want to access is being mentioned here. And same with the dependencies and the parameters. So I won't go into much details for the slim here. And this is the Composer.JSN file that looks like for the slim. I don't have much dependencies on the Composer file. It's a really basic installation for a slim. So it's just having a guzzle dependency slim tweak and PSR4. So since we are already added the PSR4 dependency in our Composer file. So we are able to access the routings and the controllers. So in this SRC folder, I've just created a basic node controller and a simple function which directly hits the request to your client. I have added this client here to show you how it's working. But what you can do is add it as a parameter of your project and access it as a variable. And then when you try to access the same node through this, you will get a JSON response here. So let me quickly show you how does the response look like. So this is the slim architecture. This is the slim URL that I have been using from my server. And if I hit here, I will get a guzzle response from here. The response that I have already hit to access the data from the symphony. So what we are accessing here is the cache data. Not the direct response data from the Drupal database. So this is the cache data which actually improves the performance of your site. So people who are already familiar with Twix and already work with Twix must be knowing how this data are being sent to the Twix. So what is really happening here is we need not dig into the much details for this function. But what is happening is render is a function of Twix that Drupal already uses. And we are just passing the response and the template name along with the data we want to have for our site. So the, as usual since this is a PSR4 so we will be having the same structure as we have been following for Drupal. So here is the template folder and inside the template folder we can have all the Twix for a file for each component of the site. So if you want to have a Twix for your home page it would be different component, a page TPL, a node TPL, a menu TPL for your entities. So I have just added the CSS here only. So this is the Twix that basically looks like. So if you see here I have passed three data, the title body and the image of the node. So if you go to the Drupal and you edit this node you will find a title, a body field and an image field. So what I have segregated is I have just picked up the title, body and image and node is from the internal rendering part for Drupal and I have just sent only the data that I have with that is being required through the render function. So if I see the template I will just see the if you see here it is a node image it is a node title and it is a node body and here we have passed the image and the user itself can have the whole control over this architecture. And if you see this structure I just have a simple div here there is a h1 tag there is a image tag just the footer and the closing div. So what we have achieved here is a simple, a really plain and simple architecture for your site wherein you can really improve the performance of your site to a great extent. So that's it, thank you. Any questions? We can test it independently like for the Drupal component you can create your own test cases unit test is for the functionality of the REST APIs and then for the symphony you can have another different because it's totally an independent system right it's just interacting with the endpoint for the Drupal. If you really pass something hard coded for your test cases then it will surely run independently for all the layers. Any more questions? What does that mean? Sorry I'm not able to get your answer. In the demo that I showed it's working separately but for the architecture wherein you want to have multi-site like if you are having multi-sites and you want to utilize the same components for each of them then you can have a single layer and it will be used for each of the multi-sites there. I guess for this architecture the same team would be comfortable working for it. As I mentioned earlier also that we were not having the resources for Angular but if you are planning to go for a headless with Angular and if the team is a specialized for Angular you need to have a different documentation for them. But if it's a core PHP or Drupal base team then I don't think so that they would be requiring a different documentation for each. The plus point for this architecture is all the three things are working independently. It's on the preferences. If you want to have that framework you can replace it with the Slayman the Twix framework. As I mentioned that they had just a bunch of team of core PHP and they did not have people for other framework having hands on Angular or Node so they really preferred for renovating and using the same architecture as Drupal. Just focusing on the flashing things and separating it. Any more questions? Thank you. What's the time? Sorry. I just have this set for it. 26. Thank you.