 So thank you for coming. This is the API First Initiative Core Conversation. And I'm stressing that it's a conversation, not a presentation so at the end, please come up to the stage and ask questions through the room, right? I can't say this. So as I say here in Ireland, Kedmila Fauca, welcome to our core conversation. And I'm going to let Mateo introduce myself. Well, I'm Mateo. I work for Lullabot. I like APIs, probably a bit too much for being a piece of software. But yeah, I've been doing this for a while now, and this is kind of what I do. Also, it says that I like to be under the sun, which is true. I'm Preston. I work for Aquia, and my bio is twice as long as Mateo's. Yeah, I know. So here's what we're going to cover today. Vision and goals of the initiative, roadmap and background, a little bit about what this is all about, some outstanding challenges that we're still facing, a little bit of an epilogue about where we might want to take this forward, and then, of course, open discussion. Yeah, so this idea of the API First Initiative kind of started in New Orleans. In there, in this keynote, he said something on the lines of that he believed that we should have a first-in-class API system. So we could build really good APIs to create good experiences. And in a way, we were trying to empower the application builders to build them in a way that they are API First. Like, they build first the API, and then they define the other parts. So what this translated in our minds is that we kind of needed to make all data available in a RESTful manner. We already have in core the JSON format and HAL JSON, an implementation of HAL JSON. There is a control module that's JSON API that does that in a slightly different manner. And also in relation to those RESTful web services, we kind of want to have authentication providers. How do we authenticate the data in core? Right now, we have basic and cookie-auth. So all that, also export all data or make all data available through non-RESTful ways, like GraphQL. There are others, but GraphQL seems to be the favorite. And we already have to promote it for that, so that's great. Finally, another thing that has been a theme in the API land with Drupal is the replication of data, relaxed, does that really well, and uses, implements the CouchDB replication protocol that allows the Drupal site to move data from Drupal to a CouchDB store. So the first thing that we had to do, we as in a community, had to do is to define the things that we have to get first, the priorities that we have to achieve. And we have kind of categorized the things that we need that may happen or needs to happen into these different categories so we can get to work. So the first thing that in the level of importance is to get the REST module in core work. And I'm glad to say that the first part, which is gathering all the feedback and knowing why people were sometimes displeased about the REST module, how can we fix that, right? So many issues were created. We fixed them, a lot of contributors that did that are in this room. And now we can move to next stage for REST core, which is having it be really great, right? So we are working on that already. I think that Drupal 8.2, 25% of the change records that are in there are for the REST module. So that kind of says something about the amount of work that was done. Another thing that's currently happening is the JSON API module that's going to be an experimental module maybe in the future. It's a specification that allows you to do some more advanced things that are typical pure REST implementation. It can be limited in a way. Similar to that, there's a GraphQL module, which is, as we said, not RESTful. But it really, really works very well when you combine it with things like Relay. I don't know if you were in the presentation today, but it feels like magic. It's like not even software. Some of the things that we will want to work on is having UUID support and revision support. The UUID support is kind of despair in the modules that we are working currently on. I think that GraphQL and RESTingCore don't have support, Relax, Web Services, and JSON API do have support for UUIDs. And we need to get every one of these modules to have support for UUIDs. When it comes for revisions, here Relax, Web Services is the best in the class. The best student. Of course, the other systems don't have yet support for revisions, and that's really important that we get it there. But this is work that has not yet been started. Also, when we talk about authentication, we are considering on going for OAuth token bears, bear tokens, or maybe JSON web tokens. This is like being a dog's person or a cat's person. I like the bear tokens, but if someone prefers JSON web tokens, please take the mic later. So why we need this is because there are a limited set of devices that can work well with cookies. Like we were seeing the other day, probably these Volefond kiosks don't do that great with cookies. Your iPhones also don't do that great with cookies and all that. And basic authentication is like sending cash over the wire. If someone takes it, they can access your Drupal site just like if they were you. Like it's their credentials from demo. So we need something to deal with authentication. And finally, we want to implement, as we said, the replication protocol that CacheDB defines. That's a good protocol. And for replication purposes, it works perfectly. So we may want to have that too. All right, so just to talk just a little bit about roadmap and background. Why are we doing this in the first place? And just to give you some information about the initiative, the coordinator is Lynn Lears who just got married. Congratulations to him. And we also have a lot of sub-coordinators who have been leading the initiative as well. So as you can see, it's very much a team effort and a lot of people are working very hard to make this a reality. We also have a roadmap in place as well. So as you saw in some of the must have, should have, could have features that Matteo just outlined, we also have an agenda to get a lot of this stuff implemented in time for 8.3 and in time for beyond 8.3 as well. Making rest best in class is gonna be something that continues over a long period of time. It's very unclear where that sort of optimum level of best in class, rest support really lies. But at the same time, we're gonna make sure to really move a lot of things forward as well, including UID and revision support, putting JSON API as an experimental module and core, which I would love to see. And then also eventually bringing it into a core as a full module. We're also looking at, you know, making sure that GraphQL is stable and contrib and eventually inviting GraphQL, the work of Fubi as a experimental module as well. And also different forms of authentication, given that our current forms of rest authentication are not ideal for security. And finally, we do wanna make sure to focus on things like config entity rest, config entity right support, which is something that doesn't exist right now, as well as better rest collections. And you can see in the middle that we're hoping to have a lot of this at least somewhat complete or in a good spot by DrupalCon Baltimore next year. One note I do wanna make is that, alongside the API First Initiative, we also have work in the community around a project separate from Drupal called Waterwheel, which are SDKs on the front end that help you actually build applications very quickly based on JavaScript and Swift. So you can build Drupal backed applications in these technologies very quickly with the help of these libraries. And that's the work primarily of Matt Grill and Ted Bowman who are here in the room. So that's Waterwheel. If you'd like to check it out, please do. And we'd love to hear feedback and have more contributions, especially if you're gonna make an integration with like relaxed or other modules, it'd be awesome. Outstanding challenges. So some things that we don't necessarily have a fine solution, but we know that our problem are things that we can come up with a solution as a community and we can have all of the projects benefit from them at the same time. So I kind of want to take the opportunity to present these problems and maybe have your beautiful brains a spark solution for that, but don't feel the pressure. So the first thing is how do we want to version our APIs? Because if you have an API that serves different consumers and every consumer is released in a different release cycle, it's released at a different time, you want that API to be frozen in a version. So when you update your API for this latest and greatest consumer, don't break the older ones, which are also important. So the problem that we're having in Drupal is that when you may maybe delete a field, you also delete the data. So all the consumers lose the data in that field, even if we somehow found the way to retain the schema for that field. So that's one problem. Another problem is that in fully decoupled applications, you don't want to encode any presentation logic in the server and we kind of do that when we declare image styles, right? We store in the server how the image is gonna look like and that is something that we kind of want to reverse the process and have the clients request the aspect ratios and maybe the superimposed text or whatever that we do with image styles, request it to the server and then the server comes back with whatever they ask. We want to do this in a way that is performant and we don't kill our site because we request so much of GD or image magic. Also, we should probably think about how can we keep up to date and keep healthy in the ever-changing state of the decoupled world because Duple is gonna be treated as a server but we can see how JSON API and GraphQL got super popular lately. What if something comes up in let's say a year that gets super popular? Maybe just creating an experimental module and putting that in core is a good solution, maybe not but that does not have a clear solution right now. Multilingual support is also kind of unclear. There are some standards and specifications on how you should do that. It seems that the agreement at this moment goes on using multi-part responses if you don't specify a specific language that you want your data in but the problem is that the symphony components that we use still don't support this kind of responses and many of the, to be honest, many of the clients that we are used to build, they don't parse these responses so well so maybe another solution can be a deal in this area. I'm pretty sure that there are other challenges that are open and they are common to all of the different systems that we're talking about and please go on to a stage and present those. All right, so before we get into some discussion I just want to mention one of the things that I think is very useful about having this conversation with all of you is that part of what makes API first best in class, part of what makes this idea of API first really powerful is to be able to dog food it which means we should be consuming our own APIs, utilizing our own APIs, employing our own APIs not just within our fully decoupled environments but also potentially within Drupal itself. There's a lot of areas where Drupal UIs and Drupal user experiences in general could benefit from these API first tools namely these web services, namely outside in potentially, a lot of these improvements that we're making to configuration entity crud will actually benefit the ability to do things like administrative interfaces or block placement for instance in preview configuration of your Drupal site in a way that uses REST as opposed to using let's say AJAX in the traditional sense. There's also a lot of things that are happening in the community which are very compelling namely there's been a module made by Matt Davis called decoupled blocks which is a way to actually make progressive decoupling a very formalized and systematic way of doing things in your Drupal site so that you can have JavaScript components interpolated into your site and manage them as a site builder would. Those sort of AJAX interactions the sort of dynamic interactions that we have a lot of in terms of the admin UI would also potentially benefit from things like this. And I'd love to also hear about other dog food and use cases what sorts of places can we use this kind of work and really make sure that we're not just building these APIs and these web services for kind of an avoid. That's the thing that we wanna avoid no pun intended but just to mention very quickly there's a lot of flavors of decoupled Drupal. We have progressive decoupling which I just mentioned we have full decoupling and we wanna make sure that this API first initiative is optimized for both of those use cases meaning not just your JavaScript applications that are built inside your Drupal site that you interpolate into your site but also your single page applications that you might be building in other frameworks like Elm or MythRoll or what have you. I wanna recognize all of the contributors. All the people on this list have done amazing things for the initiative and if you are in this room I would like you to please stand so we can give you a round of applause. Come on Ted. Alrighty, so thank you very much and we're gonna go ahead and open it up for some discussion and as Mateo said we'd love to hear from your beautiful brains up here on this mic. We've turned the mic around so that we can have a discussion kind of back and forth as opposed to just with us. That's not what we wanna have. So yeah, let's get started. Arv Magov. Daniel, I mean it's not like a really big thought or anything. I was just wondering whether we could dock food in our tests OS API. So instead of using the UI to create nodes and then check stuff maybe use West API or whatever to create our stuff because it would automatically cover like the simple use case of creating a node but then also creating node revisions and translations and I don't know conflict translation enabled and everything. So maybe that gives us a good test coverage. You wanna have any thoughts on that Ted? So Ted, so one thing we had a problem with the outside in settings tray. At first we wanted to use the rest API to update blocks instead of using the regular to submit. But first you can't validate config entities which that's on the way and that's a feel like that's a solvable problem. But the next thing is like what will we do for the form and form validation? If we, because plugins can declare a configuration form and then that would have validation. So we were sort of thinking that even if we solve that config at any update we didn't really know how to solve the problem with the form. So if anybody has ideas on that, do you have ideas? Well, anyways, so because to the idea of like dogfooding our stuff, it would be great if we could in a lot of cases use use the ability to like create a form and update via rest but that requires like validation also requires us being able to somehow figure out basically like we're getting the form API array and we can't really make a form from that. So I don't know if that's something we just can't do so that would mean we can't like make a real admin interface except like you make admin content interface but not configuration interface. So if anybody has ideas on that, that's something we've kind of just kicked down the road for now, but it would be great to solve it. If you say that configuration entities are being going to be validated, validable, then just like in Drupal 7, you had this problem with form validations developers will need to move the validations from the forms, the configuration forms to the configuration entities. So of course it will take some times because it was late, but this will solve it. Yeah. We'll bring up another topic. So I think one problem of why we cannot dog food at the moment is that we don't enable rest API by default or we don't expose everything by default. So like I know that, how it's called inline editing. For example, doesn't use rest area either because we don't, I mean, we have the API available but we just don't enable it by default. So I was wondering whether we should enable like rest API or something by default and maybe even for every entity type in like standard or something. I'd love to see that. I mean, I think that would be a great way to position Drupal as that sort of API first. You can do, you can use Drupal out of the box as a rest API, which I think is a very important thing. In WordPress, for example, you have to install a plug. Oh, is it part of WordPress core? No? I think it's still a plug-in, yeah. In any case, I believe that kind of gathering all of these dog fooding cases and examples will help to know or at least to trim down to exactly what we want to enable. Like we want to enable the rest API but also we want to toggle it on for this and these entities or in these cases or all that. It's one more interesting thing in the first API that you need to switch off the front end somehow and you still need the backend like people some will be doing the administration but it should be easy to switch off everything that would be the normal endpoints on the front end which is surprisingly complicated to do. It was in Drupal 7, I haven't tried, so. And just a reminder when you go up to the mic if you could just say your name so we know who you are. Hi, Sander. I was just wondering, do you see the future of Drupal as of having Drupal core as kind of like API things and then we have a separate front end project that does the admin for side builders. It's just kind of like WordPress. with Calypso and that kind of stuff and they have desktop apps. Do you see that we can go there or not? And so Sander just opened up the doors box here. Well, I can tell you my personal opinion and that is we just had a buff that just concluded about this topic. Personally, I believe that we should explore and think about whether Drupal 9 should potentially be something that's decoupled out of the box. But the thing is one of the most important concerns obviously is that Drupal continues to be important and valuable for site builders and content editors who need to have that user experience as well. So we would need to make sure to provide that additional, if we do have a decoupled Drupal out of the box or backend core for lack of a better term, then you would want to also have a corresponding front end experience. But Mateo, do you have any thoughts on this? Sure, yeah. So if you attended Angie Byron's presentation, she gave some examples on other CMSs, what they're doing and how they operate and the features that we may want to implement. None of those really were decoupled CMSs with a decoupled backend or a backend core and a front end core. There was one which is Contentful, which was a decoupled backend that used JSON API. And the thing is that the idea of CMS is very powerful if you combine it with flexible templates and allowing the users of the CMS to configure their stuff manually and doing that in a decoupled way, it may be even more complex than doing it the way that we do it. So I think that yes, it's doable, but we may want to think about this in a sustainable way in terms of community and the work that it requires. Hi, Emmanuel here. Just a suggestion I have is, I mean, we could probably experiment having some kind of like a decoupled installed profile, whereby you have, I mean, those two experiences, the one for the regular person, and then if you want the option of having it decoupled, you just choose the decoupled installed profile and you move that way, it's just a top. I think that would be a good idea. Part of what that would require is a lot of modules to be the same. I mean, that's a lot of, I like that idea. Sorry. Sorry. Yeah, concerning that, what Emmanuel said, we could have the theming engine, which now is trig, a way to decouple that, a way to make the theming engine a separate component, a separate module, and then the decoupled installation profile could just disable that. Yeah, I think that's a very good point. Actually, in the, you know, Fubi just brought up a similar point, which is that, you know, we do have people who still, who need to use twig, and potentially having that be something that's disableable by default is definitely a compelling idea. Hi, it's Sally. So my crazy idea, which we were just talking about an hour ago was to decouple it, but we wanted to build a symphony app for the front end. So the major, like just a pure symphony app. So like the major thing that we kind of identified as being a problem is the form API is not really there right now. We can't query it and say like, what kind of form should we build? So we would like to do that. Because in our symphony app, we can start porting things from Drupal over to it so we could move the routing over to it, the rendering layers could go over to it. So if you were creating a node, for example, I would query back end Drupal core. I would say, how do I build this form? Do all the stuff, validate it with Drupal core. Drupal core would do all the crud and then we'd use symphony views to display everything. Nice thing about doing that way as well is we already know symphony. We don't have to be like, you need to know JavaScript now or you need to install Node.js or anything crazy like that. That was exact, you know, I think there's some kind of telepathy here because that was exactly the proposal that came up in the last bof, the front of bof, which was, you know, if we do decouple Drupal and have it as a back end API sort of only layer, then we can also have a front end that it's driven by symphony, has twig, render API is all housed there and really preserves the experience that we've come to expect with Drupal 8 but doesn't throw the baby out with the bathwater. And those two components can still be packaged together in the marketing sense and called Drupal, you know. When it comes to forms, the implementation of REST core should be flexible enough to allow you to build something to expose that. In the end, Form API is giving you some metadata that tells you how to build a form, right? So we could expose that in maybe a standard format that then different libraries can render that as a form. So we could build a form not only in symphony but in any, I would say in any consumer of the API. But, and none of those pieces are there. Hi, my name's Alex. First of all, thanks to all the contributors who've made my life a lot easier with the RESTful module personally. And I was just wondering some of the issues that we were discussing earlier, whether the Friends of Symphony RESTful bundle has sort of addressed any of those and I know it's a difficult sort of task of pulling in a lot of the Drupal entities and sort of things that it's solving. But I'd just like to hear your opinion on how they approach things. Does anyone have any experience with the RESTful bundle in symphony? I do. Cool. Maybe you want to give us an impression. I want to explain. Yeah, I mean, it's basically they sort of, it's before Drupal H was stable, I wanted to build something in symphony and just to get an idea of how difficult it would be to learn. And a lot of the stuff like routing and versioning and stuff, they do out of the box really easily through YAML. But obviously, when we sort of pulling the Drupal way of doing things together with forms, entities, all that sort of stuff, does pose different challenges. But I don't know, I mean, I would just think if we could maybe look at some of the things that they're solving, obviously it might not be completely directly applicable to what we're doing, but might be worth a look. Yeah, just like I said, I don't have any idea of the RESTful symphony plugin, but I was talking about this with someone this week and I don't see why we shouldn't explore integrating more into that. But as you said, there are many idiosyncratic specialties in Drupal that may make these things difficult. It comes to mind like how do we inject all the cacheability metadata, how we do all the special things that we need to do in order to render the quick through the pipeline so we don't have to push through the whole process or just only the necessary things. But yeah, I think it would be an amazing experiment to see how we can integrate more and get them maintain our stuff for free. Sorry, I shouldn't say them and us. I mean, we are all the same community. Yeah, so slightly taking this away again on a different topic, but much like what you said with image cache styles and we've got situations where it's other items in the render process that you would also want to abstract and take and be able to fill in from the front end as it were. So filter formats, anything that you might want to specify actually from the front end as well. I don't know if that's a question or a thought. Absolutely. I was wondering with the ongoing work on the component-based rendering system, if we could maybe think about doing something like refresh list does right now, but instead of getting the rendered output from the server, maybe it might be possible in the future to use twig.js or something to have like a progressively decoupled Drupal out of the box. Do you think that's a feasible thing? Well, there's a lot packed in there. I think that we certainly explored twig.js. I think there might be some people in the room who have more experience potentially with twig.js, but I think the challenge is that Drupal's twig implementation is quite Drupal specialized and it would take a fair amount of work to really adapt twig.js to suit our needs. However, I do agree that it is absolutely something that we should be looking at. And I know that there have been quite a few people who have looked at twig.js. Does anyone have any thoughts about that, by the way? Or people who have worked with twig.js? Twig.js is not fully there yet. There's a lot of missing pieces and the templates that Drupal uses tend to confuse twig.js quite drastically. So, if somebody's interested in helping maintain twig.js, that's great, but it's not there. So, I think we talked about this maybe a little bit earlier. You know, passing those templates forward would be great and then rendering those to twig.js and then abstracting that JSON on top of those would be the right thing to do, but that we're not, it's not ready. All right, well we have some questions also to trigger some discussion, so we'll go ahead and move into those. You're being a little quiet, so, you know, how much of this should we have in Drupal Core? Right. Do you guys feel that all of these should be in Drupal Core? None of these. We should go back to 2009 and talk about Small Core. I don't have an opinion how much should be in Core, but I have an opinion that everything should be in a module because at least then we can just put other stuff in there because the world is moving fast and maybe Chasing App is in the thing anymore in two years so that will give us the flexibility to at least iterate. I mean, we could put it like directly into Core Core, but yeah, I think we shouldn't. So Core Core should be mostly about our quad stuff in a way. We were great fans of RESTful and we were quite set when we saw what was going into D8. So, finally, I would like to have a little less by default in D8 and the freedom to then plug in whatever there would be. And those could be modules, as you said, in D8, but I wouldn't vote for enforcing the default REST stuff that we have now. Yeah, I agree. One of the things that Drees has been very adamant about in his blog post is the notion of specification flexibility, having the ability to use JSON API, but then disable that in favor of using GraphQL instead or disabling that instead of in favor of help JSON, for example. I think the hard question there is how exactly do we want to accomplish that? Because potentially, one of the things I've heard this week also is potentially having all three or four or five solutions for web services and cores could be overkill. Mostly because it would be very confusing to new users and people who want to have that canonical web service. Sorry, what did you say? No, there isn't, but yeah, exactly. How was supposed to be that? Well, that's the way. Well, how RESTs, what I mean by how when I say how is the conjunct of how plus REST. Hi, I'm Jimmy. So this is actually not regarding this at all. I was too quiet before, so sorry. One of the first things that was on the top of the list was versioning. So right now I'm involved in a project where we want to future proof RESTful resources. We're using the, I don't know if anyone else has used it, but the RESTful resource plugins, which are essentially just controllers and we want to weigh a nice way of being able to kind of abstract away a black box so that you have the data lives there and then magic happens and then all of a sudden you request that specific version and then it gets output nicely. But obviously, I mean, you could start a fight in here about how exactly we go on to support versions. Like, do you have it in the API endpoint? Or as, not my decision, but the project we're working on just now, we have a custom accept header. So we went into the HAL module, for example, and pretty much copied that. And so now we accept a custom content type, essentially, and then we pass the version that way. Do you know what I mean? So, but I guess the point is, firstly, how do we even start with that in core if you want to provide it out the box with just through the UI or whatever. And then how do you support it for people who are writing more custom stuff and we're still kind of struggling with exactly what we want to do with it? And will it use SEM there? Or will there be options for having our Drupal versioning of just 1.1 or whatever, or that sort of thing? I mean, the topic is huge and probably needs its own session, I think, version. So I don't know if that's a question or a statement or whatever, but I would appreciate other people who have that problem if they would talk about it. I just want to quickly add that you guys don't need to add a question. I mean, this is just a conversation. So, Amitya is gonna answer that for me. I know. First time really excited that there's a slide saying you are too quiet next to me. It's like the first time. So I'm Amitya, hi. I'm not gonna look at you because I know that you're like, that's why you wanted to switch. So the way I look at it in RESTful and I'm taking some experience that we had in, at least with Drupal 7, which is even less API aware or less entity centric is, I think we're actually talking about two things. So the RESTful part, which is tightly coupled with data is very appealing and it's kind of easy to understand it. Like you have the data, you wanna expose it and then you tweak it, tweak JS, Elm, whatever. That's kind of the simple part. And then there's always the wise guy or wise girl which is inside of us, which is asking, but what about forms? And to me, this is actually, RESTful should not answer that because that's the form's API problem. That is, we are trying to solve two problems and we are, I think, and we're considering as RESTful problem. And for me, there's one thing, there's data. Now everything is an entity and it has fields, either configurable or fields that we can add some metadata to that. So instead of asking how can RESTful build the forms, we could turn it over and say we have here two problems. One is RESTful, which we know either JSON API or GraphQL or whatever. And the second is how can form be built and validated because the form in the end is just a user interface to the actual data and it's actually doing validation. So we can say, okay, we have two separate stuff over here. One is the actual RESTful. And the second is how do I build my forms, build or depend, how do I build my forms according to the data that I have. And then probably we can start talking about validation objects and how we compose them. So what's fun about it is that the API first initiatives doesn't need to really put the form problem as part of it. I mean, it does, but in a way it can say, okay, somebody's has somebody's else problem. And by doing so, we're actually dividing it into two smaller problems where one problem is kind of already solved. That's the RESTful. Now we're actually talking about how to build user interfaces on top of that or how do we build validation object that can be composed and altered. Again, what's important about it is how to make that data because that's the most important. Form API is so weird because it's weird, right? You can do whatever you want and it's not tightly coupled to your data. Thank you very much. Hi, I'm Nathan. Yeah, what I've got to say is prompted by what you just said there. We're using Rammel to describe our end points. So it's pretty well sort of described what response we're gonna get for a request. There's a lot of information in there. I'm not really hot on Swagger or Rammel, but I know that there's enough information there to think that something like that could be enough, there could be enough information there to build things like forms from that type of description. Maybe they're not adequate, but maybe gravitating towards an effective mechanism to describe the data in YAML or JSON or whatever might be the solution to a lot of the problems even down to how we handle versions and stuff so that, for instance, if the form API within Drupal you could actually reverse engineer, I think probably what we're doing now for tools like JSON API and GraphQL, we're dynamically generating schema, but could we dynamically generate the form from the schema the other way around? And in which case, if you were building a front-end app that needed forms, you just need the schema. So this is not gonna sound like very democratic, but we're too used to have so much freedom. And when we write forms, we want to write just the form we want. We don't really like coupling our data structures with how they will look like in the form. I think it would be really cool if we could simplify our lives by assuming that forms are only inputs for data structures, but sometimes they're not. Sometimes it's an aggregation for usability experience for better usability. We aggregate different things that we really need to save in different places. And therefore things get a little bit more complicated. Nonetheless, I think that having these schemas in a standard way and generating them in a standard way will open us a lot of doors that right now are closed because we don't really know how to describe our data in a way that other systems like third-party libraries understand. What we have to do is to put type data into work so we can generate this intermediate system or intermediate description that then we can fit. So there's a lot of value on generating those schemas. And I think that there's even a module called schemata written by Adam Brosts that kind of does that for the rest resources. So this could be a way to explore that and have automatically generated forms, which could be a use case, but not like the only tool. If that makes sense. Continuing what Amitai said, and this is like a crazy pot I had, we could have forms that instead of like, the form will go directly to the entity. Forms could be a representation of the REST API. So if we say you are API first, each form will or could be an interface to an API. And so if you do a validation in the REST API, the form that represents it will just, you know, will just say, okay, for API validate me instead of adding the validation twice. So crazy idea here. Andy, so I just came to my mind because you said that you want to have forms that collect things together for user experience or something like that. So they don't represent one to one the data structure because you might want to have that, have something together that makes sense semantically. And I think that's the same problem that we have with components. If you think about front end components, this is the same kind of problem. It's not also not mapping directly to the hierarchical or not hierarchical data structure, but you want to group something together for a presentational layer. And that's the same thing that you want to do for the form. So I think I have no idea how this can be achieved, but you know, I think that the solution could be something really similar because in this area, the form would be describing a component, you know? Or yeah, something like that. Yeah, I can totally see the parallelism. Like a form could be like an input component in the presentation. You know, I don't want to just map this one to one component and form, but it's from the concept. And the thing that needs to be solved for the component is also how to hold all the things together that in the end form a component. And that's the same that we are doing with form API going in there and describe all the things. And then the only thing for the form, which is the downside, there is more to it than just rendering it. It's validating and all that. But still, the thing that describes the form could be the same, that describes a component in the first step, I think. So just to recap on the idea of the form. So first, forms can be sometimes also complicated. Like you have wizard forms or dependent dropdown or the user experience material is really excited to do with forms. So it can be more complicated. I think my point over here is in a way of saying there are two ways of dealing with the problem. One is dealing with the problem, and the second is kind of ignoring it. And I think that in order to move for the API, first, we don't necessarily need to deal right now with the forms. It can come. It's complicated. I mean, forms are hard. There is a reason form API is so complicated. You've got the states, and you have the wizard, and adjox, and whatnot. And just moving it to some objects with data is not necessarily the right way. And I think it can come once we have those API first already in, then it kind of will force us to move into solving the form API stuff, which might be that we'll find out, circle back, and realize, well, yeah, form is kind of a weird thing, and it needs to be kept away of the data, and we can do whatever we want. So this is, to summarize, another way, I think, to deal with the problem is saying there is no problem, or we don't want to deal with that problem right now. Just a quick note on that. We may already have some of those problems by exposing the rest, the configuration entities, because they are not content. They are not data, per se. So if a form was a configuration entity, would it change anything? Like, would it be OK to expose it right now through an API? Well, first, obviously, I don't know, right? And sometimes you have a form, like you said, that can actually create two different entities. So first of all, let's remember that the use case is saying, I would say that 90%, if not more, of the forms are simple forms, that are tied to one single entity. So let's not become so developers and think only about the age case, right? I mean, nobody's, yeah, I can say, I did say wizard and Ajax, but I don't do it on a day-to-day basis for a good reason, because it's so complicated. So I would say that, yeah, 90% of the case you could go very far and say, yeah, your forms are your config entity. And if you need something more special than just flip a switch and say, I need my form to control it. But again, this is kind of a separate problem. It would be more exciting if indeed I would be able to say, as another person said over here, bring me the information with the input filter as full HTML or filtered HTML in the size of the image. That's for me the API first. The forms can come maybe later. Hello, David. I'm just going to say something similar to Amitai. And I think we have to put a limit of how many things we want to dispose, because now if we have to do forms, then we have to decouple the implementation of the form from the validation. So we have to offer it from a service. Then when do we stop? Will we expose something else later? Because there will be a new case. So at the end, what we will end up is grating up Drupal again from scratch on a DDD or something like that. So we have to put an stop to this. If not, we will end up doing a lot of work on re-grating everything from the beginning. I was totally going to introduce myself as Jason. Preston, you might get that. No, David. So the title of this session is API First. And all we've really talked about is sort of backing ourselves into an API, or an API sort of secondarily. What do you guys think it's going to take for APIs to be truly first? Because we're still really talking about APIs next, APIs more, APIs as this thing we've forgotten. Now we're going to make sure we strap it on really tight. What is it really going to take to be API first? That's a very good question. There's a whole lot of dimensions to that question. Because as we mentioned earlier, there is the issue of the size of Drupal and the surface area that it occupies. The second, which I'm going to cover now instead, is because we've already been talking about the first, is I think that what we should enable is not only should you be able to create simple crowd applications based on Drupal, you should be able to create rich editorial interfaces based on Drupal as well. That's a use case that has been coming up more and more. More enterprise organizations and some of these developers are looking for the ability to brand their own editorial interfaces that can be fully decoupled. That's something that was historically done with the admin themes. People want to do that kind of thing. People want to create applications that are based on Drupal. Where that line lies, where that horizon is, is also really up for debate. I would also want to add that I think that Drupal as a project, it's going to be very difficult to make it become API first. I think that a realistic goal here would be having Drupal allow you to build your project in an API first manner in a way that you can define your API, give it to the backend team and the front end team, and have them work independently and at the same time. Right now, this is kind of difficult because it's doable if you define an API in a way that Drupal is going to speed your API to. But that's not really goal. The goal would be to let you define your API and then have Drupal build it and the consumer build on top of that definition. And at the end of the project, they two marry together to the API and live happily ever after. So I think this might be the last one, Sally. OK, I'll say two things then, just to be in a way. So what Amitai was saying about the forms, I think we are trying to do too much and shouldn't be too afraid of throwing things away. I don't think we need to handle Ajax. I don't think we need to handle multi-step forms that should just be decided by whoever's writing the UX because maybe your app wants to do it differently on iOS to how I want to do it on the web. And then secondly, coming to this, just have the front-end team work over here and the back-end team work over there. Where that has broken down for me in the past is giving anyone some kind of layout control. Because we do need to give editors something, it doesn't necessarily have to be very fine grained. So right now, the only layout controls you have in core are blocks, right? And that's something we want to expose as an API, but Tim right now I think is working on some kind of crazy, what is it? Yeah, like field layout stuff. So if we're going to continue forward with doing stuff like that, we're going to have to consider how we're going to make that API first or are we going to just drop stuff like that and not do anything with those going forward? I believe that in any case, layouts are presentation and the server should not really control the presentation. And in the other hand, what we want to achieve with this is we want to have the power of like going back to the form example, we want to have the power to expose as much configuration as we can so we can mimic what we are doing in the back-end. Also in the front-end. So it's kind of this option that we have that we either do too much for some people and we allow this control of layouts, this control of forms, et cetera, or we either do too little and we kind of defer those choices to the front-end. Yeah, they will need something. It's just training people to understand that it's more of an abstract something than like you have a panel and you can put this in the right block over here because our content can appear on a million different devices today, like your fridge. So that's also a bit of a problem, just like training editors to not want to do things like in-place editing because that only works when you're staring at the screen in that way. So I think that's another challenge we need to overcome too. Alrighty, well here's some more questions for food for thought, just to flip through them very quickly. What are the place places to start using this internally? What features are you excited about? You know, what authentication providers, decoupled admin interfaces, something that we should support out of the box potentially? One quick note, I was asked to put this slide up or I wouldn't get any beer. This is for front-end United, Athens next year. Oh yeah, it's... Well, they did that for Ghent as well. So, Sprintz, what did you think? Thank you.