Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(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 data,learning, and all things technology.
(00:26):
I learned more new things this weekas I poked around on Langchain4j
and some video recording.
I found the latter is reallychallenging to find a quiet block
of time when family is home in thesummer and you have a squeaky dryer.
And even though I present all the time,something about recording is a little
less comfortable than live for me.
I guess that means I need to doit a bunch until it becomes easy.
(00:47):
In this episode, I'll give updates on myexploration into Langchain4j, as well as
chat about another article I found on MCPand security and how a new authorization
spec is impacting enterprise developers.
It's always interesting that technology isbuilt for developers to use, but sometimes
misses ease of use features that actuallymake it easy for developers to use.
The end result high might be worthit, but getting there ends up a
(01:10):
series of varying emotional states.
Leaves you questioning whether thebenefits are truly worth the hassle.
Anyway.
The first topic up fortoday is Langchain4j.
I built a sample project usingQuarkus Langchain4j and Neo4j.
I will have the GitHub repositorylinked in these show notes, and again,
I also have a Spring AI counterpartthat you can compare just to see
(01:33):
how the two technologies frameworksstack up against one another.
My initial thoughts just workingon Langchain4j this week is that
it felt similar to my somewhatlimited experience with Langchain.
I can't exactly put my finger onspecifically what the similarity
was there, but each piece of thefinal LLM call, things like the
(01:54):
configuration, the model, et cetera,was all in a single chained block.
While you can do this inSpring AI, I don't feel like
it's the default mentality.
Or maybe it's because I'm more familiarwith the Spring framework and traditional
application development through the Springecosystem where this feels more similar
to the Langchain ecosystem, I guess.
(02:17):
Langchain4j does abstract things awaythough, just like Spring AI does.
But there wasn't as much room todisentangle specific pieces if you
needed to customize a specific bit.
For instance, the process for justgeneral GraphRAG is typically to
call a vector similarity search.
Then take those results and pass them intoa retrieval query for a graph database.
(02:39):
In Spring AI, you can tease out thevector search and then manually pass
the results of the vector search to aquery that you run against the database.
But Spring still abstracts the model,the vector store, and question embedding
bits into beans that just get autoconfigured that you can still use.
You just dismantle the vectorsearch and the LLM call piece
and customize those bits.
(03:00):
However, in Langchain4j, Icould not find a way to do that.
In order to avoid sending the call,which does everything, including
the question embedding the vectorsearch, the prompt stuffing, and
the final LLM call all together, Ihave to write all the boilerplate
to just customize one piece of that.
So I have to write the code tocreate the embedding model, the chat
(03:23):
model, the vector store Beans plusrun each of those steps manually
using the boilerplate I've defined.
There was no way I could see to usethe beans that were already defined
or auto injected and just customizethe individual pieces that I needed.
Maybe I'm missing something, butthis approach felt pretty clunky.
I included, in the application, aplain LLM call, a vector rag call, and
(03:47):
a graph rag call, and there ended upbeing a lot of extra clutter code that
was needed for the graph rag piece thatwasn't necessary for the other pieces.
I ended up cluttering up the one resourceclass with lots of extraneous bits, some
for the vector call, some for the graphcall, some for the LLM call, and not all
of it was relevant to all the pieces.
(04:08):
I think if I were to do this ina production style application
or something that was much morecritical, I would separate those out.
I'd split into separate files fora vanilla vector call, and then a
separate file for a GraphRAG call.
Langchain4j is also available for use inspring and a few other frameworks as well.
This just didn't seemlike a natural fit to me.
(04:30):
I would, automatically be drawn toward thetools within that own specific ecosystem.
That's why I combined Quarkusand Langchain4j this round.
Langchain4j Quarkus, though,is pretty thinly documented.
It relies on the Quarkus side, which Ihave found to be pretty sparse on the
documentation, which is not overly unusualfor documentation in general anyway.
(04:50):
I'll continue to play with itand I'm sure improvements are
coming quickly, as always.
The article for today.
I have talked a little bit aboutin previous episodes that MCP,
the benefits and then some ofthe gaps that it still has.
One of those being security specifically.
And I found an article on a newauthorization spec, and the article
(05:12):
is titled The MCP AuthorizationSpec is A Mess for Enterprise.
The author talks about how securityhas started to be implemented in MCP.
So one of the original gaps wasthat there really was no provision
for security practices inside MCP.
Now that is starting to bedeveloped and those gaps filled.
(05:33):
However, what's there so far is notideally designed for enterprises
and their best practices.
I really enjoyed how this articlesteps through a process or how a
particular piece of the architectureworks, and then discusses specific
organizational practices thatshow you why it's problematic.
It made it really easy to see notjust from the playground developer's
(05:55):
perspective, but also from theenterprise developer's mindset and
understand why those with businessdecision powers might be a bit hesitant
to adopt the things as they are.
The new spec puts the securityburden on each MCP server to create
and manage tokens, and the authortalks about how that impacts the
way enterprises typically architectauthorization, as well as creates a lot
(06:19):
of overhead that defies organizationalpractices as they stand today.
Mostly the article sums up that thecurrent spec isn't designed for enterprise
use, but as with most things, it's stillin active development and we'll hopefully
see improvements in the new future.
The thing that I really liked about thisauthor's take on it is he wasn't saying
again that this technology isn't valuable.
(06:39):
It just, right now, the things thatthey're trying to fill the gaps with
don't necessarily take big companiesor enterprise developers into account.
So they end up having to doa lot of workarounds or go
outside of business practice.
And if you think about the additionaloverhead that's going to add, that's
going to be a hesitation point for a lotof enterprises and businesses in general.
(07:01):
And again, that may change, it'll adaptand improve as people start either
complaining or submitting requests orfeatures or prs to fix those things.
But that's going to take some time.
Technology continues to evolve quickly,so the same frustrations and gaps
that exist today may not tomorrow.
As I learn, I'll continue to pass alongany tidbits that I pick up, and I'm
(07:23):
always interested in learning from othersto fill in on the things that I miss.
Thanks for listening and happy coding.