 Hi everyone, this is Swati. I work with Accenture as an associate manager and have been working with Drupal since Drupal 6. So yeah, since quite some time. So today I will be presenting how we implemented a decoupled Drupal for one of our government clients. So yeah, let's start. So JSON API module really lists at the foundation level for any decoupled environment where we are using JSON API as a specification. So yeah, so this is once you enable the JSON API module, you get the REST API for all the entities and bundles which you have in your system. But really JSON API is a no configuration module. So once you enable it, you really cannot configure anything. So we have a very useful add-on module called JSON API extra which provides an interface where we can override JSON API module where it has configurations like we can rename a module, rename a resource path, change the resource name. We can exclude few fields from any resource type and a set of default enhancers which we can apply for our fields to customize and enhance the output for our JSON API. So now let's see what in real-world scenario, we have to do what on top of these two modules to really make this decoupled environment work. So in JSON API, everything is a resource and each resource is connected to another resource in form of relationships. So let's take an example to understand it more. So for example, we have a content type called article which have some basic fields like ID and title. On top of that, it has some entity references with a tag name associated with an article, an image associated with an article, and some paragraph called related books which then references to another content type call book. So this is a general structure which we have for any content type. So now if our front-end application or any other application tries to access a content type article, the resource page for a content type article, they will be getting the basic information for an article. They will be getting ID, they will be getting the title, but they will not be getting the information of the relationships which will be added to that resource type. It will be saying that it has a relationship, but the tag name will not be provided, the image URL will not be provided. So but our front-end application really needs a flat response where if they are trying to access one article resource page, they should get all the information which is related to that particular resource type. They don't really have to iterate deliberately go inside each and every resource to get the response of each and every these resource types. To do that, we have a module called JSON API default. So once you enable that module, it provides a block in the JSON API interface where we can add these relationships. So here what we are saying is we need to include these information of these relationships in our resource type. So I want the information for my tags, I want the information for my article image, and then I want to add information for my paragraph collection of books. Awesome, right? But the catch here is if, for example, we have a nested kind of a relationship where we have a content type called article which is referencing to a paragraph collection of books, and then it is in again, referencing to another entity reference content type book. So it is a nested kind of a relationship where even if we add collection of books paragraph in the relationship, it will not be still providing the information of book name. To do that, we have to deepen inside the relationship and go a step further and say, we need the information of a paragraph, then dot and go inside deeper and say, okay, we also need the information of that book. Similarly, if you then need the relationship book image, which is a separate relationship for a book, you have to go deeper inside and say, okay, I need related books, dot field book and that field book image. This is how we go inside and get the information for all the relationships which we have in the system. So once we do that, we have this compile response for all the relationships which we have, and we have this one flag response for RSO style. So now we have all the fields which we want for our system which is there, but we have these scenarios and situations where we need something which is really not there, which is a computed information. Something which we need to send to our JSON response which is not available or really computed. So how can we do that? How can we send something computed in our JSON response? So to do that, we have a hook call entity-basefill-info-alter. So here, I am adding a field called sticky because I'm probably sending some more sticky information with my content, and then I'm using my class of plug-in field type, which is my custom field, which is responsible for evaluating and providing the value of my field. So here, I'm just sending a simple string, saying custom computed field value. This is a value which my class will be processing. So once I do that, you will see that my field sticky, which I created here, will be added in my JSON response, and with the value which I have set here, will also be added to my custom response. This is how we have been adding some of the custom computed values, which needs to be added for JSON response. Now we have all the resources, we have everything which is ready, but there's one thing else which really is needed sometimes, which is how to enhance any existing field. So we have these scenarios where we have to enhance the output of an existing field in JSON API response. We can do that by adding a custom field enhancer, which can be added in this namespace of plug-in JSON API field enhancer. So here I'm creating my custom sticky enhancer, for that we have to extend a class called resource field enhancer base, which is an abstract class provided by JSON API extra module. So there's a dependency if you are adding any field enhancer, right? So here I'm adding my custom that is a label which is added and then we have to override two methods, do one, do transform and do transform methods. These two methods are responsible for providing what enhancer we're doing once it is applied on any field, right? So do one, do transform is a method which is responsible that once you are applying an enhancer, what needs to be done. So here I'm just changing the value of my field to something custom, right? So I will be applying that, so my field was still sticky, I will be applying that to my enhancer. So once I add my field enhancer, this is a list of all the default enhancers which are present in our system. Once we enable JSON API extra module and my enhancer which I added here, adding some more info to sticky is added here along with the other enhancers which is added. So once I add that, I'm applying it to field sticky and once I applied that, my value is now changed to the new string value which I computed here. And if I try to, if I remove the enhancer, it will be reverted back to the original value which was said there, which was like on a custom computed field value and that needs to be implemented in the method, do transform. I know the names are a little mixed up but this is how it works. So this is how we can implement any default enhancer and apply on top of our fields to enhance the output for any fill in JSON API response. Great, so once we have the set of data ready, the next and very important concept in JSON API is that we have to expose our images as it will be accessed by different platform, different channels, we need to provide images to different platforms. So we will be uploading images at CMS level and these image styles will then be used across by different platforms. So how can we actually add these image styles in a JSON API response and expose to any other application? So for doing that, we have two modules called consumer and consumer image style. So here I'm registering a default consumer which is using two image styles, medium and thumbnail. So now what will happen is all my resources will be using and will be exposed in these two image styles, right? But if there is a requirement that at a field level, we want to modify it, we want to customize it, we can do that. So from the list of enhancers, once I enable this module, consumer image style, a new field enhancer is added which is called image style. So it can be used to reduce or refine the image styles that can be applied at a image or at a field level. The catch here is even if there is a large image style, you cannot select it because at the consumer level, you have not added it. So you cannot increase the number of image styles at a field level. However, you can refine and reduce the number of image styles at a field level, right? So this is how we can add image style for our images in JSON API response and this will be the output which we get, right? So now we have everything which is needed for exposing and setting up our JSON response, but last one of these, how our frontend application will actually be using this JSON API response. Frontend application really uses URL aliases rather than any other NID or any other UID for accessing our application. So we have this module called decoupled router which sits between our decoupled frontend and decoupled drupal and this is the one endpoint which our frontend will be accessing. So it will always be accessing this translate path API and talking between both of them. So for example, my frontend wants and requests for about us page. It will be going through my decoupled router. It will be processing the response and sending it back the endpoint response for my frontend to use and access it, right? So it simplifies the process and now the workload is shifted from our frontend. So everything is streamlined, right? So these are some of the building blocks which we can set up and the ecosystem for JSON API is increasing day by day which is really great. So you can explore their new set of modules which you should see and it is great to explore them. So yeah, so this is what I want to share for decoupled drupal environment. So yeah, thanks for listening to me and let me know if you have any questions. You can reach me at swathi.e.garretacenture.com. So yeah.