One of the many issues with Spring is that abstractions it provides are extremely leaky [1]. It leaks frequently and when it does, an engineer is faced with the need to comprehend a pile of technology[2] that was supposed to be abstracted away in the first place.
This is the best I can do for rationalizing Spring.
Also Spring is a kind of franchise or brand, and the individual projects under the umbrella vary a lot in quality.
Spring has more “synergy” in a sense than using a bunch of separate libraries, but because of that it’s also a big ball of mud that your code sits on top of, but isn’t on top of it in the sense of being in control.
Want to swap out your client for a different one? Good luck - it probably expects a completely different schema. Trying a new model? Hope you're ready to deal with a different chat template. It felt like every layer had its own way of doing things, which made understanding the flow pretty frustrating for a noobie.
So I sketched out a diagram that maps out what (rough) schema is being used at each step of the process - from the initial request all the way through Ollama and an MCP server with OpenAI-compatible endpoints showing what transformations occur where.
Figured I'd share it as it may help someone else.
https://moog.sh/posts/openai_ollama_mcp_flow.html
Somewhat ironically, Claude built the JS hooks for my SVG with about five minutes of prompting.
I'm also getting more into the lower-level LLM fine-tuning, training on custom chat templates, etc. which is more of where the diagram was needed.
upghost•6h ago
[1]: https://github.com/nexusflowai/NexusRaven-V2
max-privatevoid•5h ago
upghost•4h ago
You don't really have to parse the output, Python already has a parser in the form of the AST library[1].
But I get your drift. Depending on your workflow this could seem like more work.
[1]: https://docs.python.org/3/library/ast.html#module-ast
max-privatevoid•4h ago
What I don't want to happen is for some shitty webdev who writes an AI client in JavaScript to be forced to write a custom parser for some bespoke tool call language (call it "MLML", the Machine Learning Markup Language, to be superseded by YAMLML and then YAYAMLML, ...), or god forbid, somehow embed a WASM build of Python in their project to be able to `import ast`, instead of just parsing JSON and looking at the fields of the resulting object.