Here's the transcript of our conversation:
RVB: 00:02 Hello everyone. My name is Rik, Rik Van Bruggen from Neo Technology, and here we are again recording yet another episode for our Graph Database Podcast. Today I'm joined by someone that I should have invited a long time ago. It's probably one of the first people that I met in our wonderful community: Axel Morgner from Germany. Hi Axel.
AM: 00:24 Hi Rik, how are you [chuckles]?
RVB: 00:25 Hey [chuckles]. Again, I need to apologise. I should have invited you a lot earlier, but you know how these things go, right [chuckles]?
AM: 00:32 No worries. I think now it's the perfect time for a podcast. I have some news and I'm relaxed after vacation.
RVB: 00:42 [chuckles] Super. Axel, we've known each other since I think FOSDEM in Brussels two or three years ago. That's the first time we met each other. But many people might not know you, so do you want to introduce yourself a little bit and tell us who you are and what do you do?
AM: 00:58 Yes, sure. But I think we met in front of a pub in London after a meetup.
RVB: 01:05 [chuckles] That sounds likely as well [chuckles].
AM: 01:10 [chuckles] Yeah. I'm Axel Morgner from Germany. I'm living and working in Frankfurt, and I'm the founder of Structr, our software project and also our company.
RVB: 01:25 And Structr, that's been around for quite some time. I remember the days when people thought it was a content management system. But it's much more than that now, isn't it?
AM: 01:37 Yes. Yes, it has become more a graph application platform. That's what we call it now. It has started out as a content management system when we first had the idea of creating something new based on a graph database on Neo4j in 2010. The first attempts were made back then. But over time, we saw the potential in graph databases and Neo4j in particular to create much more. So the short story of the evolution of Structr: It was we wanted to build a content management system in the first place. Then we saw that we could do a lot more stuff if we make the back-end very flexible.
AM: 02:32 And then we came up with this flexible schema or data-modeling tool, which was just added for our own projects - to gain speed in the projects - and then we just generalised that into a-- yeah, we called it Data CMS and now we call it Graph Application Platform because you can do a lot of things in terms of application programming without having to code as much. So you just put the data model in the graph as well, and there's components in Structr which create a [restful?] API and all the stuff out of it. So we have a lot of things that make your lives easier.
RVB: 03:22 Well, I've seen you do the demo, and there's a couple of recording even, aren't there? How to build an application in a couple of minutes. It's really impressive actually. I'll put the link to that on the publication of the podcast as well.
AM: 03:38 Thanks.
RVB: 03:39 So how did you get into the graph story, Axel? And why did you get into it? Can you tell us a little bit more about that?
AM: 03:48 Sure. The history or the-- my background is I'm a physicist, and for me, software are tools to solve problems. And after my studies, I started working at Oracle, doing all this relational-database stuff and so on. So that was in 2000, and just for two years. After two years, I was kind of fed up with all this, let's say, heavyweight-proprietary-enterprise-database stuff. But nonetheless, we had a very smart team in one of these projects and we decided to create enterprise content management system based on Oracle, and we founded a little company. And after some years, I thought it's too heavy and too boring and too proprietary, and I wanted to do something new.
AM: 04:52 And there were some NoSQL databases around and I started looking around and thought, "Okay. If I want to do something with content management where we have trees - so page trees, five hierarchies, organisational trees - let's try it at graph database. And Neo4j was in Version 1.0 - this is the version I started with - was major and stable enough to give it try. And it was embeddable in Java. So I'm kind of a Java hacker. And that was the story. It was a perfect fit to just map hierarchies and trees in a graph database.
RVB: 05:41 But as I recall it from the content management days - if I can call it like that - it was also about the performance, right, that you were able to get out of it. Because I remember you telling me that in old-style content management systems you needed caches and all that wonderful stuff and [chuckles] that basically, if you just store it as a graph, you don't need that anymore.
AM: 06:05 Exactly, exactly. So it has turned out that it was the best decision I or we ever made, in technical terms, to go with a graph database and with Neo4j as well. Not only in technical terms; communities and the people are wonderful too. But the performance is a very important thing. So we store everything in the graph. For example, take the page tree. Normally, if you want render a webpage, you store HTML, basically HTML in your database. If you have a content management system, you split up the HTML page into small pieces. And the more flexibility you want to have, the smaller the pieces have to be. But if you then have very many small pieces of HTML and have to join them together for rendering dynamic pages, you have to do a lot of joins in a classic or a relational database.
AM: 07:14 And we all know that this gets slower and slower the joins you have to do and [the?] more data you have in your database. If you do it in a graph, you just start at the page note and just traverse the page tree over some relationships, and you just take the [wave?] through the page tree - your requests parameters tell you - and then you just render the page output of this together and you can do that in a couple milliseconds. In a classic content management system you can't do that. You can only cache portions of your page to get a reasonable speed, but if you for example have a protected page - so you have users who log in and everyone sees different content - then you can't do that anymore; you can't cache the dynamic content for each person.
RVB: 08:13 yeah that makes sense...
AM: 08:15 So it's much quicker than a classic content management system.
RVB: 08:19 Super interesting. And I encourage everyone to take a good look at Structr if you're doing content and web application development; it's really lovely. So Axel, where is this going? What's this story both from a general graph-industry perspective and from a structure perspective? How do you see the future?
AM: 08:43 I personally see a very bright, full future for not only Structr and Neo4j as I think the best graph database on the market, but also with the graph database's space in general. Because it's my belief that graphs or graph databases are the best-- not tool, but technology to really map the reality in an electronic structure, if you want ...
RVB: 09:23 Reality is a graph [chuckles].
AM: 09:24 Yeah, reality is a graph. The best abstraction of reality is graphs. And so the best tool to map this abstracted reality to software or to memory - that's basically what we're doing - and calculate on that data is a graph database. So we have an interesting roadmap. We're about to announce our upcoming release, 2.0, which will contain very interesting features. Like on one hand, we're expanding a little bit into the enterprise content management market, so we're creating a much better file interface: a completely revamped files and folder management user interface. And it comes with the possibly to use SCP or SSH to just lock into Structr and do file operations in it. We are currently implementing the CMIS: Content Management Interoperability Services, I think it's called. It's a very broad industrial standard for interacting with content management repositories. We are implementing that based on our layers. So that will put us into the-- let's say we're approaching the larger ECM vendors or systems like Documentum and Alfresco, and so and so on.
AM: 11:07 And on the other hand, our mission, our long-term goal is to make application development much easier. So we want to reduce the friction you have as a creative person or as a manager in your company to create an application with the knowledge and the data you have. So the friction is introduced by developing hurdles like you have to choose a programming language, you have to set up the thing. Or maybe you can't program or you don't like to program; then you have to find developers, you have to pay them, and so on. It takes times and it's expensive. We want to fill the gap between the content management system and the development framework with Structr. So make it easier to create applications just by drag and drop, and put in some data, so that everyone can create mobile and web applications. That's our long-term vision, I would say.
RVB: 12:16 I mean, that's like a wet dream [laughter].
AM: 12:19 [chuckles] Yes, it is. I know, but I mean--
RVB: 12:22 It sounds really great. And you know what? I can't--
AM: 12:23 --you have to have ideas like this to keep you motivated over such long time. So we won't stop [chuckles].
RVB: 12:31 I agree. I agree. That's great. That's great. Wonderful. Well, Axel, it's been really great talking to you, and as you know, we want to keep these podcasts digestible length so I'm going to wrap up now. I really want to thank you for coming online and talking to us. And I look forward to seeing you at one of the future events and community events, right?
AM: 12:58 Thank you, Rik, for this wonderful podcast series and the opportunity to talk to you. I think we will see us at the latest at the graph connect in San Francisco, I hope.
RVB: 13:08 Absolutely. We have to meet up there [chuckles].
AM: 13:12 Yes. [crosstalk]
RVB: 13:13 All right. Thank you, Axel. Have a nice day.
AM: 13:16 Thank you too, Rik. Bye bye.Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!
All the best
Rik
No comments:
Post a Comment