Podcast Interview with Tim Nash, independent "Wordpress & more" developer

Yeah - I love doing these podcasts. I really do - even though I sometimes need to scramble to find the time to do them - but it's totally worth it. Because very often, I get to talk to some really, really interesting people. This conversation is another one of those occurrences - the conversation with Tim Nash. Tim has been working in the Wordpress world for a long time, and seems to be infected/affected by the Graph Bug - and is preaching the graph gospel to the Wordpress aficionados. Super cool - here's the conversation we had:

And of course 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 our Neo4j Graph Database podcast. Today I'm joined by someone who is probably in a much nicer location than I am, out in the Yorkshire Dales, Tim Nash. Hi Tim.

TN: 00:20 Hi Rick.

RVB: 00:21 Hey.

TN: 00:21 Thank you for letting me come on your show.

RVB: 00:23 Well, thank you for joining us. It's always great when people make the time. I know everyone's busy. Thanks for coming on. Tim, the first question I always ask everyone is who are you, what do you do, and what's your relationship to graph databases? Do you mind telling us a little bit more about that?

TN: 00:39 My name's Tim Nash. I primarily run training and consulting development services on timnash.co.uk, get the plug in early. I work-- [crosstalk] [chuckles]. I'm primarily an E-commerce and security consultant. However in the last few years I've been drawn into the world of Wordpress, which is a content management system, and isn't my natural home, and isn't the natural home for many developers, so I've been working to try and change that and show the development opportunities there are within Wordpress, and the content management system in the community. I do stuff, is what I describe to people who ask me what I do. And in reality, I used to write code and now I tell people mainly how to write code.

RVB: 01:27 Very very cool. How did you get into graph databases? What's your relationship to that wonderful part of the industry?

TN: 01:34 About six months ago, I was sitting watching a video from a conference about in-game economics, and it was all being modelled using Neo4j. I watched it and thought, "Do you know what? That's really cool, and I want to have a play with it." So I had a little side project that I was mucking about with, and started to just play around with Neo4j, and thought, "This is really really useful and really interesting," and it sort of developed from there. The more I played with it, the more I thought there's opportunities to use this in a wider platform, not just inside my little projects, and started thinking about how we can use that potentially alongside Wordpress projects.

RVB: 02:19 That video that you watched, that's from Yan Cui from Gamesys I think. He's been doing that talk on a number of conferences among which at Qcon in London this spring, and he was actually one of the first guys that came on the podcast, so there's an interesting link there.

TN: 02:38 In fact, it was that conference video that I was watching.

RVB: 02:42 Was it [chuckles]?

TN: 02:43 A nice full circle.

RVB: 02:45 Fantastic. So where's the link with Wordpress then? How do you see that link then

TN: 02:52 For those people who don't know Wordpress, as I say, is a content management system. It's built on a pretty standard LAMP stack for most parts. In particular it's using MySQL and PHP. Now, MySQL, while lovely as a relational database, bizarrely in Wordpress, isn't really used as a relational database. They have this idea of posts and pages of custom post types, except they all sit in the same table, posts and post meta. And individual posts and custom post types of pages have no natural way within Wordpress to actually model relationships.

TN: 03:31 So you're sitting there going, "Right, I need to link post A with post B and say what that relationship is." There's no way to do that within Wordpress. Lots of developers have built their own hacks around, but as you can imagine, when you've got pretty much a flat structure like that, any attempt to develop this is going to result in a hack, and you're going to end up with a huge pile of extra data sitting in the database that really doesn't need to be there. And it's just really CPU and intensive to try and get this data out.

RVB: 04:04 Especially on larger sites, I suppose, right?

TN: 04:07 Yeah. If you're talking a few hundred posts, it's fine. But if you're talking company's like Wired and the New York Times and similar, who are using it as a traditional publishing platform, they have tens of thousands of articles. Then you've got sites that are using it as just a pure database storage system. One of the projects-- a side project from one of the Human Genome people, actually published their data through Wordpress, so they have not tens of thousands, but hundreds of thousands of posts. And very quickly, those databases creak.

TN: 04:41 So I've started looking at the graphing side of things and thought, "Well, what if we keep the relational database, but just push this data into the graph database, and then go-- we can query the graph database with the relationship and then pull that concept back out of the relational database." And found that worked really well. And as I'd already started playing with Neo, I stuck with it.

RVB: 05:05 Very cool. I think it's a super interesting way of doing things right? We see that all the time. That people actually use the graph database as a compliment to their existing relational database systems. It's a really nice fit right? So you went about this about six months ago you started this, and then where is that project now? Is it going anywhere?

TN: 05:28 Six months ago I started playing with it, and at the time I didn't have a big project to hoist this upon, so it was very much my own playing around, so when you don't have a project that you can actually immediately use it on, what you do is you jump up and down and shout a lot about something until someone gives you a project that you can use it on. So I spent the last six months or so, mainly at conferences and going around and just generally talking about this idea of graph databases.

TN: 06:01 I've been quite lucky in some respects that while perhaps boo and hisses from the Neo community, obviously Facebook's announcements with their own graph database bits has peaked the interest of some people. So I've been able to piggy back on that, and say, "But look, here's something that's actually working and already exists." So at the moment, it's been very much about looking at how we can do this sort of thing inside Wordpress, how we can push that data across, and getting some of the larger projects to at least consider this.

TN: 06:35 Now, there is a lot of precedents, because two years ago if you uttered the word ElasticSearch at a Wordpress conference, they would just look at you and go, "What sort of black-magic is this?" And now, things like ElasticSearch, is considered a almost mainstream compliment to a Wordpress site. So we're hoping to be able to just start introducing our graph databases and use the same sort of way that we interact with ElasticSearch, and bringing that to compliment with graph databases. And hopefully that means that Neo will be sitting at the top of the list, as it's the one that's first through the door, if you like.

RVB: 07:14 So how would it work then? Every time you would update something on the Wordpress site it would automatically propagate into the graph database? Or would it be kept in sync in some way? What's the idea there?

TN: 07:27 Wordpress uses actions and filters. So basically, every time you do an action on the site, there's probably some sort of event listener that's attached to it. So with that event listener, we can push that data across. You'd probably have it as a-- in what I've been testing, it's always been a one-way push. So we're pushing data into Neo, and then querying Neo. So when you hit publish on a post or even when you hit save on a post, that data and associated post meta, so think, important bits and pieces that you want to query, get pushed across over into Neo. And then rather than querying Wordpress via its normal search and loop system, you actually make the queries directly to Neo, which would return you back a little bit of the information that you've already given it. But more importantly, will give you back the post ID, which you can then call through your relational database.

RVB: 08:22 I think there's also some interesting applications afterwards right? If you would, for example, use the data in Neo to figure out the relationships between the documents, recommends new documents, new pages. All that kind of stuff becomes possible once it's in Neo, right?

TN: 08:39 Yeah. The very first example I did of this within Wordpress was for related posts. And to be able to define related posts and let users define what they considered to be a related post. So some people might think that because the posts are written by the same author, that means that they're related, which obviously it could be. But others could be looking for more complicated relationships between various tags, or even are these posts as part of series, which actually is something that you think should be really obvious and easy to build into Wordpress-- even the ability to say, these four posts belong to this series and should always be grouped together, is something you can't easily do. But when you push this into a graph database, saying these things are in a group just becomes super easy.

RVB: 09:33 Cool. So let me ask you a little bit about the future. Where do you think this is going then? Where do you see this evolve within the Wordpress world, or maybe even beyond that?

TN: 09:46 Hopefully within the Wordpress world, we'll start seeing some actual production uses of graph databases taking data from Wordpress and manipulating using them. There are some limited experiments going on at the moment. There is a couple of small production sites that are making use of it, but it's very on a small scale at the moment, and we haven't got our big publishers doing this yet, but there's a lot of interest in it. So, one of the things that really helps adoption particularly in the Wordpress world is through the use of plug-ins. So the next step is to get a group of us together to actually build a common framework for plug-ins, so that we are not basically having to recreate the push and the sync aspect of this every single time. Again, there's good examples of this from the work that's been done with ElasticSearch through several companies who operate inside Wordpress communities. So hopefully we'll see that develop and we'll be seeing much more sites that are making use of graphic databases in general, but in particular Neo, over the next few months, and into the next year. As for that, who knows.

RVB: 10:57 [chuckles] Exactly. Well you know, maybe we can get you to talk about your work at some point, at one of the meetups as well. That would be lovely as well, if you find the time at one point.

TN: 11:08 That'd be great.

RVB: 11:08 Sure. Cool Tim. We're 11 minutes into the podcast so I think we're going to wrap up. We want to keep these things short and snappy. So thank you for taking the time, really appreciate it.

TN: 11:20 No worries.

RVB: 11:21 I hope to meet you at some point in the future.

TN: 11:25 Okay. Lovely to meet you.

RVB: 11:27 Thank you, 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

Podcast Interview with Axel Morgner, Structr

Here's a podcast episode that was long overdue: I finally got to speak to a long time evangelist and community member, Axel Morgner. We met a long time ago in front of an illustrious London Pub, and have been working together on a number of projects, activities and ... stuff. Over the years, Axel always impressed me with his unbelievable achievements on Structr, his fantastic enthusiasm and just sheer impressive expertise on all things Neo4j. Listen to the story here:

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