 Good afternoon, everyone. I'm gonna get started. It's one o'clock sharp because after me. There's jibran who's presenting as well on the on another Core initiative My name is Wim. I'm one of the API first initiative Coordinators Mateo is the other one. Unfortunately, Mateo isn't here today. He is In a better he's in a better climate than this one. He's a Mallorca at home today. I think so I'll you'll have to do with me I'm sorry So the goal is to give you an update of where we are at where we are going And just to give everyone a good sense of how things are progressing Questions there will not be a whole lot of time because there's another session right after this one But you can come and find me or anybody else who works or helps out with the API first initiative if you have concrete questions That's all of course So the things will cover the vision the overarching goal Then translated to specific goals a roadmap of things that we are trying to get done as fast as possible the Ecosystem surrounding API first and then some outstanding challenges and open discussion as time allows So before we do that actually I have a quick questionnaire. We have I think well I'm relying on somebody else there who counts the number of people in the room, but Basically, I want to have a sense of how much how many of you are using which parts of API first and Who are just interested who have experience and whatnot. So who of you raise your hands have worked on the coupled Drupal projects in the past at all it seems like about 20 or so so That seems like about a fifth probably so interesting if yes, was it more than a year ago? about eight more than six months ago or Less than six months ago Seems all about the same interesting And the Drupal did the coupled aspect was it critical to the overall project like the decoupled part of the project? Was it essential or was it an add-on essential? Okay about 15 probably If you haven't worked with the coupled Drupal yet in the past who of you would like to interesting only 40% I guess so some of you are here just to hear what it's all about I guess Which is fine if you have been using the coupled Drupal. Were you using the core rest module or something else core rests? It seems most of you By 20 I guess Were you using the contrapped rest UI module to configure it to set it up? Who is used core rest UI? Oh, sorry the contrapped module rest UI. It seems like only a handful of you know about that module Did you not use did the core rest API noticeably improved in the past year or so in your experience if you've worked with it Did it get better? No hands, that's pretty sad Well, okay, thank you I guess So that should have been this and have you used json API or have you used json API instead of core rest? Okay, so about 15 I think If you haven't used core rest and you haven't used json API have used graphql Three four five people Have you used relaxed web services couch to be two people three four, okay Or have you used a combination of all of the above basically just some json API some rest some graphql some relaxed one One two three people. Okay, so now that that's interesting, right? So we have some sense of what people are actually using so we offer you a lot of options And that is actually kind of the vision This is what Teresa stated in the past. He believes that it's important to have web services be first class in Drupal So that Drupal has top-notch support for APIs and people are Able to use them really well really easily with great DX and whatnot so API first is about being able to access your data Your configuration and whatnot via APIs Very easily so the overarching vision is for us to have an Unparalleled API first platform the point is any data that Drupal stores manages You can retrieve restfully in any format So the json format that Drupal core ships with the XML format that Drupal core ships with But also to help plus json format that is an optional module in Drupal core But then also not just have pure Representations of data stored in Drupal, but also have it available in multiple flavors Drupal core rest doesn't in the HTTP purest way But there's also the json API spec, which is also restful, but as a particular set of conventions Both of those are restful, but there's also non restful ways of interacting with data examples our graph QL And card to be but then card to be specifically for a narrow use case offline first replication and syncing and All of this should be available using any authentication mechanism basic earth cookie or else to whatever the future brings And so if we get to this point then you can point any SDK any tool at Drupal and How easily interact with it get data out get data in Which would make it a great connector a great hub for everything to be working together so that is kind of the whole goal and Increasingly we are seeing that people not just want this but need us We have seen a lot of sessions about it a triple-com Baltimore. There were 12 sessions one training I haven't checked actually for this triple-com. There was an entire event just for a decoupled triple So it seems the need is strongly increasing The goals that we have We try to take those this overarching vision and translate into must have should have could have because you need to Start somewhere, right? So the first thing was drool play chip with the rest API, but it wasn't very usable. So that was the first The first thing to get done then of course we want to go further We want to make it best in class and we want to have excellent documentation So those are the must-haves and happy to say that it is actually usable now we're making good progress on making it best in class and documentation automatically generated for your content types for entity types That is also proceeding pretty well Should have Jason API. We would love to see that Be used far more because it solves certain problems that the core rest module has For example, you have collection querying filtering sorting and so on which triple core as dozens So that's also a very important one. Well, glad to say that there's also a stable module for that mostly thanks to Mateo and Daniel who's in the back and looking at his phone and not hearing this And also many other contributors, of course GraphQL is also shaping up really well and they're about to release a first stable version So if you haven't tried that in the past because it hasn't had a stable release yet. Well, it's about to get one There's a workflows initiative with which the person who is making a photo over there now is Working on a lot along with several people here in the front That is great and it enables new possibilities, but we also need to be able to do those things via API's so you ID support and core rest doesn't exist yet We should have that revision support doesn't exist in core rest nor Jason API. We should have that as well So there's more work to be done there That hasn't really started yet, but as you can see quite a few things are taking shape Things that we should have or at this point could have was to support that is also progressing really well couch DB sports. I was just talking to Dixon here at the front About that module turns out that is just at the beginning of September It has had its first beta release at they're using it in production So couch to be support if you want to use that relax web services module in contrip It's also getting to a really good good place So if we compare that with six months ago, there's quite a bit more weightlifting going on as in progress being made One another another goal reached and so on so we are making good progress So hopefully this gives you a sense of where we were where we are today So why these things well for core rest the reason we have that is it supports multiple formats Sometimes you want to have a format specific for your needs. It supports any kind of data so it can be used for non entity data basically and it's super configurable which is great in some use cases and Kind of juxtaposed with that is Jason API, which doesn't support multiple formats Which is not very or not as configurable, but it makes your life a whole lot more easier It doesn't require extensive configuration and so on so because it is opinionated. You can have better tooling You can avoid bike shedding and researching various competing Potential tools it just answers those things because it has an agreed setup and agreed upon set of decisions basically Collection support as I mentioned is something that rest doesn't have so Jason API is is a very very easy to use module in comparison to rest API Graphql is At this point really the thing you mostly use for UI components that then fetch their data and just the data that they need Which is harder to achieve with core rest and Jason API and rest is already in core It's in stable core Jason API is currently stable in contrib We're working on maturing it in 8.4 contrib and hopefully we're going to get it into triple 8.5 core Which would make your lives a whole lot easier Graphql is About to be released as a stable module. I haven't checked today's Twitter feed, but I think it's going to happen any day now So these are rest API Jason API graphql These are all modules to interact with data But the problem also is that sometimes it's hard to figure out how to do that interaction documentation is often missing And that's why we have open API. We're working on getting that to a stable place in 8.4 contrib So the point is that starting was very painful like a year ago because documentation was lacking Things were brittle. Well rest is much more stable now Jason API is stable Documentation via open API which works for both the rest and Jason API So this works for both this and this Well that will make things a whole lot easier So hopefully that gives you a sense of why we are working on specific things If you then look at what we are currently working on what our current focus is to to go to the next level kind of Rest API we're working to make it best in class. What is actually missing right now is translation support So you it's it's somewhat possible But it's not fully supported yet to retrieve for example a Dutch or French or German translation of a node But you can you definitely cannot patch it post it so you can't modify it Modifying configuration is impossible configuration entities. You can retrieve it retrieve them, but you can't modify them File uploads are not supported And the thing is because Jason API builds upon this infrastructure that core provides the same Gaps translations config modification and file uploads are also not yet supported in Jason API Obviously, these are pretty important. So we are working to add them to core and then Jason API will benefit as well We are working on them, but it requires it takes time because we need to Expand APIs in Drupal core in the subsystems that all of this builds upon so everything needs to support it in order for the rest APIs to support this For Jason API the key thing that is missing besides the things that are already in rest is comprehensive test coverage, which To be fair rest didn't have at first either at this point It is almost at a hundred percent coverage in the sense that all entity types have a very solid set of test coverage So that we know that we break things if we do For Jason API, we still need to do that But because core already paved the path it should be much much faster for Jason API and that will help it get into core craftql What is missing there is more sites using it more feedback. Amazie is using it in production They're using it very productively. They're using it to well. They're very satisfied But we need more people and with more different use cases to also use it and give feedback and so on of course The next one is excellent documentation via open API as I mentioned before the interesting thing is that just six months ago There was competition. We didn't have a clear path forward It was the rest API doc module from a year and a half ago the skimata module the docs on a module and the open API Module and then I think a few more sandboxes So there was no clear Consensus on how to move forward at this point there is so we are standardizing on the open API module Which is also a spec that we didn't invent so it also integrates with other tools So rest API Further gaps being addressed Jason API the same gaps plus tests Graphql also being stabilized an open API getting to a point where it is actually working for all these cases Of course that is a lot of work to get all of these things moving forward and yet more like UID revision support couch to be supporting core and whatnot So we would love to see more help and the good news is that Acre is hiring more people to help out specifically with API first triple. So if you are interested in that Let us know The people working on all these things so core rest Relaxed web services and so on but specifically the things that we've been working on so far Mateo easy easy row ipso and I are the initiative co-ordinators and we are working on various parts Daniel is also working very much on the rest and serialization and Jason API So pretty much all over as we know Daniel to be on over all the things that bowman is working an open API But also core rest and serialization and Damian cloyd Damian Lee is also helping out with serialization arrest so if you are specifically seeing problems with any of these areas or you have feedback or you have a feature request or You don't want to help out and you don't know where to get started come talk to these specific people In IRC you can find all of us The ecosystem so what we talked about so far was the overall vision like Drupal should be able to support all of these things But there's also tooling being built around it to make it easier to get started Some of the tooling is waterwheel It's a it's a library to make a javascript library to make it easier to start talking to Drupal core rest and to Drupal's Jason API to take away some of the The Drupalisms to make it easier to get started and to make requests in just the right way and so on Distributions distributions to make it a whole lot easier to get started content is the short version is content up is a massive productivity boost if you want to build if you are familiar with Drupal and you Want to build a decoupled Drupal site? It has example apps for various JavaScript libraries Makes it very easy to get a sense of how that works that specific library that specific SDK being integrated with Drupal Reservoir is specifically targeted at non Drupalists It aims for simplicity so it has as far less feature complete feature rich than content I choose is to focus on simpler things It's a different audience probably for you guys most of you would be best to use content I would say give it a try play with the example apps Get a sense of what you can do Those are the key ecosystem things waterwheel content a reservoir but outstanding challenges things we haven't even really begun to tackle or Don't know really how to begin to tackle or just because we haven't gotten to it yet Things like image styles for responsive images should should they be embedded in responses or not There are some reasons to do it one way some reasons to do it another way If you have entities and you're patching or creating entities Things like validation error responses How do you expose that properly on the client side when you do that patch or post request and how to present that? You need to get enough metadata in order to be able to represent that clearly That's also not yet in a good place Drupal core Is not yet using any of the rest API so it's only you guys using it essentially at this point So ideally Drupal core would be using it and the scariest of them all API versioning which nobody has solved yet Not in Drupal not outside Drupal not anywhere So how do we solve that for Drupal where any side builder can add new field types and can change a single value to a Multi-value field and so on that's stuff of nightmares unfortunately So yeah, that's I hope that's a that gives you a good sense of where things are at where things are going We're working on and I talked fast. I'm sorry, but I wanted to leave some time for questions or discussion. So Any questions any feedback any concerns any frustrations or maybe everyone is here for the next talk This is a question maybe just for you way more baby people in the room How do you feel progress over time has been are we moving too fast too slow just at the right pace or doing to me to move even faster It can use be a little bit more specific in what sense for a core rest the overall API first stuff I think Drupal as a project the overall API first stuff. Okay I Think interestingly enough quite a few things are are moving forward really fast Simultaneously like graph QL is moving forward Jason API is moving for it all of this moving forward Coach to be support is moving forward. So a lot of things are moving forward quite nicely To me personally I'm working on core rest and trying to get that to move to a really good place and Jason API to a really good place Which requires fixing a lot of sub system edge cases that weren't taken to account when those subsystems were first built And I wish those things were going faster because it takes a lot of time and effort back and forth consensus building and so on So that part I wish could go faster I'm not sure it can because that's the thing about open source and consensus building If I think something is ready Oh, but apparently then Andre thinks of something that I hadn't thought of and then we should fix that and then Daniel Thinks of something and that's the thing about Drupal lots of people come together and think of additional edge cases Which makes the whole much better much more reliable more robust But it makes more takes more time Everything was crystal clear or really everybody came for G brown stock Daniel, I have a really simple question. How do we talk food? I mean you said we should talk food Yeah, how do we talk food? I think you had a really great idea a few weeks ago Where you said it would be interesting if as soon as you install the core rest module We would change for example the the node form to not call PHP code But do an arrest request internally to save the node and then if the validation error So that was one of the things that we don't really Have in a great place the error responses in case of a validation error Like if that were being docked that and you would get a validation error that would have to continue to work The same way so we would have to fix this and we would know when it would break so that could be an interesting interesting way to do it or Other UIs like layout builder stuff that is being worked on and so on for example so It's obvious to me maybe not to anybody else that the core rest API was not designed At least initially to be used to build like a decoupled website. Mm-hmm. Just the structure of responses and whatever else and Jason API getting more stable is do you see a future where we deprecate core rest API and that is replaced with something like Jason API um, I Would like the answer to be yes because Jason API is like there's fewer things that are Configurable therefore fewer edge cases therefore it is more stable The problem is though that Jason API only supports entities and so some I actually am surprised myself But quite a few people are using are creating custom rest resources to generate a specific XML response that They need to integrate with some external system that is apparently a thing and it like that's fine and it makes sense, but so it's it's I Think we would maybe deprecate the rest API or the core rest module for entity use cases As soon as we have Jason API in core because it is just far more pleasant to work with you Don't have to create a rest export view to be able to list all comments for a node. For example, you can just Make a request with a specific query string in the URL and then you can get just that data so I would say Fabe we would probably recommend Jason API over rest for certain use cases and Matt is asking is there any timeline for that? Well, it depends on when Jason API is in core. Hopefully eight five No firm timeline as is the case in open source Related to that. I think I think we can do a lot better job as As kind of a decoupled community if you made to like put together resources and document all those different use cases help users to really understand like Use content up for that or use Jason just Jason API or Relaxed web services for this and that and like have a comprehensive. Yeah is to really guide you I think because there's So much activity and there's so much progress Everywhere, I think we've become a lot better Collaborating over the past six six nine months. Yeah, and it's come some really good stuff out of that But I think you can do much better job. That's sort of guiding. Yeah I think that's kind of the the task I don't want to put words in the market the content of people who are present But I think that's kind of the the call of content to to show how to do it And what is the current best practice and if something is no longer the best practice? I'm assuming content. I will Evolve towards the better practice, but that's the best practice for a particular use case They where you have like the traditional doesn't do much with offline First or it doesn't do much where you decoupled to Drupal sites and you want to So maybe you should write some blog post about HDB so you just proposed to get more work yourself Another question so you list like image styles and stuff Do you have any idea about the vision support? Like do you think it's important for the couple application? I think I think also we'll have some thoughts about that and It's important for different use cases, I think When you like decoupled to Drupal sites or two systems not necessarily a browser front end and a back end Then certainly you need revision support. That's also form of decoupling, right? We shouldn't have this There are many use cases so I think It's a good feature, but it's also like exposing that and working on that in Through our API, so it also fix a lot of stuff in core. Yeah, like it's one of those things to where we know Then we've discovered that throughout the workflow initiative, you know We have to fix all these things and exposing revisions and giving people the opportunity would then uncover and just fix a lot of good stuff and then whether or not you want to expose revisions on your Published site. I think there was some good points raised there by the content team in their presentation Probably not a good idea, but that's one use case, right? Yeah, I guess the answer would be it depends Maybe thanks for the good summary on API's first initiative. I have two questions one is very short given that Headless CMS is so popular. I've seen in Dree's presentation that it grows 500% year-on-year Why this room so small? That's an interesting question and more interesting that perhaps is that these numbers are Like only about 20% of the people in the room actually have worked on the couple projects if everybody was awake and raised their hands Of course, but I'm assuming that is the case Yeah, I don't know Yeah, it's impressive Your second question Okay so According to the Dree's presentation this morning, it looks like we are targeting to decouple the admins of interface of Drupal Is that that mean that we're gonna have to Navigate differently in the future. Oh, you mean UI wise navigate differently. No, sorry I think this initiative is is it positioning ourselves in the right direction towards that or yeah, okay So the question is basically is this initiative helping to make that possible at all? Yeah, I think that's where you're getting at Yeah, or I mean are we going to depend on what framework we choose or are we gonna have to do something? Oh, well, this this is basically just making that a possibility. So this is making such decoupled admin interface as possible It's also making things like content are possible React front ends possible like it's making all of those things possible without good APIs to get the data out of Drupal and get Data into Drupal you can't do any of it, right? So I would say yes, this is a necessary step along the way, but this is not Specifically to enable that this is to enable a lot of things that otherwise are not possible or just are very painful to do This should make it so that it's painless Maybe so delightful to get to interact with Drupal. Okay, so hopefully when we get to that point We'll be ready to yes. Yeah. Yeah, I think I should represent It up and maybe there's one more you remember your question The question was It's more general okay Drupal, but given that you are so involved in in this initiative You know and the popularity of API first size It's not only that we are making Drupal and more and more able to work Headless it's it feels sometimes like that. We are be heading Which may be a good thing, but I would like to hear your views on that. How does it feel be heading? Wow, okay, I'm not sure if how I should feel about that to be honest I Don't okay, so I would say that I'm not be heading Drupal I would say I'm turning Drupal into a multi-legged and multi armed thing So you can do more things an octopus kind of I don't know but Yeah, okay, that's perfect I'm giving Drupal more heads as in the ability to grow more heads Yeah, indeed, thank you