Whether it’s getting to Mars earlier than expected, or connecting disparate sources of information to take down a massive money laundering network, graphs are powering innovation on a global and cosmic scale.
Tara Shankar Jana of Neo4j had the pleasure of speaking with Kacha Mukabe, who is a grand winner of the 2021 Leonhard Euler Idea Contest for his innovative project using Neo4j graphs at Developers.Zed.
Read his story below!
Tara Jana: Please share with us the inspiration behind Developers.Zed.
Kacha Mukabe: When I started the project for Developers.Zed, I had a couple of ideas for the competition. I was thinking of what I could possibly do with a graph database. I never actually used any kind of graph database before, but the idea of relationships within a graph database was something that interested me.
Here in Zambia, Africa, we do have a lot of developers, but we’re not very visible. As a result, whenever a company is looking for developers, they tend to look outside the country and tend to outsource most of the developer work to American or European countries.
What I wanted to do was make our developer community a bit more visible. The developers here, we know each other, and we meet up every once in a while – but we are the only ones who seem to know each other!
I had the idea to use a graph database, which works in relationships, to basically model the same way we know a developer who has some skill that a customer or a client in Zambia might need. From that relationship, the developer would then know a different developer that has some different kind of skill.
I thought if you could create an application that has a database with these relationships, all you would need to know is just that one person, and you’d be able to follow up and connect with different people through their relationships.
TJ: Nice! It sounds a bit like a LinkedIn for Developers?
Kacha: Yes, it would work a bit like a LinkedIn for Developers, connecting people based on who they know. Someone will be able to go on there, search for somebody – they just need to know one person – and then they’ll be able to find the whole community of developers that we have here on the web application.
TJ: To have recommendations through different developer relationships and find the expertise the client is asking for is a brilliant use case. I would love to learn more about how you built this application, especially with you being brand new to graph databases, which is so inspiring!
Could you give us a glimpse into the code, the way you used to build the app, and some ideas around how you connected the front-end to the backend?
Kacha: Before I joined this competition, I had never heard of Neo4j and hadn’t used graph databases. I had used GraphQL in some other applications, but I was basically starting from scratch. I built this application using GRANDstack.
Here I have a small demo of the actual application:
TJ: On the database side, can you shed some light on how easy it was for you to interact with GraphQL using Neo4j?
Kacha: For the database side, I actually picked up the Cypher language and the Object Graph Mapper (OGM) that Neo4j uses in about a week or two. The first week, I was looking through documentation and examples of how Neo4j can be used. In fact, within the first week, I had the first part of this demo basically done. Within another week, I was able to do what I wanted to in terms of creating relationships.
I found that it was actually easier than I expected. Looking at it from the outside, I was a bit intimidated by graph databases and the Cypher language. It’s a whole new way to interact with data, very different from SQL. Once you dive in, it is pretty easy to pick up. The query languages just made things a lot faster to do. So within two weeks, I had my demo up and running.
TJ: That’s amazing to go from having no graph database background to – in just two weeks –having your application up and running! It makes us feel so proud, both of the libraries we’ve released and the overall adoption of graph databases.
Certainly it was easy for you to build, but I’m sure there were some challenges along the way. Can you share any challenges you might have faced?
Kacha: When it came to challenges, it was my first time working with the Cypher language. I went pretty deep into understanding how the Cypher language works, both in terms of how I was going to create queries and updates and how I would connect the front-end to the backend. I had a couple of challenges with reconciling how to do the queries using GraphQL.
Before this, I was more used to something like Java’s Object Relational Mapping – or ORM – but I found a tutorial and documentation for OGM or Object Graph Mapping. A challenge that I faced was using React, which is not something I use every day. GRANDstack was actually pretty simple for me, and Node Package Execute (NPX) creates a GRANDstack app, so everything was already set up for me. I just needed to figure out what I wanted to do.
TJ: You make it sound so easy, but I’m a hundred percent sure there was a lot of thought and work that went into it. Thank you so much for putting it together and going through those learnings and challenges. Is the souce code going to be on GitHub repo, and can anybody go and quickly take a look to see how you built it?
Kacha: Yes, the source code for the front-end and the backend are completely open source on GitHub. My GitHub username is KachaMukabe, and you can check out all of my code there. Everything is pretty self-explanatory if you have the code. With that and the documentation next to you, you can basically create Dev.Zed with your own use case.
TJ: That’s a good point! People may have a different problem to approach, but maybe they will have similar schematics and can apply your thought process.
Thank you for your innovative submission and for sharing your thought process, challenges, and journey. It’s also always good to hear feedback on our products and the process. Again, I am super pumped to see your application and see the community you’ve brought together.