 So, this is a type system for tomorrow. It's not about font faces, in the case that's what you thought, so feel free to leave now if you want to, I guess. Let's see, how do I get this to advance? False start. There it is. I don't know why that worked. Okay, so like I said, it's a type system for tomorrow. And what I'd like to do is kind of talk about entity types and how we can use them more efficiently, but include some ideas about how behavior and kind of break down how we tie behavior to our core data types and kind of the things that you would need to build ambitious applications with Drupal. I'm Gabe Sulis. I'm a back-end engineer at Atten Design Group. You can pretty much find me anywhere as Gabe Sulis, githubdrupal.org, Twitter. Like I said, at Atten Design Group, we like to work for agencies or for people who we like to say are cause-driven, cause-driven organizations, so universities, nonprofits, and GOs. We love working with those guys. We're a full-service digital design strategy and development shop based out of Denver, Colorado. I found this quote that kind of inspired this talk, and it was, bad programmers worry about the code, good programmers worry about data structures and their relationships. And Linus doesn't pull any punches, he calls bad people just bad programmers outright. But this other one, I think, puts it in a little bit better perspective, and it's smart data structures and dumb code work better than the other way around. And so in the context of Drupal, a data structure is an entity type, right? We use entity types to label data. We say this is a user, this is an article, this is a blog post, or this is some other random thing that we can identify as an abstraction. And everything interesting we do revolves around that idea of those data structures, those entity types. And working within an agency, you know, I'm not a big core maintainer, I'm not just focused in the code, I'm constantly just working on little projects having to solve a lot of the same problems over and over again. And I kind of got some deja vu. I'd see the same problems come up over and over and over again. And so I wanted to think about how can we use our data structures, how can we create and share behavior between them in order to solve these problems in a more generic way so that we're not writing custom code over and over again. How do we not recreate trees? How do we not recreate queues when we don't need to? And maybe not do access control in custom code over and over again for some complex use cases. So we read those concepts about data structures and our entity types in code, and we have to write that over and over again. But we can probably make it configuration, or a lot more configurable. So some examples of those problem types are kind of complex associativity. So what I mean by that is this user has a ticket for this flight, and those three entities might be related, a user, a ticket, and a flight. We also have hierarchical and ordered data. This classroom belongs to this school within this school district. Or nested data structures, that might be something like an office is located at this address, or this article has a pull quote. And so you've got an address embedded within an office entity or something like that, or complex access control. That's like this user should be able to see this entity if it has this field value, and then finally like triggered events that happen on entity cred. So when this node is saved, send an email or ping this person, right? So we solve these same problems over and over again, but we don't have generic solutions to them. And so we use contrib and custom code, and we have a little bit of out-of-the-box functionality to solve that. And we often see that when a need to a particular kind of pattern becomes blatantly apparent, right? We'll see something like paragraphs, ECK, or field collections come out. And they're all trying to solve the same problem of nested data structures. And sometimes they're better than others. And oftentimes I think that's because they're just in core these blunt points of extension, right? You only have hook entity insert, hook entity update, and those kinds of things to actually start to work around these types that we've just defined in the system. And so without a lot of discipline within an organization, solutions to those common problems can vary widely. You can't get the same thing over and over and over again. And it also becomes very hard to teach new people about that. It's not accessible to the novice programmer, and it's not accessible to the new hire. So why does that matter? About a year ago, my fiance started her own business, and she needed a small website. Her needs were simple, maybe a page or two, maybe a blog, and just prominent contact information. It needed to be low maintenance, and the editing experience needed to be intuitive. I didn't recommend Drupal to her, right? It would be overly complex, it would just, it would be a time suck. It would be hard for her to use without a lot of custom work. And there are a lot of other solutions out there. But then, not long after that, I was talking to my friend, and we were discussing how so many people in businesses and entrepreneurs are kind of left out of this information revolution that we're experiencing. And they're still stuck on paper, right? They're using Excel. They can't create applications that solve their problems, right? And so he had, during his time in college, he had spent a couple of years working for his dad's company. And he remembered how everything he did was on paper, and that they had all this information in filing cabinets, right? They could go back and they could see a historical record of how much things it cost, how long it had taken to complete them, but it was totally inaccessible to them. So in only a few hours, we were able to use Drupal to mock something up that would let them put their estimates in, and actually create some application where they could start to record their, the actual needs of their business into a Drupal site, into a technological piece of work, right? And so that's where Drupal is great, right? It's this great, fantastic tool for building something custom to solve your real needs, either individually or in a community. And so with some dedication to perseverance, you can get really far, really quickly. And with perseverance, you're gonna build something that actually gets something done, right? And so I think in Drupal, we've seen a lot of hand wringing about, are we going more enterprise or are we trying to help the little guy, you know? And how do we solve those things? And I think it's been presented in a way that's forcing us to choose. And I think that if we kind of look at Drupal a little bit differently and see what it's really good at, we can bring those two together. And they don't have to be mutually exclusive, right? And so just as that lone individual can create powerful tools to make their ideas actually happen, an organization, the enterprise, can benefit because they can reuse the same patterns across their many business needs with the same Drupal application, right? And do the same thing in repeatable ways. And so where Drupal really shines is its ability to build malleable solutions to unique sets of problems. User-fieldable entities and generic behaviors composed together to solve those problems, right? And so I think we kind of need to think about Drupal and the types that we're providing to people and the behavior that we make available, kind of like a language designer of like C or Go or Haskell, thinks about how to create a programming language. They expose concepts like recursion or Lambda functions or something like that to programmers in order to put those together in interesting ways to solve unique problems. And they can't envision what the problem is that somebody is going to solve with that, they can just say that I know these ideas, these concepts put together will be able to solve those things. And so we can't know what people will do, but we can expose behavior and ideas to people in a more accessible way so that they're not so closely tied or kind of tangled up inside Drupal core. Yeah, so what are those data structures, concepts and behaviors that I'm talking about? So just some basic ideas of what a data structure is when I'm talking about it, right? It's big clumps of relatively simpler data. So you could say a map, a list, a queue, a set. We'll go into each one of those and how they can solve particular problems, right? So the simple example of a map in Drupal is just a profile page, right? The map is the key in a map, a map is made up of keys and values. In our case, a field first name or field last name is the key and a string is its value. But then we can also say like we have some organization and its users are, we have field users and that's the key. And it's an entity reference to users and those are the values, right? So you can compose maps of many things using entity types. And they could be put together in many interesting and complex ways. But between, so that's the entity type, right? That's all we have right now. It's just a map to some extent. But other data types that we might see in programming are things like a list or an array, and it's just a meta structure, right? We can deal with these many items all as one unit and we can pass that around and use that. And so we might see something like that in Drupal as a multi-value field or using the contrived module as like entity queue. Queues are interesting in that they're a lot like a list except the order isn't defined by the entities within the list. It's defined by the time that they go into the queue itself, right? We have trees, we see that in taxonomy and we have sets. So you can take blue, and you can say aqua and navy are a member of some taxonomy tree, and then you can tag nodes. And you can say stuff like all these three nodes are members of the set aqua, but they're also members of the set blue. And you can do the union or the difference or the intersection of those things using taxonomy trees. And so just their mere presence in a set, right? A node doesn't know any of the other nodes in its set. But it knows that it belongs to the group blue. And so then the concepts, right? So no longer just structure, but concepts that we can put together in a way to solve problems. And that's first is just order. The idea that we can put things in an order, something can come before something else, right? And applications that need that might be like staff seniority lists or user preferences, right? You should be able to let people create applications that utilize the idea of order to solve their problems. You would let people arbitrarily group entities without saying anything about their category, which is kind of what you have to do if you use a field and referencing those. We should make order available outside of just a field list or something. You have hierarchy, right? So if we had hierarchy as this thing that we could use for any entity type, we could let people do family trees or say, make an organization entity type and then put that in a hierarchy. So you might have the international order of dog lovers and then like the Peruvian order of dog lovers and the American order of dog lovers. And these things form a hierarchy even though they're all the same entity and they're not necessarily terms or something, right? Identity is another concept that needs to be accessible. That's basically addressable, can we point to it? Can we reference it? Can we load it when we want it? And identity, you've got kind of two different things like uniqueness. Whether, I mean it has to be unique to be an identity, but also random versus deterministic, right? So we expose through config entities this idea of a deterministic ID, right? When you use a machine name, you're saying this is generated in some way that I can know exactly how to type it. I can program around this entity, this ID. It's kind of like a problem of syncing taxonomy terms between environments. You're using a UUID or a term ID and those aren't deterministic. Those are generated at the time that they're not determined by the nature of the entity itself. And composition. So this is the idea that you can take smaller things and build up to greater things, right? And composition is absolutely everywhere in Drupal. We see it in address module, paragraphs, ECK, media entities, the phone numbers. It's basically we take these smaller sets of like area code, phone number, country code, and we put those together into something we call a phone. And that gets composed together with a contact to give a little bit more information. And in Drupal, we see that the unit of composition is the entity reference. That's how we glue these things together into bigger forms. And then finally, there's association, right? Association is the idea that two things can be related to one another, but not necessarily part of the same thing. They're not embedded within one another. Like an address might be embedded within an office. And association is two distinct things. Like two users have a friendship between them. And just to say, just to break that difference down a little bit, composition might say that you put a paragraph inside of a node. But association actually keeps those things distinct. And we might use entity references to say the ticket, right, is composed of the flight and the passenger. But the passenger really has no need to directly have like a field flights or something. Or the flight doesn't need to have a field passengers because you couldn't describe complex things about that association between them. Are they an economy or are they in first class? If you're just using a field, you'd be hard pressed to differentiate the nature of their relationship. And then observability, that's just the idea of if this, then that, right? When this node is saved or updated, do some action. And we have access to that right now in code, but we haven't exposed it without maybe something like the rules module, very well to site builders. Okay, so where are we? With these ideas. Order, we can basically expose that through taxonomy weight, field weight, book weight, and views sorting. But of course taxonomy means that we're limited to taxonomy terms. And taxonomy itself kind of confounds hierarchy and order. You can't just have an ordered thing that doesn't also imply some parent-child relationship. Book is again limited to nodes, you can't use it with anything else. Entity reference, field weight is kind of most like what we'd want. But we've not built any special functionality about creating order between many entities without having to create some list or really utilize that in some easy to inaccessible way to everybody. But we also see the entity queue module in contrib, and I think that's telling us that there's a need for it. In some examples, it's like a drip campaign. You put 15 blogs in a queue and then we're just gonna publish one every day or something like that. That might be something you could build if you had access to order without wanting to, I guess, do some custom code. Hierarchy, we sort of have it, right? We have it through taxonomy terms, we have it through the book module. Ad hoc entity references, but again, a lot of the same stuff applies, right? It's limited to terms, limited to nodes, and there's not a lot of special functionality around it. Identity, I think that's pretty clear. We have UUIDs and machine names, and so we're actually really good on identity. Composition, actually, we're really good and well placed there, right? We have entity references and they're absolutely everywhere. The problem with the core entity types we have now, if we look at something like node, is that we have no behavioral opt in or opt out, right? If you wanna just use bundles to represent most of your content, you're limited by the fact that titles are required on everything and everything gets a path, right? You can't just make an address node, you have to actually install the address module, and so that means it's less discoverable to users. You can't just use it as to compose data structures out of something very simple, the same idea of nodes for everything. And we see other things like dynamic entity reference and inline entity form, they're all kind of telling us that composition is really this thing that we should focus on. And as far as association goes, we have nothing, right? Nothing exposes that idea of complex relationships between entities in a way that's usable. We kind of, in core, right? Contrib, we see like the OG module, which has created its own membership entity. But unfortunately, that's kind of limited to like your grant, organic groups module, and you can't express things beyond membership, right? And kind of hacking it together. And so we can imagine like this is some code from OG, right? You'd say create this membership between an entity and a user, and then you could save that membership. But more generally, if we had some support for that in core, we could say like create an association called a ticket between a flight and a user and save that ticket. And we could create all kinds of different associations and have easy ways to access those. For example, we could get all tickets ever sold for a particular flight using some common code that unifies those different ways of expressing association between entities. So it's kind of aspirational, but I think we could do something like that. As far as observability goes, right? We have hooks, action plugins, and condition plugins. And as far as core goes, the action plugin allows us to create actions that fire when an event happens, right? Like an entity is inserted, send an email, right? But because we haven't exposed those in any meaningful ways, user aren't really able to use those actions without getting into custom code, right? Condition plugins allow us to say if this node is created and it's tagged with blue, then do something different. We have them for exposing blocks on a page. But conditions plugins are actually these really cool thing, but we don't use them in any meaningful way, but you're on just block placement. So you can imagine doing all kinds of interesting things with condition plugins. And so I wanna, this is really quite fast, but the takeaways I think are that we have a lot of stuff in core, right? We have the idea of hierarchy, we have the idea of order, but we have tied them very specifically to entity types, right? We've said that if you want to create hierarchy, you have to use taxonomy terms. You can't just make them out of any entity. If you wanna get a node page, right? You're gonna be stuck with a title field. You can't use that to compose things like an address or a phone number or something like that. And so I think what we can do is look at those concepts and think, let's pull them out in an interesting way. Allow us to create a new entity type out of our own fields and then say this thing can belong to a hierarchy or this thing can be put into an ordered list. And let people put these together in more unique ways, right? We cannot tie them to our entity types. Our data types are locked to our behavior. The idea of fieldable associations is not in core. And then we don't have condition plugins exposed in meaningful ways. And then action plugins are just this kind of unused thing, because we basically expose it in no meaningful way. You can't use conditions to trigger them. You can't use anything but the rules module, which isn't using these action plugins to actually make behavior happen. And so if we can kind of look at this idea and say, how do we let people use Drupal Core to build useful applications and put these ideas together in better ways, then we're not democratizing the ability to create these applications. We're not saying Drupal is gonna be a platform to build a great blogging thing, right? We can't just let somebody create a distribution just using Drupal Core or their own custom blogging platform that people are gonna be more likely to use. That went much faster than I expected. Let me know what you think. Feel free to tweet at me. Keeps Elise. Leave me a review on Drupal.org or the event thing on Drupal.org. And don't forget to take the survey monkey for the conference, yeah. So we have a lot of the tools in core right now with the type data API. So my question is, what is your kind of vision for exposing all the data API in meaningful ways for site builders? And maybe you can explain a little bit about what your vision is. Absolutely, okay. So if you look at the book module, I think it's a really interesting idea of how we're exposing hierarchy to different entity types, right? And what you do is you can create a new book, and that happens to be a node. And that book, you can actually add new nodes to, and you can arrange them into a hierarchy. I think one of the things that you'd look to is look at the book module and say what can we rip out about this that's specific to hierarchy, right? And let people create those things, make a config entity called a hierarchy that nodes can be added to, or any custom entity could be added to. The same goes for queues, you could create config entities as queues and let people add those to queue. Does that answer your question? Yeah, and so just continuing on that conversation, you're thinking about interfaces or providing a user interface around exposing the item list data type or the map data type which already exists. And then let people create plugins, unfortunately they're plugins. So we'd have to change something about that to allow that to expose and extend from the core data types as their own kind of non entity or entity thing. Yeah, are you saying that you want to kind of expose typed data itself to it through the UI? I mean, that's what's currently in core is typed data. And so most of these things are already possible if you use typed data. But as you said, it requires a developer, a programmer, and it's not easy and it's not something we can necessarily expose in the UI very easily. I'm not sure that's true, right? We expose a hierarchical thing for taxonomy terms and we know that we can move these terms around in that list just by creating a new, you had something to say? Okay, yeah, we have things exposed that expose these concepts, right? We don't necessarily need to go to typed data to expose a map, right? We can use entity types and that's an analogy, right, to what a map is. You've got custom fields, a bundle, for example, is a way to create new schema for different maps. I kind of disagree with that because I'm a big type data low level person. Yeah, I like creating data types that don't necessarily have storage implications. So you could use, we could extend from those that base type data and come up with different storage and whatever that's not entity based. But I think that definitely coming up with better newer data types is a good thing, like the set. Okay, absolutely. Yeah, I've looked at typed data, I think it's awesome. The reason I wanted to come here is because I know that there's a lot of talent in this room, right? There's a lot of people at this conference who understand the typed data system and I wanted to kind of get your juices flowing and say like let's look at typed data or let's look at the entity type system and actually make these things available. If you'd like to talk more, we can discuss those ideas, I'd love to. I mean, some of this sort of feels like what entity ECK tried to do. So it sort of generalized stuff, which I really like the module, but I was just looking at it as like 18,000 usage. But I think to some extent is there also, I feel like people are often looking for like a story about how to use these concepts rather than just like the random concepts, whereas like the book and the book module, like the group's module say, like they're sort of, they see it as, as you know, membership in a group. So I think if you're not a programmer, if you're not sort of in the developer mindset and you see something that has a story that this is groups, it means something more than just generic associations to get people's sort of mind around how I might use this. Whereas if we expose, if we build something that is just sort of generalized, exposes generalized concepts, will it be like what's the subset of the sort of, I feel like the intersection of people who would want to use it through the UI and the people who also could code it, would they choose to be, I would choose to code it instead. Like if somebody gave me a UI to do all this stuff, but also like just these generalized things, but I could also do it in code, I would probably choose to do it in code when we get to this sort of generalized level. But we're building, but to some extent, Drupal builds tools for people who aren't coders, who might not choose to code it or haven't learned to. But I think if you're doing that and they don't have sort of the backstory of these generalized ideas, it's really hard for, it's really hard to figure out these generalized ideas unless you have to say, oh, this is a taxonomy term and you can order your taxonomy terms rather than, hey, here's the general idea of ordering things. Is there, have you thought about like how do we, where's the line between sort of exposing these generic concepts to sort of guiding people into how they might use them? Yeah, I think maybe I didn't express the thought as clearly as I wanted to. And that these concepts are, the reason I identified these concepts like order and hierarchy here is to say that we should, they should be individually put together and composable into pieces. But it's not the end user that necessarily has to compose them together, right? If you wanted to create something like the book module, you could reach for ideas in core and put those together into a module that mostly be configuration for like, okay, we're gonna create a book entity type that comes as configuration, as default configuration with the book module, right? But it's just using under the hood this idea of maybe a hierarchy entity or a hierarchy type data structure and then exposing forms to use that. But it's just basically let's break them apart. Let's not say you have to use terms or nodes to create hierarchy, just that we have hierarchy and it works with entities. And so if you need to reach for something else, yeah. So one thing that I, cuz I'm friends with Gerard, the guy that made the ECK. And one thing that me and him had talked about is that it's really hard, it's hard for people to conceptualize how to use it, even though it's like super powerful. And I had a suggestion for him that he never took, but I think it's an interesting idea is to write a distribution that uses something like ECK and removes as much as possible from Drupal Core instead. Because as long as you have things like nodes and taxonomies and stuff, terms that have stories around them. And you're not saying, hey, you can build stuff with generic entities. I mean, you probably have to leave nodes in. But if you could just say, okay, here are the building blocks and I'm not going to give you these things that I've already built these behaviors and assumptions around. Then I don't think people are going to sort of build those things. Unless that's the only option you give them. Yeah, I think the quickest when I've seen it is just like looking at the node module and the node entity type. And looking at the things that make people hesitant to use them in those interesting ways and the reason that they went to ECK, right? If you don't have a required title field, if you don't automatically generate node slash node ID for every bundle, right? Then these things become a look a lot more composable. And so it's very easy to ship with the article bundle for a node that has a title field, but not necessarily require that every bundle have a title, right? Or every bundle have a page. And so it's something that you can configure out of the box and provide that to somebody, but just still have a more generic entity underneath. I kind of imagine that almost everything would become a node if we started breaking these things out, and bundles would just kind of be. I wouldn't have gone down that road before. Yeah, I know, I know. Bundles for everything or ECK for everything, right? Another thing that's been discussed recently is using GraphQL to expose data definitions from the entity definitions and being able to do some of that association just in code rather than in storage. So that's something else to think about. Yeah, no, a lot of these I worked on the JSON API module and we had to make the decision to only expose bundles. We couldn't just say expose all nodes because the schema was different between bundles and thinking about things in terms of types really helps you think about that. And there are, of course, relationships between entities in the JSON API as well. Do you see anything wrong with the entity reference stuff within core? I mean, I sort of think of what you've shown with the airlines of being in sort of the classic database thing. If you've got a many to many relationship, you kind of have a join table. We could have some sort of joint entity that had any references to the two items. Yeah, I'm just curious about your thoughts on that. Yeah, so I think that just like you might add the behavior of being put into a hierarchy, you might add the behavior of being an association between two things to an existing node bundle or something like that, right? And that configuration would allow us to kind of optimize queries in some way, right? Like automatically add the joins to say, when we're doing, where did I go with that code? Code like this to say, give me all the tickets sold or give me all the passengers from a flight, by using that information that this thing is an association, we can start to optimize around that and create join tables for nodes that have been flagged as associations or something. Yeah, I think that's what I wanted to say. I'm hesitant to go with like a new entity type as an association, because I think it falls prey to like the same thing that we have with taxonomy terms now, which is like a taxonomy term is this custom entity type. And the only reason it's a custom entity type is to expose custom behavior, rather than just saying, let's have genericized entity types and allow behavior to work with any entity type. And I know that's a difficult problem to solve, but that would be an interesting way to put things together, right? Thanks, guys.