 Oke, saya mulai. Selamat pagi, teman-teman. Selamat pagi. Selamat pagi. Nama saya Lora Bderizal, tetapi orang yang menolong saya, dan kalian bisa menolong saya, saya dari Indonesia, currently working for Sepulsa, take start up, so you can reach me in Drupal.org slash use slash L7Cosmos or github.com slash L7Cosmos. Today I'm going to talk about Kong as a gateway for your Drupal API. So before I talk specifically about Kong, first I will talk about Drupal. So before Drupal 8, many people trying to do a headless Drupal or decoupled Drupal, but there is no standard way, there is no best practice how you should do it, how you can do the headless Drupal or decoupled Drupal. And then in Drupal 8, there is one strategic initiative called Drupal 8 API first. So this is in Drupal 8, you can you have in the architecture level the Drupal 8 support how you can do the headless Drupal or decoupled Drupal. So making Drupal 8 API first means making the power and flexibility of the Drupal we love available over HTTP APIs. In so doing, Drupal will be able to power ambitious application from all kinds from behind the scenes system written in language like Python, PHP, Java or Gove to beautifully rendered experience using the latest front-end frameworks like React, Vue, and Ember. So if it speaks HTTP it should work with Drupal. So that's what the Drupal 8 API first initiative. And what has been done in this initiative? First thing is the RESTful Web Service is already in Drupal 8 core along with HAL JSON already in core 2 and also we have the JSON API, GraphQL O2 and CoachDB protocol in Contrib modules. The JSON API and O2 is already in stable version. JSON API provided by JSON API module, GraphQL provided by GraphQL module, O2 provided by simple O2 module and CoachDB protocol provided by Relax Web Service module. But there is still problematic in this initiative. One of them is about authentication. So Drupal 8 basically only support basic out and cookie authentication out of the box which only works well for the browser but not work well for application. So only really suitable for progressive couple use cases. The default expectation for front-end developers and native apps is O2 authentication. So imagine if we could decouple this authentication out of Drupal. So not only it can reduce the workload of the Drupal but it can also make the Drupal more flexible because you can use any authentication method. So we're not limited to basic out, cookie out, or O2 so whichever or whatever the authentication it should work with Drupal. This is where COM COM comes into the pictures. So anyone here ever heard about COM? So COM is an API gateway. That means it is a form of middleware between computing clients and your API based applications. So COM consistently extend the features of your APIs. Some of the popular features deployed through COM includes authentication, security, traffic control, serverless, analytics and monitoring and also request and respond transformation and logging. But why COM? There are also others API gateway. There are also many other API gateway. But why COM? Because first thing is COM is extensible. Basically you can create plug-in just you can create modules to extend Drupal. So you can extend COM with plug-in. It's also fast. Blessingly fast because COM is built on top of engine X. Open source and platform agnostic. I can even install COM on my local machine. It's also cloud native and it also have RESTful interface so you can configure COM through the RESTful HTTP. This is how COM looks like. This is how COM works. COM is basically reverse proxy. So once COM server running every client request will be made through COM before finally send to the upstream to the final API of your application. So before it reach your API COM will intercept the request and it can make additional functionalities to your APIs like authentication monitoring logging, security access control, caching rate limit, and serverless. So for authentication COM can protect your service with authentication layer like you can add basic O, key O O2 HMAKE authentication JWT and LDAP. So you can add all of this authentication to your APIs. And also you can protect your API with security like access control okay like access control you can also secure your API with cross origin resource sharing or chores so you can make request from browser you can also add dynamic SSL to your APIs you can also whitelist or blacklist IP address that can make request to your APIs and you can detect and block custom bot or client you can also manage total and restrict inbound and outbound API traffic you can also invoke the serverless function you can invoke, you can run Lua code because COM in Lua you can invoke Azure function you can invoke AWS lambda function and you can also invoke the open-wis actions for analytics and monitoring you can you can enhance your API so you can give analytics and monitoring to the third party service like Prometheus Zipkin, Datadog and Runscope you can also transform the request and response on the fly with COM and finally you can log the request and response with various transport like TCP, UDP HTTP file StatsD Syslog and Logly so you can use all of these features of COM out of the box meaning once you get COM running you can do it you can put in front of your Drupal API without you you don't have to do anything in Drupal so it will work out of the box but for as we can see COM also have authentication which overlap with Drupal because Drupal have its own authentication so this is this is where we trying to move or replace the Drupal authentication and we use the COM authentication so COM authentication this is more or less how we use COM authentication to replace Drupal most of this step is already done in Drupal modules I will describe briefly how the module how the module walk so the first step is we need to sync the consumer so COM authentication work around the consumer object the consumer object represent a consumer or a user of a service you can rely on COM as the primary database or you can make the consumer list with your database to keep consistency between COM and your existing primary data store so this consumer concept is similar to simple out module so you can treat the consumer as a client or application which consume your API so in this case we will map the consumer list the second option we will sync the consumer of the Drupal and consumer with the consumer of COM so the module Drupal.org slash project slash consumer this is the module which provide the consumers entity so we will map this entity with COM consumers basically is each time the consumer created, updated or deleted we will sync to COM using standard Drupal hooks and after we we keep the consumer sync between Drupal and COM we need to make the Drupal treat consumer as a user because Drupal rely heavily in current user which is a user but because consumer authenticate a consumer not a user so we need to make this consumer Drupal now and as a user so we need to exchange the account interface so it represent a consumer not represent a user and this consumer account basically base on the request headers set by COM so every time client make request COM will set request header and send it to the upstream to your API this is the headers that COM will send to your API the ex consumer ID ex consumer custom ID ex consumer username and ex anonymous so basically this consumer account will use these headers and only check these headers so there will be no process about the authentication about how the authentications it will only check these headers the next step in order to use COM authentication we need to set the reverse proxy because COM is reverse proxy we need to do this to avoid header spoofing because the consumer account base on the request header so we need to make sure that the HTTP headers is not spoof and we also need to set the IP address of the COM server so for example COM server is in localhost so you need to if you have more than one COM server you need to list all the IP address and then we need to register a service for authentication provider so Drupal can collect it and Drupal can use it this is where Drupal check the authentication if the request is suitable for this authentication as you can see this authentication provider first check if the request is from trusted proxy that's why in the review step we need to configure the reverse proxy setting so this is to ensure the request is originating from COM and not from other source and then we only check the headers if it has X consumer ID set by COM and if the request applies to this authentication provider we will authenticate the consumer to Drupal and this is how how this provider authenticate it it checks the X consumer custom ID so this is the consumer entity ID of the consumer in Drupal and we set we sync it to the COM with consumer custom ID so this is where we know that this consumer is the Drupal already access in Drupal then we only return the consumer account interface on a step before this consumer account is already constructed and injected using Drupal service and dependency injection so it should be very light and now at this point Drupal is authenticate already authenticate the consumer and treat it as a user so whenever Drupal current user call it will return the consumer account object so at this point the authentication from COM already successfully authenticate to Drupal but what about permission because Drupal access work around role based permission so the current user need to check current user can access or have certain permission now COM has access control plugin which you can you can assign group to a consumer you can also assign multiple groups to a consumer so this is the equivalent as a Drupal role so we can treat this COM group as a Drupal role and check if this consumer if this group have a certain action or it have certain permission so we can give them access so the COM access control plugin will set the request headers with X consumer groups this is where we we use it as the Drupal roles with the method get role once again it only check the request header so now at this point you have a consumer as a Drupal as a Drupal current user and this consumer also have permission so you can use it normally like a user but this time Drupal did not handle the authentication because the authentication already been done by COM so let the COM handle the authentication and Drupal just use it use the authentication okay so to summarize Drupal Drupal 8 with Drupal 8 API first you can it so easy to do helpless Drupal to do decouple Drupal or use Drupal as a web service and COM can act as a gateway for your Drupal API COM can enhance and extend your API with additional functionalities COM also provide authentication plugin which you can use to replace the authentication in Drupal because both have authentication so it's overlap so we use one over another so in in this talk we already talk about how to replace Drupal authentication with COM so COM can do that and with with the authentication of COM so we not only we can we use the Drupal workload but you can use any authentication method provide by COM to your Drupal so what's next so all of the step is already done in modules so you can you can use it you can modify it you can extend it so the module is like in Drupal.org slash project slash COM so the current current version is still in development so the first release is will be targeted at better integration, better consumer integration with COM so if you guys want to contribute contribution are welcome and we also have looks for possibility if we can integrate the COM administration right in Drupal so you can configure COM right in the Drupal administration also we look for the possibility if we can integrate Drupal routing with COM routing so you can you can try at drupal.org slash project slash COM okay that's all from me any questions yes except for authentication is there additional work is the API exactly the same does the frontend need to know anything about it yeah if you if you don't use the authentication so all the COM features is working out of the box so you don't have to do anything in Drupal so all you need to do is is get the COM running and you just find anything yeah no all you need to do is you configure COM so you COM can proxy to your API and then your API wouldn't you want have to change anything in your API no it will still be the same and how useful was performance so right now i use it in one project so it's very useful because we have project for third party so it's a service used by client or consumer so this is where COM useful because the consumer so this consumer we won't have to change anything in Drupal so we only configure it in COM so when any consumer change or what you won't have to do anything Drupal any other questions no that's all from me thank you good morning