Pages

Thursday, 22 March 2018

Podcast Interview with Niklas Saers

I had the chance to have a chat with Niklas Saers recently. Unfortunately the recording quality was not always that good - but I think you will be able to make out most of what we said :) ... Niklas works for Unwire, and specialises in iOS development. He is the author and maintainer of a Swift driver for Neo4j (see below) and a mobile-based iOS browser for Neo4j data. Really good conversation - with a Flemish twist. Here it is:

Here's the transcript of our conversation:

RVB: 00:00:07.247 Hello, everyone. My name is Rik, Rik Van Bruggen from Neo4j and here I am recording another episode for our Graphistania podcast. And today, I have, well, should I say a fellow Flemish countryman? I'm not sure really. There is a little bit of history there, right? I've got Nicolas Saers on the phone here.

RVB: 00:00:45.845 Nicolas, why don't you introduce yourself a little bit? What do you do and what's your relationship to the wonderful world of graphs?

NS: 00:00:52.858 Yeah. So I'm primarily an iOS developer, been developing iOS applications since 2008. Released about 40 of them, usually working as a consultant. And, yeah, I got into graphs back in 2011 when I was doing a lot of back-end development, also with Java. I've been working with databases more or less all my life. And, yeah, at the time, we were working with MySQL databases and we wanted to explore how could we make more interesting queries that could give benefits to our users. So I went to Goto Aarhus, which is a conference that was hosted in Aarhus. And I attended a workshop with Jez Humble and Ian Robinson about Neo4j and this was all pre-Cypher. We were working with these data sets they had about Dr. Who. And it was all very interesting and, yeah, lots of fun that made-- it really clicked with me, made really good sense. So been using Neo4j a lot in small projects after that. And, yeah, in 2015, I decided that I wanted to combine this interest in graph database and iOS development a bit more because, at the time, Swift had been announced in 2014, it was all new and shiny, it was very interesting, it's being open-sourced, it's going to go serverside. And, yeah, it's like there were drivers for MySQL and, the regular gang. There's no Neo4j driver there. I said, "Well, this sounds like a good, fun hole to fill. So I looked around if someone had done anything like this and I came across this project called Theo. And it looked a bit abandoned. It had been originally developed by Cory Wiles from Graph Story. And he had been working on it for Swift version 2 at [inaudible] with three [inaudible]. I've been at it a little while. So I looked at it, looked elsewhere, and just before I started writing it, something like that on my own, I saw that, "Oh, he started converting to Swift 3." So I figured, "I'll join that, help him out." And joined and worked together with him on releasing Theo 3.0, which was basically updating Theo to work with Swift 3.

RVB: 00:03:54.913 Wow. That's quite a big journey already [laughter]. But you've expanded that work a little bit by now providing a full Neo4j client on iOS, right?

NS: 00:04:07.428 Yeah, so from 3.0, talked with Michael [inaudible] about it. He asked if it also had Bolt support. And, no, we were just using Rest at the time. But I thought, "Yeah, that's an interesting challenge." So, for 3.1, we implemented Bolt support and improved that a bit for 3.2. And as of last week, Theo 4.0 was released and that has-- instead of you dealing with just Cypher and parsing that, the results you get back, on your own, [inaudible] on your own, it has lots and lots of different convenience methods. Like you can still, of course, write your Cypher, but it gives you good supports in actually parsing the data you get back, so it's very easy to use as a Swift developer. And as part of that work of making Theo 4.0, I decided I wanted to explore what does a Neo4j parser look like on the iPhone? What's native [inaudible]? And that work turned into Graph Gopher. That also was released last week, which is a Neo4j processor for the iPhone.

RVB: 00:05:25.155 I saw it. It's quite, quite impressive. You did a good job there and--

NS: 00:05:28.812 Thank you.

RVB: 00:05:29.188 --we will definitely put some links on the transcription because that seems like something people might want to use a little bit, like for editing the graph and stuff like that, it's really, really easy, right?

NS: 00:05:39.951 Yeah. So I use it a lot myself. It's actually my primary interface to graphs at the moment, which surprised me a little bit because we have all this power with the browser. But just the convenience of having it in your hands, having it with you, makes life-- when I think of, "Ah, I'd like to quickly enter this," or add a relationship, add some nodes, edit some nodes, look something up when I'm just in the living room or coming out of the shower or whatever, eating breakfast, it's just so convenient to have this connection to your graph database with you. It's just a few taps away. Yeah, so I use it a lot myself.

RVB: 00:06:26.205 I can see that, yeah.

NS: 00:06:26.797 [inaudible], so, yeah.

RVB: 00:06:29.609 Fantastic. So tell us a little bit about why you've been doing this work. [inaudible], why do you think it's interesting?

NS: 00:06:41.261 Sorry, I think you broke up a little bit. Could you repeat the question?

RVB: 00:06:44.056 Of course I can. Yeah, no, I'm just wondering why did you get into graph databases and what's the attraction there? Why do you think it's so relevant these days?

NS: 00:06:57.009 So mainly about the relationships because, as I said, at the time, the [inaudible], we were using MySQL a lot. I've been using all kinds of relational databases before that. And, yeah, relational is an interesting word, right, because the relationships isn't really strong there. Whereas the [inaudible] can really easily query, quickly query, where I can put properties on relationships, that fits so well with how I'm thinking about queries, how I want to express queries, like I was having all these joined tables in the middle to try to express this in a relational database. So, yeah, that is my main attraction to it. And the performance when using it is really good. And seeing the data, how it actually lives together kind of as a cluster or as a group rather than spread over different tables, it's--

RVB: 00:08:13.459 It's making the relationships an equal citizen, right? Relationships are as important as the entities themselves. That's kind of the summary, isn't it?

NS: 00:08:23.644 Absolutely. Yeah.

RVB: 00:08:28.243 Pretty cool. And then, are there specific use cases where you think that this is really relevant? Or are there specific types of domains where you think that this is most relevant for you?

NS: 00:08:40.919 I'm having a bit of trouble with that question because it's rather where it's not relevant [laughter]. Because I haven't really been in many settings where I now rather would have a relational database instead of a graph database there. So it's more if I'm going for something where I just need to look up one thing and always only need to look up one thing, I'll perhaps use a key-value store instead. So it's more like, "Am I going to use a key-value store? Am I going to use a graph database?"

RVB: 00:09:20.662 I get that. I get that completely. Yeah, so, I mean, if the domain is not very connected, then why would you even consider a relational database? You might as well use a key-value store or a document store. But if it is very connected, then why wouldn't you use a graph, right?

NS: 00:09:41.430 Exactly.

RVB: 00:09:42.397 It's kind of like that evaluation, I suppose.

NS: 00:09:45.488 Yeah. And now, with Graph Gopher, I think it's so easy to have access to this-- have it with you and be able to easily add nodes and query, follow these relationships, easily edit or add relationships as you think of them. It's so good to be able to go ahead and say, "Okay, well, actually, I want to have this relationship and work a bit with that and then perhaps getting back to a computer later on to flesh that model fully out to--"

RVB: 00:10:27.191 That makes a lot of sense.

NS: 00:10:27.754 "--go over a lot of more nodes, but just to--" if it'll prototype over a few nodes. But at the same time, you have a full Cypher editor there, so you can run any Cypher you like.

RVB: 00:10:43.568 So, Nicolas, let's talk a little bit about the future. What are your plans for both the Theo project, the Gopher project, and for graphs in general? And what does the future hold for you?

NS: 00:11:00.786 The future holds a lot of new software developments [laughter]. Spoken as a software developer, right?

RVB: 00:11:05.707 Absolutely, yeah.

NS: 00:11:06.115 [inaudible]--

RVB: 00:11:07.304 That's a good thing.

NS: 00:11:08.537 Oh, it absolutely is. Yeah, it's good fun. For Theo, we're now at version 4 which very conveniently aligns with Swift 4 and version 3 aligned with Swift 3. So I'm kind of expecting us to keep this trend and having Theo 5 follow Swift 5. There has been a lot of talk about how to work with concurrency in Swift. And Chris Lattner, earlier this year, put forth a document saying how he envisions this going forward. And so the concurrency model we're using, what we're using in Theo right now is that when you make a request, you get the results back, which is either the values you asked for or an error. And so this result type style of query will probably change along with changing-- sorry, I'm going to [inaudible]-- this result set that you're getting back is probably going to change a bit as we're getting async-08 into Swift and so I'm kind of hoping that will go into Swift 5, so that's kind of a change I'm expecting for Theo 5. Graph Gopher, it really depends on how it's [inaudible] at the moment. [inaudible], it's cool. So listening to user feedback, seeing where it'll go from that, based on what feedback I'm getting. It is that moment, primarily made for the iPhone. I'm having some great ideas for how a graph client could be for the iPad because I think the iPad as a tool is quite different from the iPhone as a tool for the kinds of tasks you do for that. Theo is, of course, made also for the Mac and Apple TV and Linux. And I'd love to explore some for the Apple TV. I'm very probably going to explore a Mac client. So no promises here, it's just what I'm [inaudible] exploring. And one piece of work that I am very actively working on at the moment is for Theo for the service client. So it already runs fine on Linux and there are all these great server web frameworks. And one of them, Vapor, which probably by now is not the most popular on, has kind of an ORM where I'm building bindings, if you will, between Theo and that ORM so that using [inaudible] on the server with Swift feels very natural just like it would with any other data source.

RVB: 00:14:21.256 Now, if only that would also exist for Android [laughter].

NS: 00:14:27.720 Well, Neo is filled with Java developers, right? I'm sure I would be duplicating my efforts [inaudible]. So, yeah, I'm dipping in from the iOS side here.

RVB: 00:14:42.930 Got it. Absolutely. That's great.

NS: 00:14:44.067 But any work that would be done in Android, I'd be super happy to look at and discuss a bit back and forth how this could be done on iOS or what learnings we have between the projects to make sure the drives are really as good as they can be. I would like to add that we already do, right? Having a very good chat with Nigel from the drivers team and there's a community effort going on there to make sure that everyone knows what's going on, what's coming up, and get to chat about good experiences on different drivers. So there's already a lot of that going on.

RVB: 00:15:33.272 Great. Nicolas, thank you so much for explaining that. And we'll put a bunch of links to some of your work in the transcription of the podcast. It's been really great of you to come online and share all of that. And I just wish you a lot of programming fun and development fun with Neo4j in the upcoming months and I look forward to hearing more about it.