 Hi. Thank you for showing up in such big numbers. I hope I can bring something interesting to you. I don't know who here is really familiar with graphs, like who's working with them like all the time. Okay. So there's a lot of people that are just coming to check it out, learn a bit more about graphs that don't really like, that still have to get started. Okay. So especially people that are more experienced, I would love to hear your feedback after this talk, because I'm pulling some rabbits out of my head, and so I myself am not very familiar with graphs. We're exploring what are the possibilities, and this talk will be about that exploration that we've been doing. So originally, this talk was going to be about putting graph databases into popular open-source CMSs, because that was the most obvious thing to do. But then we thought a bit more about it, and we came up with two more use cases that I'll shortly talk about also during the talk, and that's why I changed the title to Graph Databases and CMSs, rather than Graph Databases in CMSs. First short introduction, I'm Christoph Antoma, I'm a Belgian, half Hungarian by now, almost because I run a business in Hungary. We're specialized in developer portals, so we do documentation systems. Like I roam several open-source communities, including Drupal, the developer evangelist, Dita is not open-source, but open standards, and the write-to-docs communities. If you're interested and excited about documentation, you need to go and check out write-to-docs. It's an awesome community, but it's another thing, and those are our partners. So we specialize in developer portals for APIs. Now, what does that have to do with graphs, and why are we interested in graphs? We're really excited about personalized help. To keep it very short, currently, documentation works like a manual. It's like a book. We've taken the concept of a book and we've put it online, and you can go and find individual pages, but it's still following this book structure, and I think it's time to change that. You see already a move towards information as flows rather than books, and I think that's also gonna happen with documentation. What I imagine that in the future, documentation will be in the context of one person so that you get personalized help based on what you've been doing in the system and how you've been interacting and what information you already know and the system knows that you already know. So that's how we got interested in Neo4j and graph databases, because to do that kind of one-to-one personalization is rather hard in standard databases, and that's why we got excited about graph databases. Like, I don't know if you like, this is the evil empire, right? The personalized marketing. We believe that there's a more benign version of that where you do personalized documentation where you kind of like get a personal assistant that tells you like, oh, it looks like you haven't used this feature yet, and this looks like something you might actually want to use. So maybe you want to read this little blurb of documentation here. And then the idea is that you would be able to recognize when people get frustrated based on their behavior and then serve them the right content at the right time. So, and that's with that initial idea, like I had been meeting Michael at a few events, I think at CLS in US the first time, and then we had been talking. A few years ago, one of our colleagues had gotten excited by graph databases and he actually built a module for Drupal. That's the CMS we work in, but I didn't get it. So he built this module, he's a really good developer, so it was good code, but it didn't get any legs because nobody was really using it because they didn't really understand what you could use it for. So then once we got this personalization use case, I started thinking more about it, talking with Michael, and in the end we decided to build a new module together with Tamash, and the idea there was to just capture information from the CMS and start storing it in a graph database so that we can then do queries on it and start serving content later. And the initial idea was like, so what can you use this for? Well, you could use it to explore large non-uniform data sets, so if you just get a whole bunch of data and information and it's not really structured and you want to start exploring it and getting structure out of it, you could use it to recommend content. This is also a very common use case in CMSs for sure. For example, there's news organizations that are using graph databases, like Neo4j in particular, to recommend content based on what you're looking at. And then the last one is like personalization. And I think that's time for Tamash's demo. Hi, so... Oh, wait. Sorry. Yeah. I'll just... Yeah, okay. So this demo will show the... Yeah, so this demo will show the integration we did for Drupal. One of the key things... So first of all, the module exposes the Neo4j client to Drupal modules. But the part that I will demo is to use it with the module called rules. What rules does is that there are events in the system and you can filter them with a condition and then you can execute actions. And I created an action which runs a Cypher query. And the way I... So I haven't... Although it would be nicer to have some kind of visual query builder, but that would be a lot of work. So currently it's only... I can only run a simple query. And this isn't a complex query. What it does is just that includes or just inserts the data into Neo4j that says that a certain person has visited a site. And I also made the token system. So in many places in Drupal, this token replacement system is available, which means that you can get this context sensitive tokens and I made it work with the Cypher query. So basically if you run a Cypher query, these are available as parameters and you can see that there you have a wide selection of stuff like site data, data for the current page that you visit and many other things. And what this allows me to do is to basically build a very simple recommendation system where if you start visiting content on your site, then it will show up as a recommendation. And this small module basically, this is the code that displays the block. And there's also a very simple query here that basically just looks for content that are somewhere there in the database and source them by basically that's just a very simple metric that the source it by the average size of the distance between the two content. Can you actually read it from back there? Can you make it bigger, how much? Yes, I think somehow. I think the more interesting thing probably is to show how the data is stored in the database. Maybe you can show the, do you have the visualization? Yes, so this is basically the graph. These are the actual content that we have visited. These are the paths that we have visited. There's another feature of the module that logs these paths that you have visited. These reds are the actual visits and then this blue one is the user. So it's a very, very basic thing, but I guess you see the fantasy of it, of the possibilities. So you can just squirrel away data using all this, all the tokens that are available in Drupal or well, we're Drupal shop, so Drupal is our thing. So you get all these, all these context things, contextual parameters from the system that you can then add to your graph and do all kinds of magic with and then run queries and get information to do recommendation, for example. Now, this was our first kind of use case and this was the thing that was the most obvious, but there's more. Because we were like thinking about this when we were brainstorming about the session, it was like so, but what could you do if you combine the two technologies? Rather than asking what if you put a graph inside of a CMS, we asked like, so what can you do when you combine the technologies? One of the first things we thought about was this intersection. It's like putting a graph database as your database for your CMS, whether we like immediately rejected that idea because performance-wise it would probably be rather bad because also it would require an enormous amount of work to get that done so we kind of rejected that. The thing we didn't thought about was the other thing. So like putting a graph database inside your CMS, that's what we just showed, but what if you put a CMS as a GUI in front of your graph database? So what if you use a CMS as a tool that helps you to make better graphs? And I'll explain in a moment. So this is one of my spills that I've done for a lot of APIs. It's like this idea that Drupal is not just software, it's a whole ecosystem. Everybody, is everybody familiar with Drupal actually? Who doesn't know Drupal? Okay, there's some people. So Drupal is an open source content management system. It's built in PHP. It's like WordPress, everybody knows. It's kind of like WordPress, but a little bit more to say, WordPress is used for a lot of smaller sites. There's also bigger sites now, but Drupal is more the craftsman tool for building websites and you can build very custom things and a whole bunch of complex things. And the cool thing about Drupal is that it has this really big ecosystem of people, lots and lots of developers that have built extensions for it for pretty much anything you can come up with. If there's a new interesting, exciting API coming out, somebody will build a module for it. They can plug it into your sites, mileage may vary, sometimes it won't work, sometimes it will work and you have a big epic win. So it allows you to really plug in into a whole ecosystem of innovation that's expense with a bunch of things. For example, the developer portal said that we do. What often happens is that some large corporates, they need some special access permission management. They want single sign-on to some specific software, very big chance that somebody already built that module and built that connection. And that's kind of a really nice thing. So what would it mean? So if you think a little bit more about it, like if you would use a CMS as a GUI for a graph database, what could that mean? First of all, I think you could use it as a content model builder. So I know that you can build content models in graphs, but the flexibility of graph databases also makes it its weakness, I think, because you're basically, unless you build a UI and you built a structured model where you have to spend quite some time building that model, you can do pretty much anything. And one single typo and you can have like a different field. Yeah, go ahead. Is it content model? Okay, sorry. Yeah, please, do intervene if I'm saying things you don't understand. So content model is the idea that, for example, company, company name, VAT number, data foundation, company formats, founder, and so on. Those are all fields. Yeah, the schema, yeah. So content model in CMS speak is the schema that you build up. And making a structured, and enforcing a structured schema, I think or I imagine is potentially a problem, I think, if you have a very flexible interface. With CMS, that's not the case because you just get a form that you have to fill in and you just fill in the fields and it's automatically stored in the right place. So, and I'll show you a picture that will make it clear in a moment. The other thing is reports, views and reports builder. I know that you can get the data out of your database, but then how do you sort it? How do you format it? How do you theme it? Like what design elements do you put to it? How do you share it? There's a bunch of complexities that you get for visualizing information that has been solved over and over and over again for CMSs and that there's a very mature tool sets that could be used from the CMS space. Publishing, do you want to prevent access for specific types of users and for other people not? Like do you want to limit the access to some online resource where you have your reporting? There's integrations with other third-party services like importing and exporting content. There's this whole space of functionality that's already available in the CMS space that could be plugged in into the graph system. So for example, for content model, Drupal Core has this fields system where you can just add a field and then you just select the type of fields. I know that's not readable, but you get text and time and whatever dates and a bunch of other things that you can just use this graphical interface for building your content model. Now I know if you're a developer, you don't need this, but if you're not a developer and you have to interact with a graph database, this potentially I think could be very, very valuable. For example, this showcase that's been used over and over again about the Panama Papers, I think that's giving journalists or other people that might not be developers the power to model their information and to enrich the information and start structuring it using these graphical tools that we've already built in the CMS world might be an interesting win. For data exploration, so enriching the data about entities, ensuring completeness that all the fields are there, that's also something that is trivial in CMSs. You have to program it in your interface if you want to do that with a graph database, sorry to understand because things like sending a form to somebody to fill in data that might be missing. And I think that's what you could do is store some of your information both in your graph database and in your CMS so that you use your relational database for retrieving like the complete set and you use the graph database for figuring out what are the links between the different entities. And this is also another thing like when you have a system like that you can evolve your content model just from the interface. So if you want to rename a field, that is possible. And that's I think much harder in a graph database, okay. So for example, for reporting what you could do, this is again very blurry screenshot of the views module in Drupal. Views is like a graphical interface for building SQL queries in Drupal. And then for massaging it so that it looks the way that you want it to look. So you want it in a table, do you want it just in a list? Do you want your results in a grid? All of these things are possible using views just by clicking on buttons and dropdowns and stuff. So, yeah, you can't really see it here but you can select what kind of content you want to pull in and so on. So what we imagine is that you could run a Cypher query and pull in the results, get the content IDs using the Cypher query and then using the CMS to pull out the relational content from your SQL database, get all that information in, then sort it and form it, well sort it, form it, theme it using the Drupal teaming system so that it looks nice, potentially even export it. There's a bunch of plugins for different export formats and a restrict access and reach data. So that's, yeah. So things that you can do is like filtering, sorting, adding headers, footers, like all of the stuff that's necessary in the CMS. And then there's like third party integrations. Drupal has, like when I took the screenshot and that's a little while ago, had 2,600 modules that are third party integrations like with things like Neo4j or other popular systems. So there's like for example Salesforce, alone for Salesforce is 56 modules. Now some of them will be better quality than others, but at least some of them are going to be really good. So you can like pull information even for like Salesforce and other systems. So that's basically the idea that I wanted to share and maybe get some feedback on. Yeah, yeah, yeah, yeah. So that's a good point. Like what, do you see some, do you think that it would be useful to, yeah, okay, okay. So that's a good point that you would need to do some sort of syncing, yeah. Other, sorry. Well, right now what it does, like the module that we've built is very, very basic, like we spent very little time on it so far. What it does right now is you have something happening in Drupal, you can set it so that it will be scrolled away. So we like the part that we've implemented was the thing before the demo. Everything after it was like, what do you think should, is it something that you want to see built? Is this something maybe somebody else wants to build that we can collaborate on? More kind of like getting ideas out there and then seeing how we can reach out across communities to collaborate on things. Yeah. You are using your graph and you extract the data to Drupal, but how do you feed the graph? That was the module that Thomas showed. So I think there's two ways that you could do it. One, you could have a JavaScript that just runs on the page itself for like just visitor statistics, that might be a better thing, like to just feed it directly. Yeah. In Drupal you can add an article. Yeah. But do you do that in Drupal and in Drupal save to the graph? Yes. So the way that it works, yeah. Right, Drupal right. So what Thomas showed, the module he showed, using the rules plugin, the rules module, rules is like coding without coding. It allows you to say like when this happens, do this. So what he made was when whatever you set happens, like somebody visits a node or somebody creates a node or I don't know, like somebody promotes a node like from unpublished to published, then do this thing. And then the thing that you do, you can set whatever you want using the tokens that he showed. So all these things, all this contextual information that's available to Drupal, you can use to build a SAFRA query to save it into your database. So you're free, it's a very flexible system. So you are not this redirect maybe? No, we do, Drupal is Drupal. Drupal does its own thing. We have all our data there, but then we also save into the graph database. It's not an exact copy because we're not duplicating. It's a system that can be configured to also store whatever else you want to store. What's the events from? Yeah, like for example, events, but it could be even data, even information if you want to. Like somebody changes the data on a certain field and you want that to be saved in your graph database, you can do that. Okay. I'll first go there. Yeah. You want to borrow users that are not used to work with a work interface on that? Why Drupal? Drupal is our thing. That's like, we're Drupal people. I know it's hard to understand, but we can't help it. Yeah. Yes? What occurred to you to store structural information in the graph database, the relationship between data, but store no data in the graph database and only store references to data in the normal database? So I think that could be done. So I think that like you could- Can I solve the synchronization problem? That's a good idea. Yeah. You can use the synchronization problem. So I think that's- So I can borrow her? So the question was, have you thought about only storing relations between entities in your graph database and keeping all the fields and non-relational information in the Drupal database? I think that could be one way of doing it. Probably would already be possible even now, just based on the interactions between things. So yeah. The problem is you need all the information. No, no, okay. You need all the information to write a query in the graph database. So for instance, if you filter on fields, if you want to project fields, if you want to collect information, then of course this information also has to be in the graph. Otherwise, if you have only the structure, then you can of course follow the structure, but you have no means to kind of filter out stuff and so on. So you have to have at least information that you need on- You're right so long if the query system isn't aware of that pointer following. If the query system was aware of that system, then it could follow those references and then- Yeah, you could follow references, but then- The query would be slow. No, no, but either you would have to go back to the relation database to ask for information, but which would not perform at all. But you have to have at least as much information in the graph to write sensible queries. And I think it's really a continuum, right? So I actually don't agree with Kristoff that running a CMS on a graph database is slow because we have a lot of people who actually do it. And it's really fast, but it's a continuum, right? So you need all the other systems that access the relation database. So you can do everything from the one extreme that you said only have relationships in the graph to the other extreme, where you have to complete CMS running in the graph, right? And then it depends on what you want to do, how far you will go, right? And then it's, but all of them are possibilities, right? And I really like it because it makes graph databases in a content more accessible to users and that's something that you all want to achieve, right? And no matter which CMS, I mean, Drupal is an example, but I think it works with a lot of other CMS systems as well. But this would be a really good, also really like a product almost, like a graph database front end product that you can then build up with that and then customize it for you. So to answer a little bit more like on your question, so yeah, we are Drupal geeks and but one of my key messages has been in the Drupal community is that Drupal is a graphical interface. It's like, it's incredible. It empowers people that are not programmers. I'm a buying engineer. Like I did some, I did some programming, but very, very little. I've never really learned ever to code, like really code. I'm a side builder. I click things. And even though that I'm a clicker, I was able to build very complex products and projects. And on a higher level, I can talk with people and understand what they want and then build it for them using graphical interfaces. So I think there's a whole lot of people like that out there that are just not coders and then expecting them to become a coder so that they can use your product. Yeah, but I don't think that's the best thing to do. I think that's one of the key things that Drupal has been very good at. They're like attracting people that might not be coders yet. Like get them excited and hooked on this whole power that they get from this graphical interface. And then they'll start playing around with the code in the background if necessary. And I think that's one of the key things. That Drupal is very powerful at. Yeah? Okay, yeah. We have more time? We have one more? Okay. I have one thing that I want to mention is we have one other partner who builds really cool stuff for users which is not like full-blown applications, but what they do, they use Neo4j and they're similar to what Christoph described, but to build micro-apps. So you must imagine it's like a mobile app for the business. So you're working on a certain part of your business and actually you're not interested in all these other things that the other departments do around you. But usually if you build a business app it has everything, right? But they build micro-apps where you have one app that only shows you your fields, your content, your tasks and your stuff and that's something I could imagine could be easily done with Drupal that you have like pure department or pure use case, you have one micro side kind of that only focuses on this one use case and it's not distracting and works on mobile and all this stuff. And then you kind of really empower users to get their stuff done and I think that's very powerful. I personally, I was talking about last week with one of our colleagues who's working on marketing to use Neo4j for building like personas of the people that are on our mailing list and to like enrich that data using like the Drupal system. So we could do it something like that. So yeah, other questions? Yeah? Yeah, so you're fetching lots of this metadata about this it's right into the graphic piece. I assume quite quickly you get lots and lots and lots of data in there. Have you guys, do you have this in production? Have you done performance? Can you benchmark to see how it's going to react? Currently, yeah. Currently this is just a proof of concept. So we've done the proof of concept together and we want to see, we know that people are using Neo4j in production with Drupal for this kind of applications. We already know for sure that like tracking sessions like a page visits on a highly visited website with millions of hits per, you know, you're going to get in trouble using the PHP system, just that like because we're using caching so that you wouldn't hit PHP. So there's definitely issues there. But there you could do like a mix with some JavaScript in the front ends that does the rights about visits. But I think it's the more the other things like when you're changing the content, those are things that normally you wouldn't get that way. And then there's a lot of contextual stuff inside of the CMS that you would be able to grab this way. And in general, we have actually customers and users that use Neo4j for large. So it's for instance, financial times in the UK uses Neo4j for content recommendations on their website. So they have like millions of users and it works for them. So it's in principle, yeah, yeah. So it's not a problem. It's rather a problem in kind of designing what do I want to store and how do I want to retrieve it and things like that. But that's always use case specific, yeah. But for example, then in financial times in another application, do they use some kind of ETL system to fill in the ground database in relation to that? So they, I'm not 100% sure. So either they use an ETL system or they have in their editing system, it sends events when kind of articles are updated and published. And then the events are translated into the graph database and it's done there. Okay, cool. So we have to switch speakers. Thanks a lot, everyone. Thank you. Thank you.