I thought Babashka would be ideal for writing small "Tool servers" for AI, except tool servers are expected to serve an OpenAPI specification. I'm not in the mood for manually maintaining an OpenAPI spec in parallel with the code, but it also seems that Reitit, which could auto-generate such a schema, doesn't work with Babashka. I haven't been able to find anything to get my hopes up, any thoughts /experiences in this regard would be very appreciated.
On the surface it feels more compelling to write and maintain an alternative routing lib (with few to no dependencies), than maintain a fork of Babashka for a single specific purpose. I would rather put my time into something more widely useful.
The text missing was just me not cleaning up my unessesary complaining about Reitit π Reitit is not made for Babashka, and probably nerver will be. Looking to Reitit for a solid solution in the Babashka world, will likely have me waiting for a long time. Thanks for the link to the multipart project... That is very interesting.
Adding a routing lib to bb has been asked multiple times and I think reitit is perhaps the most widely used one nowadays, but what's holding me back from adding it to bb is the many transitive deps it brings with it
Given that martian works in bb, perhaps it can be used as an inspiration for what you want. Instead of a client it should generate a server ... how hard can it be? I don't know :)
I totally understand that π And I think it is very important that you keep being very protective about what to include Babashka. Babashka is also widely used, so why is it Babashka that needs to bend.
I am not done looking... I just dont think Reitit is the way to go. I want to explore if I can make something using the same (or at least very similar), data structure for routing but without all the transitive dependencies (including their own stuff). Something that might only support a subset of features π€·
Would it make sense to suggest Reitit to include a reader-condition specific for Babashka, if such a thing is possible: https://github.com/metosin/reitit/blob/7520d20f123c801d5f8bf9689301ccadd1dae4a5/modules/reitit-core/src/reitit/trie.cljc#L343-L344 It doesn't fix everything related to Reitit, but I think it would make Reitit core work in isolation in Babashka, which is a step closer.
You could fork reitit and see if that works
Would it look like this:
(defn compiler
"Returns a default [[TrieCompiler]]."
[]
#?(:cljs (clojure-trie-compiler)
:bb (clojure-trie-compiler)
:clj (java-trie-compiler)))Yeah
Hey, I donβt know if it helps but Martian works with bb and does have some OpenAPi stuff I recall correctly
i think the ask here is to generate openapi yamls from route definitions which reitit does, but maritan is more client side; given an openapi spec, it can make clients and functions from it. if https://github.com/askonomm/ruuter emitted the openapi yaml for the route tree, that would solve this issue here
Ok yeah we donβt have that in bb. Maybe reitit should be added to bb at one point β¦ π€
@jacob429 What you are after is something else than an mcp server right?
yes, I wanted to create an API server that easily included an OpenAPI specification (because AI tools look for this automatically), and I want to avoid having to maintain specification and code in two places (these things have a tendency to diverge). I'm not advocating for including Reitit... but I would love for my use case being easier π The method is less important.
is there an example of this in JVM Clojure?
I didn't look very thoroughly, because I hoped I could jump right into Babashka. But I will later and come back with what I find.
I've created a demo babashka script with a Reitit router by monkey patching the ns reitit.trie and the function reitit.impl/fast-assoc https://gist.github.com/jeroenvandijk/cb5f3411943c24dc68b225f34a3e474b
Credits to @jacob429 for finding the problems. Maybe you want to do a PR with Reitit?
@jacob429 I did a quick try with the your openapi gist and I got it working without the muuntaja json encoding, maybe that can be solved in a different way https://gist.github.com/jeroenvandijk/0ee5e2d0bb0b396e41c605c99b5f7100
Nice π
amazing
I've tried to summarize everything I've found while analyzing what is missing to use Reitit and its OpenAPI library in Babashka: https://gist.github.com/jacobemcken/441244529a4d68e27db514fe7fa7ae7e I will be going to bed now, but I will keep an eye on this thread both during the weekend and next week if you have some follow-up questions or requests.
Thanks. The text seems to break off here: > Reitit dependencies are entangled with
For file upload this might work: https://github.com/Frozenlock/ring-multipart-nodeps
of course you could also make a fork of bb and include custom dependencies. someone has done that before: https://github.com/kloimhardt/babashka-web