 So, hi. I'm Matteo. I like decoupled architectures, and I've been involved with this kind of architecture for quite a while now. I think it was kind of three years ago in one of my internal reviews at Lollabot. I said, my boss asked me, what would you like to do next year? And I said, I would like to get into an API-first project. That happened. And now I'm gladly presenting about this stuff. Lollabot is a digital agency. We do not only Drupal. We love Drupal. We do other stuff like content strategy, design. We do React. We do a lot of JS stuff for clients like MPC, universities, et cetera. And they paid for my trip here, and I'm very grateful. So, if you have the chance, come by the booth. So, in this session, I will be happy if you come out of it and you have learned about some of these topics, JSON API, what it is and when to use it or why to use it in the first place. A Drupal module. We wrote a Drupal module. I hear it's working fine. But, yeah, I'm going to give an update on the status of the things that we have pending, of the things that we implemented and why we did it this way, and the limitations and how it compares with other solutions like resting core or even the GraphQL module. And finally, some of the outstanding problems that we have in the decoupled world. Not just for JSON API, but also for many other decoupled architectures. There are tricky problems. Some of those have solutions. Some others have hacks. And we'll talk about that. Hopefully it's not going to be rushing through it because it's towards the end. So, JSON API, their motto is that JSON API paints your bike shed. And that is because I don't know if you ever had to design an API, but that is something that everyone has an opinion on. Like, what's the name of the property that's going to be there? How are you going to structure the JSON object? Or how are you going to interact if you're going to use rest or not? So, JSON API takes that off your way because it's an opinionated specification and it tells you what to do and the discussion ends there. So, it's pretty nice. I've been experiencing success with that, with that bike shedding stopping there. So, basically what it does, it defines the transport format of a JSON object and also the interaction on how you communicate with the server. So, JSON API is a specification, a particular specification that tells you how to do things from the server's perspective. So, then consumers can make assumptions and work on that. And by building a standard, what we're building is an ecosystem of tools that can be used. So, don't look at this too much because we're going to go into detail a little bit, but first I want to make a note on the fact that JSON API, it's a specification, it's a document and it's a Creative Commons document, which is kind of the closest that you can get to open source when you don't have source code and it's completely open and most importantly it was developed and run by UX and front end experts because I am a backend developer and I like things that kind of cover all the corners that are very academically correct, but those things are not the things that are the most easy to use. So, these people basically what they did is they have been experiencing some pain using other specifications and that they did their wish list. So, what this tells us is that this is something that is designed to be used. It's designed to be easy to use. So, why this one? Because there are many, right? So, one of the arguments would be the one that I just said that it's easy to use, right? Another argument could be that, well, when you see and you compare this with the many specifications that are out there and I'm not listing all of them here, there are many more and this is only talking about REST specifications. You can see that JSON API is not doing too good compared to other like Uber or Mason or whatever. One of the good things is the only stable specification that there is out there, like the only modern specification on top of REST. And it works really well, especially because as I said before, when you set a standard, you can then build an ecosystem of tools that can help you leverage all this information. So, why this one? It's because it's insanely popular. There's a lot of software built around of JSON API. It's not just in the Ember community, although it started from the Ember community, but there are like more than 141 repos and this is just taking their side. And I know that there are many, many repos that are not listed there. For instance, the Drupal model is not there. Probably should be there. It is not. And also, whatever your language is, your preference is, there are integrations with JSON API. Like there are more than 18 programming languages that interact in one way or another with JSON API. And you have both client side and service side implementations. Like you have react integrations with JSON API and you have in the front end and you have in the back end Drupal integrations with JSON API. So that makes it really easy to get that 80% done so you can focus on what is important, which is adding value for your project. One of the things that we learned last DrupalCon is how by reusing and making these assumptions, you can build something like the Cards CMS, which I don't know if you saw that presentation last year, but it was pretty amazing to see how seamlessly the communication worked from this Ember application and the Drupal side using JSON API. So that's what we gained. Another good thing that I like about the specification is that it doesn't control too much what you need to do. It kind of gives you room and flexibility. Like, for instance, I like to highlight the filters idea. So in JSON API, you can have filters. And what all that they say is that when you do filters, you are going to specify the keyword filter in the query string. And that's it. That's because every server has its idiosyncratic implementations of filtering, right? In Drupal, we have the entity query API. And we can query any entity and relationship between entities. And it's super powerful. But we need some way to express that as part of JSON API. And JSON API doesn't tell you how you need to do filters because otherwise we would be in a corner trying to do kind of weird mappings, right? So what we did is since we have this room inside of the filters parameter, we specified in the Drupal module what is the filter strategy that we're going to use. So now we end up with a specification that's JSON API that specifies almost everything. And then our specific stuff, which is the Drupal filtering extension. So by providing those, you kind of provide full documentation on how to use this. So, yeah, the extension system is pretty nice. Also, it is kind of useful when you follow a particular specification when implementing an API. It is very nice to be able to just send front-end developer to the documentation. Not because you don't have time for that, but because the documentation and the specification, it's kind of more detailed on what you can and you cannot do with JSON API. So now your server uses JSON API, so you can just point them by giving them a link. And that's it. So that's pretty interesting. That clears a lot of support requests from my playlist. And so why, why do you want to use JSON API? Why am I passionate or I like JSON API? That's because before I landed there, I started with the couple project, the one that I was mentioning before. So we basically ported all the Drupal ideas and we made a JSON out of it and we sent it to the client and we rendered that in a backbone app, I think it was, but then, yeah, backbone. And that worked well. I mean, there was a lot of success in that project. It was a single website. It was the couple. And by just making things JSON and sending it over the wire, we got done. But then the same happy client wanted a second project. And we wanted to use the same API. We realized that we couldn't use it because there was a lot of presentation details encoded in our API. And that was a problem because now we wanted to show things differently while serving one site. We wanted to serve a second site, but it had a different design. And we had fields that said position title on the left and a background color red. And that didn't work for the new design. So we had to choose either one or the other. So basically we had to redo the API, learn from our mistakes, and we did this second project. It also went well until we got the third project. And at that point, I mean, I wanted to see what other people were doing. This cannot be just me having these problems. I should have done that before. But hey, I did it at the end. So basically that's when I discovered JSON API. I debated on using JSON API or how by the time GraphQL was not on the table. And we went with JSON API. We never missed any other feature before because all the problems that I was having are known problems. And those known problems have known solutions. And either you use JSON API or another advanced system, you are going to have the same known solutions applied to it with some other flavors, right? In JSON API, you interact differently with the API than with all the solutions. But in the end, you sure solve the same problem. So implement the same solutions. So let's talk a little bit about the JSON API format. I'm going to rush a little bit through this because I don't think that this is very interesting. This is just format, right? So basically there are like four parts. I encoded them with colors. The blue part is the resource information. This is what identifies a particular research. It can be, for instance, a type collection and then the ID number 23, right? So yeah, that's pretty easy. Then there is the actual data, the attributes and relationships that you have inside your, inside of your entity, the inside of your research entity. And finally, we have the yellow part, which is metadata, which is kind of talking about the data that you're exposing, things like this resource was loaded in 0.75 milliseconds or that's too fast probably. But yeah, you also have like links, things that are related to each other and this kind of metadata. And finally, you have some glue code to put everything together. So it looks like this. There is the part with the identifying the resource and this part to identify a resource is going to be reused in the relationships because in a relationship, you point to another resource, right? That's what the relationship is. And then you have attributes and relationships and inside of that, you have just the key values. So it's very readable. That's what I was saying when I was saying that it was designed by UX designers and front-end developers. They want it to be usable. They don't want here an array of name equals whatever and value equals whatever. If it's an array, then it's just plain simple. In here, I'm just setting a string, but this could be whatever. This could be just an object. And the relationships are kind of fractal in the sense that they contain all of the four colors inside them. But basically the idea is that you have the key, the name of the relationship and then the ID of the thing that they are pointing to. So this is pretty much it. So you can see it's easy. You may be confused because I went probably too fast, but I guarantee that if you stare at this format for 15 minutes you'll be the master of it. So resource interaction is even easier. It just uses rest. The goal of this talk is not to talk about rest. Probably you are already tired of hearing about rest, but it's basically using HTTP verbs to do actions on the resources. And for us, like to get us in the mindset, resources are kind of just entities for us. We kind of use the same name. In the rest world they use the word entity and we do as well. So it's kind of the same thing. So this is what it looks like. You make a guest request and you get a response. Pretty much that simple. The only thing is that you can pass, at least in the Drupal module is kind of optional, you pass an accept header saying, hey, these list of articles, I want them in the format API JSON. And that's that. So we said that we had typical problems. We didn't talk about those problems, nor the solutions. So the big problems are related to three big topics. One is that in rest, typically we have multiple requests to the back end. And by having multiple requests to the back end, what we are doing is we are slowing things down because we have multiple times the HTTP latency from going from my phone in that mountain with low coverage in 3G to whatever server I'm hitting. So if you do that multiple times, it's going to hurt performance. Also, when you get an entity in rest, you get the whole thing, everything or nothing. It's like when you get the entity Drupal gets you everything that's there, right? And finally, there's content discovery. This is kind of an interesting thing because we are so used of having listings and being able to find every piece of content. But that's because Drupal is pretty awesome. And that is not trivial in other places. Things like I know how to access article 12, but I don't know how to get all of the articles. So those are the big problems and those are the solutions. So let me highlight those by going through this extremely simple example. And believe me, your project is going to be way more complex than this. But the example is that there is a blog and my friend Paco wants to do this blog. And he likes to talk about front-end development because he's a front-end dev and he's also vegan and wants to talk about that and cats as well. And he wants to write a blog in kind of this manner. This is the mox that he has. There is a title, there is an image for the author, there are comments, a list of tags with the name of the tag and a link to somewhere else related to that tag and also the images of the authors of the comments, et cetera. So this is not a radical design, right? This seems pretty simple. So when he starts doing this with typical rest, he says, okay, I know that this is article 12, so I'm going to load that and when I load that, I'm going to load the author and when I load the author, I will know that the author has a picture and I will download that. So you can see how quickly that super simple example escalates in the number of requests. But the worst part of this is not the number of requests, but what I have here represented by the indentation levels. You can see that there are three, sorry, four indentation levels here in nine. That means that in order to get the information that we want about the image of the author of the comment on the article, we need to do four sequential requests. That means that we need to wait for four requests to go to the server and back. And that's what's bad. So in JSON API, we simplify that by saying to the server, that looks simpler. When you get the article, just include these relationships, follow the relationships and include the response all in one go. So you make one single request and you get all the data that you need. So that's resource embedding. You are embedding other resources in your initial request. So that's how you would solve that. The idea of kind of limiting what you get back, imagine that he wanted to get only four articles because now we know that when you request an article, you can get also information about authors and tags. So you specify the fields for the articles that you return are only the title and the creation date. So it's basically, it's just that. This is the idea. You get only what you care. So you get all that you want and only what you want in one single request. And that is pretty powerful. So the last thing that we said we were talking about was collections. So imagine I'm going to switch the example. Imagine that you're implementing a record label and you want to do something like this. Give me the cover image and the publication year of all of the albums of all of the bands having one of the members under 35 currently living in Murcia, which is a beautiful region in Spain. And you can say, oh, while you're at it, I'll put the name of the band and the members as well. So that sounds like a lot, right? But what we're saying there is that we want a list of bands and we want to select not all of the bands, but only those bands that one of the members is under 35 and lives in a particular city, right? And then we are also including, we know how to include and we are also know how to select fields. But the important part here is that we are filtering. And this is a complex filter because we are not filtering, we're filtering bands, but we're not filtering on any property on the band. We're filtering on properties on the members that belong to that band, right? So the way that you would do this is you would use the keyword filter and you would say the members, the city member is set to Murcia. And that's pretty much it. You will get all of the bands that have a member that live there, right? Or at least that you said in Drupal that lives there. And you could also add on top of that another filter that says the age of the members has to be, you set it to 35 and then you set the operator to less than. So when that gets interpreted, it gets set to less than 35. So that's it. Then we do some includes, we do some fields and again, you get a collection with all of the items that you need that contain all of the data that you need and only the data that you need. And this is what JSON API is all about. So I don't know if you noticed, but that sounded pretty much like a query to me. The fields are kind of the columns in the SQL statement. They includes our joins and the filters are the where. So that's what we're doing. We are empowering the consumers to do advanced queries on our system so we can have them build the data that we need, that they need. So this is the crucial concept. If you walk away with anything out of this session, just remember this, the consumers are the ones that specify their data needs. You as a server or as a backend engineer, you don't have any business saying this is how you will display data. This is unfortunately not a monolithic approach where you can click a view together and say this is how you're going to get the data. No, they are because my Xbox application is going to have a radically different design than my iPad app. And maybe my Android app is completely different from my iOS app. And I don't even know if I open up my API what someone can do with my API. So what am I doing saying that something needs to be displayed in a particular way? So that kind of reverses the roles and it's not the server anymore saying I'm going to click these filters together for a view and this is what you get, but it's the other way around. It's the consumer that decides what data they need to implement their design and they ask for it. And basically as a backend developer, that's kind of cool because all the work is there. There is a final thing on JSON API. I'm not going to go through this, but there are like for every resource for different endpoints, there's the related data endpoint and the relationship data endpoint. Go and look into the specification and you will learn more about it. I should have known this, but I just sent you to the manual. So I said that there is a performance game, right? Let's talk about that. So I did a very simple test and please don't chastise me on how simple this performance test is, because I'm aware of it, but I'm just trying to make a point. So what I'm doing here is I'm selecting an article 2100 and I'm including the author and the image of that article and also I'm including two tags. Just for fun because we know that the slow path is going to be the three sequential requests, right? But I'm going to select the two tags and I'm going to compare that with resting core and in that case, we need to make those sequential requests. I'm not going to again, I'm not going to bother to do these two tags requests because we know they are not in the critical path. So this is what it takes with page cache in full motion and using my local to make this test takes 21 milliseconds, which is pretty good, right? But you notice that here, if we have more sequential requests, the performance gets worse, right? While if we use modern technique like JSON API does with embedding resources, we get a flat around 7,000 seconds and that's three times the performance. But it's not only times the performance because if we had like nine levels of indentation, it would be nine times better. So this kind of is stable, this performance game is stable if you get anonymous traffic cached by page cache or authenticated traffic cached by dynamic cache or even uncached traffic. So it's kind of a very, I would say that it's fairly safe to say that the performance is better and it's a linear game. So there are more details on how I did this in that just there, if you're curious. But yeah, basically what we are doing here is we avoiding troupel to putstrap multiple times to get to the data, right? But it's not only that, right? Because again, if I'm with my very bad signal on my phone and I need to do the round trip to the server, maybe it takes 300 milliseconds and if you have to go nine times and do 300 milliseconds, that's three seconds to load instead of 300 milliseconds plus seven milliseconds, right? So it is really important and I would say that without something like this, without resource embedding, with JSON API or with something else, the performance in a decoupled app is just not acceptable. So you need to do some of this. So let's talk about the Drupal module. So basically the Drupal module has been, oh yeah, that's where you download the Drupal module. Basically the idea of the Drupal module is that it's zero configuration. So you download the Drupal module, you enable the Drupal module and you're done. You have a fully functional, full-feature JSON API server. So that means that not only you're able to interact with the entities, not just reading, right? We're not talking here only about reading data. My examples were about reading data, but we are also going to have to need to write data to delete entities, to update them, et cetera. So you can do all of that by default. It also integrates with whichever authentication provider you have enabled in your system. And if you add anyone, it gets added to the list. So if your request is eligible to authenticate, then it gets authenticated. It's that simple. It's tied to the entity system. And this kind of was not a heated discussion because it's hard to have heated discussions with Wim Lears. But it was an interesting discussion on if we wanted to limit ourselves into the entity system. And we said yes and I'm very happy that we did because that kind of reduces complexity and makes the module more stable. So yeah, it integrates with the, there is full accessibility metadata support you saw before that we did a performance test with dynamic page cache, which indicates that we have that support. And it works really well with computer fields. So things that you want to add extra to your API is create a computer field and it works. And we took the stands to also make a one-to-one mapping to resources to bundles, right? That means that there is a different resource to get articles and there is a different resource to get pages. There is no such concept of getting a node. And that's because if I ask you what is the list of fields in node 45, you don't know. And that's because you don't know if it's an article, a page, or whatever. You can only derive a full schema from a bundle, right? And that's why we decided to go with the idea of tying the resources to bundles. That has the unfortunate limitation that you cannot make a listing that kind of intermixes articles and pages. I don't think that that's very useful. I mean there is that use case. But you can make the two requests, maybe, with that. I haven't found a use case for selecting all of the bundles on an entity type that would justify going that direction. So what do we gain as part of that? What do we gain is that we can create a schema and there is a module called Scamada and that module has now full support for JSON API and the full support for JSON API, what will give you is document. It is also JSON, but it's just a document that explains the shape of the JSON API output. So it kind of tells you that there is data property that contains a list of, for an article, for instance, that contains a list of properties, let's say, an NID, that NID is an integer that contains a body. That body is an object that contains value, which is string, format, which is not a string. So the use of that is that you can generate automatic documentation. And by generating automatic documentation, you get the ability to just make sure that you have your documentation up to date. So when you create a field in Drupal, the documentation is for your API is automatically updated. So the consumers, the front-end developers can just go and look at the documentation and trust it and they know that it's up to date and they don't have to go and make random calls to your API to inspect the data, they get back to see, oh, I see that the body is not a string, it's an object that contains the key value, right? Because they have here what they need. And this human and readable output here that you see is created by a small project called Doxon, that it just slaps some JavaScript on top of the Eskemata output. So that's what you can do with Eskema. Oh, you can also generate automatic forms because now you know that the title is a string, that the article has a title that it's a string. So you can pass that to a software that writes automatic forms for you. The cool thing is that if you add a Boolean in your back-end, your front-end can automatically create a checkbox for that. So you can also validate your input. So if you're going to send a JSON blob to create a comment, for instance, if you have downloaded previously the schema for comments, you can just validate the thing that you're sending is useful, is valid, and you didn't miss one of the required fields, et cetera. You can do more things. You can even generate boilerplate code. So these software here, what it does is it generates Go models based on JSON schema data. So you can kind of get your start, you can get a jump start on your project by generating code automatically. So you can do a lot of stuff by generating Eskema. And we can only do that because we know that we are going back to a triple bundle. And that's when we can generate the schema. Some of the limitations are the file integrations, they need work, they also need to work in Drupal core. But yeah, I mean, it's something that we need to get there. Like uploading a binary file is still kind of in a rough place. Getting also image derivatives working so the consumer can select which image they want is also kind of difficult. It's limited to the entity system. So you cannot, for instance, expose DB log entries, which is something that you may want to do, but you can't. We gain too much from limiting ourselves to the entity system that this is kind of a pros and cons. Right? It's a good limitation, but still limitation. And extensible through code only is no, that's no longer true. Because thanks to American Airlines, actually, because they cancel my flight and I got some extra time and got this worked a little bit. So that model is still not there yet. But I'm really excited because it kind of ties back to this Drupal philosophy of empowering site builders. And this will allow you to kind of modify some of the things, edit the default routes, rename some properties, disable some fields, because sometimes you don't care about the content translation status field. Especially in the U.S. You do it all in English. So, well, that's not fair. But anyways, you get the idea. Sometimes you don't care about the version ID field. So, yeah, there are some open challenges. Things that are very complicated, like should we take a stance and do some image derivatives in the server on how we think that an image should be cropped and displayed in the consumer? I think we shouldn't. But again, we don't want the consumers to download your eight megabyte picture, right? So we need to do something there. So that is one of the open challenges. There are other challenges, like what happens when you want to do this trick of doing multiple requests to the server, but for write operations? There is no good answer in the JSON API module. I wrote a module that kind of will take a blueprint of requests. It's usable, but still it has its own limitations as well. So, well, there are a bunch of things that are tricky. Like we can get a date in a format that we don't want. Maybe we want in ISO, in the ISO format, on the client's server, on the client's basis. I want to be able to specify the format of my dates, and that is something that we are not there yet. So if you want to contribute to any of this stuff, please come to the sprints. If you don't want to contribute to any of this stuff, come to the sprints and work in something else. But especially if you are a first-time contributor, I think it's amazing. The mentor sprints are one of the best parts of the DrupalCon. Before I go, I want to say thanks to these people. I don't know any of them, but they made this presentation to be kind of beautiful. I like it. So this is all creative comments and stuff. Thanks to them. And if you like the session, please go and kind of evaluate it, because this will help presenters, and this doesn't go only for this session. This will help presenters to get a better chance to present in the future. And yeah, if you didn't like it, you can forget about it. That's it. Ta-da. Yeah, yeah, go ahead. Is this working? Is this working? No? It seems it is working. Okay, so to clarify your question on, clarify your sub-request sub-module, is that to work with Q and batch API requests? So since I'm not sure that could capture, I'm going to try to repeat the question. Is the sub-request module intended to work with Q, batch API, et cetera? And the answer is no. It's not that fancy. I mean, all that it does, it allows you to serialize or to send serialized HTTP requests. And send a collection of them, so Drupal can execute them all and returning one go. The only fancy thing that it does is that it will allow you to say request number three expects request number one's output. So go to this property in request number one output and put it here in request number three. Is there a way of doing Q or batch operations with JSON API, either the module or in the specification? Is there a way of doing batch or Q API operations either in the Drupal module or in the specification? Not yet. And to be honest, I didn't think of that and I think it's a very interesting feature. Just, this is working? Okay. Just real briefly, I really appreciate locking it down to the entities because I understand the convenience. But the problem for me is that if 99% of my API is covered by that and then all of a sudden I need an API endpoint that doesn't, that is an entity related and I have to give out to the client, to the consumer as a separate API endpoint. That seems unusual. Is there like a wrapper or some solution you have for dealing with mixing the JSON API with something else when I need to go beyond the entities? Yes and no. So the idea is that you still have resting core to do all that and it will allow you to create the JSON API output. Like the example that I gave is about logging. But that is not very interesting because logs do not relate to anything and nothing relates to logs, right? So that is the big disconnect there. In order to traverse the data model tree and follow relationships and do queries of things that relate to things like the example that I gave on filtering on the members data that belong to a band, you, if they are not entities, we cannot use entity query to do that query. So you can fake that it's JSON API, you can put it in a route that is compatible with the rest. But it will always be a little bit foreign to the rest of the data model because it is, it's not an entity. Thank you. Hi, you said that the API has right capability as well inside of Drupal. Does that mean that I could use it for something like a syndication model where I have say 200 Drupal sites that I want to have them push to a central syndication server to push out to either other services or for application access or something like that? I don't see why you couldn't. Yeah, I think that you can. So I could set up something like an on update push JSON, a get request over to the syndication server or something like that? Yeah, you would need to do some custom code, minimal custom code for that. Yeah, I think so. Okay, thank you very much. You're welcome. Do the entities that it supports, is that content entities as well as config entities or are you limited to content entities? I should have said that. Yes, it's both. Okay. It's both. Good. So you can, if you're into that, you can update the placement of your blocks from a remote place. Cool. Thank you. For instance, or do something useful. Yeah, my question's about permissioning on certain fields. So you have your band explanation there. If you had like the middle name of a member, but you didn't have access to that, how would your API say you requested it? Would you just get a 404 or a 401 or would you get all the data that you had requested that you had access to? Access control is trickier that you would, or at least what I expected. So the thing is that when you're selecting collections and one of the items that would be inside of that is 403 because it's not yet published, right? You don't want to fail the whole request because there are legit items in there, right? So I wrote an extension that is called partial success that will allow you to overall get the 200. But for those things that failed, you get meta, remember that we talked about the meta section? There is, in the meta section it says, by the way, there was a bunch of things that gave me a 403 or a 401. And in there, you kind of get that output. And if you are authenticated, it will even give you a stuck trace in the JSON. Excellent. Thank you. Another question I had was about removing Drupalisms from the API. Front-end developers that I work with don't like when they see field underscore. And so in say Drupal 7, I have to write complex mapping and to flatten APIs down and complex definitions. So is there a way to hook into or alter the input and the request and response? There are three ways to do that. In level of inconvenience would be hook into the normalization system, which is I don't want to, right? The other way would be field API lets you configure the prefix. So you could set the prefix to an empty string and have your fields named correctly from the start, which can have collision problems. And the last and probably the option that you were expecting is that that module that I said that I wrote recently I'm going to publish will give you a configuration entity that kind of is a companion of the resource and lets you do exactly that. It lets you rename every field from the UI and disable a resource or rename the route, whatever. Thank you. I have a last question. It is if you probably would be possible to allow type data types to be exposed through JSON API as well, although, you know, through some custom codes, is that possible to then expose and use type data? We are using type data and exposing that when generating the schemas. So what we are doing to generate the schemas is we are using normalizers on the type data. Not on the entity, but on the type data behind the entity. Right. The data definition. Right. Exactly. The data definitions. So it's not directly in JSON API, but is accessible through a SCMATA. So if it would be possible to, instead of using entity queries, have an endpoint with the endpoint to a lower level type data or a complex data that's not an entity, which there are very few of, but it is a possibility. And then, and maybe, you know, instead of going, you know, write custom code instead of going through entity field query, go through your own custom data collection. It's not possible and probably it's not gonna be possible because I went that route in triple seven and there is a lot of complexity that goes with that flexibility. Okay. But it should be extensible enough for a separate contrib to allow that. Okay. So we are