Ep46: Quarkus Neo4j Application + Development Lessons Learned

In this episode, we dive into the Quarkus framework with a code repository and an article about development lessons learned. Topics covered include:

• 🔗 Building a starter application with Quarkus Neo4j and the Object Graph Mapper (OGM).
• 📝 Exploring similarities and differences between Quarkus and Spring frameworks.
• 📑 Resources for building with Quarkus and Neo4j - blog post and documentation.
• 📚 Key takeaways from an article on developer philosophy, touching on code rewrites, estimation challenges, and the importance of automation and edge cases.

Whether just curious or writing code, we all learn and face similar development challenges!

Episode Transcript

(00:05):
You are listening to the BreaktimeTech Talks podcast, a bite-sized tech
podcast for busy developers where we'llbriefly cover technical topics, new
snippets, and more in short time blocks.
I'm your host, Jennifer Reif, anavid developer and problem solver
with special interest in datalearning and all things technology.

(00:25):
This week I dug in on a major Javaframework in the space, Quarkus.
I explored by building a starterapplication, which I'll fill
you in on my learnings so far.
Next, I came across an article ondeveloper philosophy, and I thought
some of the things there overlappedwell with programming lessons that
I've learned over the years, andeven encountered again recently.

(00:46):
To get this show on the road, Istarted playing around with Quarkus
Neo4j and the Object Graph Mapper, orthe OGM that comes along with that.
Now, first of all, before I dive intothe specifics on all of that, some
of you may wonder what is Quarkus?
Maybe you haven't come across this before.
Quarkus is a Kubernetes native Javaframework designed to reduce an

(01:07):
application's footprint, which isideal for addressing challenges in
deploying, running, and maintainingapplications in cloud-based environments.
Quarkus has become a major player in thelist of frameworks, so naturally I've
wanted to try it out for a while, and Ijust finally blocked some time to do it.
Quarkus and Spring actually area lot similar in certain ways.

(01:29):
First off, they both have an onlineapplication template interface for
defining the project and the dependencies.
For instance, in the Spring world, this isthe Spring Initializr at start.spring.io.
And for Quarkus, this is code.quarkus.ioand it's their template code application

(01:50):
builder that is their bootstrapinterface for creating your project
definition and your dependencies.
You also get some object graphmapper capabilities for both
Quarkus and Spring to automaticallymap your nodes and relationships.
Typically with like an ORM or other typesof mapping libraries, you'll be able

(02:13):
to map your database entities to yourdomain classes inside your application.
And Neo4j being a graph databasehas a similar thing where you have
an object graph mapper library.
If you've dealt with Neo4j andthe Neo4j OGM before prior to
Spring six, the Quarkus OGMwill feel very familiar to you.

(02:33):
However, now, the OGM is baked intoSpring Data Neo4j, where it is not baked
into the Quarkus, starter or dependency.
So you do need to specify that as aseparate dependency, and that's not
available on their code template online.
So you have to specify that separatelyafter you download the zip file.
Slight difference there, but they bothfeel very similar in a lot of ways.

(02:57):
I have a little bit morebackground on the Spring ecosystem.
So playing around with Quarkus havinga bit more experience in the Spring
world, I saw a lot of similarities,which I hope to have a blog post that'll
better outline those things and giveyou a starter for my learning journey.
I also did start a project fora Quarkus Neo4j application.

(03:18):
I did pattern it after a similarSpring application that I have
on my GitHub as well calledthe sdn-coffee-shop repository.
If you are looking for the newQuarkus rendition, it's called
quarkus-coffee-shop, so that all ofus can go back and compare what does
Quarkus look like, what does theSpring rendition look like, and see
the differences and similarities.

(03:40):
I also followed a few steps in a blogpost I mentioned, I believe, in the last
podcast episode that walk through howto create a project using Quarkus and
then specifying the Neo4j dependency.
However, it doesn't go into OGMand that dependency, so I had
to kind of deviate a little bit.
But I found the blog post really helpfulfor just getting the project started

(04:02):
and including the proper dependenciesthat I needed, at least to start out.
The documentation for Quarkus Neo4j felta little bit verbose and over-engineered
for a starter sample application, whichis why I started at the blog post and
then filled in gaps where necessary.
I wanted something that was very conciseand minimal as a starter application.
So I hope I succeeded in doingthat with this quarkus-coffee-shop

(04:24):
GitHub repository.
Also, to springboard off of that,not as a pun intended there.
I will be looking at and have startedlooking at Langchain4j and integrating
that in my Quarkus application as well.
This will be a, probably aseparate repository on GitHub at
some point in the near future.
Spring has Spring AI, and whileyou can incorporate Langchain4j in

(04:46):
Spring, I feel like it seems a littlebit more of a natural integration
to use Quarkus with Langchain4j.
So I'm looking at the twoand comparing some different
things between the two setups.
I will have more to talk aboutin future episodes, hopefully
in the next episode on that.
The article I came across this week wascalled Developer Philosophy, and I thought

(05:07):
this was really interesting becausethere were a few things outlined in this
article that I've learned over the years,and yet I've had to rehash or make those
same choices again just recently, andI'll kinda talk a little bit about that.
The first thing in this articleis that it says, avoid where a
ground up rewrite looks attractive.

(05:29):
I found this really funny because Ijust talked about this in the last
episode where I was going back andforth on whether to rebuild and
rewrite the application for theJava Graph Academy Neo4j online
course, whether I should rewritethat or just do incremental changes.
And I ended up going down the rewritepath initially and just finding that

(05:49):
was too messy and hard to untangle.
So I backpedaled and wentwith the smaller, more
incremental changes over time.
And I just found it funny that this talksspecifically about avoid situations where
a ground up rewrite looks attractive.
Been there, done that.
I just talked about itin the last episode.
I definitely agree here.

(06:11):
If you can make incremental changesor small tweaks over time to
improve and slowly refactor thingsto improve it, I think that is
typically the better way to go.
And the author does say that occasionallya rewrite is the better choice, but
that's just few and far between.
The next thing in the article is aimto be 90% done in 50% of the time.
This goes back to software estimates.

(06:32):
And I've talked a little bit aboutthis before in previous episodes, but
I have recently found this so true.
In fact, just at the end of last week,I was working on a GitHub repository
and I was tweaking some things and bythe time I hit, I guess just before
lunch or about lunchtime, I was like,great, I have pretty much all of, all
of the pieces in place, the skeleton.

(06:53):
I have the application running, itcan connect to the database and so on.
Things are looking great.
I just have a few little finishingtouches to do, and then I should have
my afternoon to devote to other things.
Right?
Well, it ended up being thatthose final few finishing
touches took the rest of the day.
So even though I had a a, a starterapp and everything was going really
well, I thought it'd be wrapped upin a couple of hours, those last few

(07:16):
little things ended up taking so muchmore time than what I anticipated.
It's hard to estimate when things seemto be going so well and 90% of the code
is done, but sometimes that last 10% cantake much longer than what you anticipate.
The next thing mentioned in thearticle is to automate good practice.
People will forget to do things nomatter how many times you tell them.

(07:38):
The only way to ensure itgets done is to automate it.
This is why I think things likebuilding powerful habits and setting
reminders or automating certaintasks or things like auto pay for
bills and so on are just so popular.
It's so easy to forget to do things.
If we automate it, weensure we don't forget.
The next thing I found interesting is thatit says, think about pathological data,

(08:03):
edge cases are a developer's entire job.
And I think this couldkind of go one of two ways.
I think it's easy to fallinto one of the extremes.
Either you don't build any resiliencyinto your systems or your applications,
or you try to hedge your bets andfind every edge case and every niche
little thing you might come across.
I think those two extremes are notgood on either end, but you need

(08:27):
to find somewhere in the middle.
You can't really try to plan forevery outcome, but you should
definitely build some resiliency in.
It's too easy to break things andhave things go wrong very fast if
you don't have some sort of safetynet to catch some of those things.
There are a few other things listed in thearticle as well, but you'll have to check
out the article to get the full list.

(08:49):
This week I delved into the worldof Quarkus with Neo4j by building
a sample application and alsointegrating the OGM library.
I explored how it's similarand different from my existing
knowledge and experiences.
Next, the article I found this weekreinforced some of the choices I've had
to make recently, especially in fallingprey to human nature on rewriting code,
estimating, and remembering things.

(09:10):
As always, thanks forlistening and happy coding.