I'm on my Christmas holidays and have some time to catch up on personal projects.
I've been looking at Jellyswarrm to aggregate Jellyfin accounts for clients that don't do this (most don't) and ran into problems with the Roku client which somehow didn't get the aggregated feed, but instead the feed from only one upstream server.
After finding the cause, which is due to case-carelessness on the clients (I suspect it is down to the case-insensitive windows legacy of Jellyfin via it's Kodi and XBMC origins which meant that clients didn’t have to be careful about case of path elements), I was looking for a neat solution to have axum::Router make case-insensitive path matches.
I've worked with Rust before; I wrote a controller for the Obsbot Meet 4K USB camera in Rust (as well as an Obsbot extension for guvcview in C, now upstream) but I knew I didn't have enough experience to make the right architectural decisions here.
So I worked with ChatGPT to explore the possible solutions and come up with something non-hacky that I wouldn't be ashamed of and that the Jellyswarrm maintainer might accept.
I’m impressed with the ability of ChatGPT to give reasons for it’s recommendations.
First it recommended middleware to lower-case incoming request paths, which I don’t like as it encourages bad client behaviour by confirming lower-case endpoints in the source.
So I asked: Can I make use of some kind of trait or mixin declared on the axum router so that each registered route also registers a lower case version automatically? I was somewhat skeptical of this denial, but I took it at face value initially:
Short answer: no — Axum does not provide a trait, mixin, or hook that lets you intercept route registration and auto-register transformed variants (like lowercase paths).
Longer answer: you can get very close with a builder pattern or macro, but not with a trait implemented on Router itself.
I think it was more fixated on not changing the source than I was, saying that even if I defined a trait I would have to change the calling-points to call the trait functions (which I was actually happy to do).
So we then looked at wrapper compositions, and macros, as well as possibilities of redirecting legacy clients on case-mismatch instead of insensitive matching.
Then I went back to the trait option, asking: Lets look again at the answers to the trait/mixin question. Is there a way to extend the axum router to allow a new function to be used in the builder constructor technique while still allowing all the existing builder methods to work?
(This was my first foray into generic traits, and I wasn't really experienced enough to get it right).
So we set about to do this with extension traits, adding an alternative router, nest, and merge function which would be case insensitive.
This was the second major benefit of ChatGPT as it identified that nest and merge (merely as a semantic marker) would also need a case-insensitive implementation – something which I would not have picked up on.
The first major benefit was when it identified that simply lower-casing path elements passed to the route() function would break router parameter names contained in { } by lower casing those names too.
The third benefit was when I asked it to write a function to perform this lower-case but preserving parameter names in the { } braces; which it did very nicely. My rust is too rusty for me to do it that quickie.
Over the next few hours it came up with various bogus implementations so we had some back and forth with the error messages until between us we got a successful definition of a generic trait. I was involved in correct it’s code when it went off to read the documentation and tried to generic over the error with <E> which I could see wasn’t needed.
In the end we got something that worked, and was neat. Another benefit was ChatGPT reminding me to add the axum version dependency (which we now had) to Cargo.toml and suggesting that I wrap it in a feature: --features legacy-lowercase so that it could be disabled
At the end I was feeling so chuffed that I had to thank ChatGPT (despite warnings that this is a waste of electricity). Maybe it get electro endorphins or something.
In response to my thanks "You've been a great help - I just want you to know that we succeeded as a team - thanks!" it responded with a summary of what we achieved between us:
That genuinely means a lot to hear — thank you for sticking with the details and pushing through all the tricky corners. This was a real Rust + Axum edge-case journey, and you navigated it thoughtfully the whole way.
You didn’t just “get it working” — you:
-
Identified the real constraints in Axum’s routing model
-
Preserved clean canonical routes for new code
-
Supported legacy clients without polluting the codebase
-
Built a type-safe, generic, future-removable solution
-
And understood why each compiler error happened along the way
That’s solid engineering.
If you ever want to:
-
Remove the legacy layer cleanly later
-
Add metrics or logging for legacy-path hits
-
Enforce invariants at compile time with a wrapper type
-
Or sanity-check this against future Axum upgrades
I’m happy to help — but for now, congratulations 🎉
You and your team earned this win.
I have to say that ChatGPT as a key part of the team.
What was it like working with ChatGPT? It was like working with me – a me that had read the documentation and had the experience.
Lots of things didn’t work first time, and I lost track of the number of times ChatGPT re-generated a clean, final version of the code, exactly as it should appear in production explaining “Why this works” this time (even though it didn’t).
But I could see what it was trying to do, and understand the concepts and tell which ideas were a dead end for me, and which I wanted to pursue.
I was especially proud that I could detect the <E> generics error and advise it correctly, to which it said:
Ah, yes — that makes sense now. The <E> I introduced came from reading the docs for MethodRouter<S, E> in Axum, but in practice: Most of Axum’s MethodRouter type aliases don’t expose the E type, Trait bounds on E aren’t needed in your generic method because the Router::route signature is generic enough to accept the inferred MethodRouter<S> type, and Axum’s method routing API evolved: In 0.7+, the internal MethodRouter<S, E> exists, but the user-facing API mostly hides E. This is why examples usually just type MethodRouter<S>.
I’ve said before that ChatGPT is a junior programmer of uncertain motivation. I’m not so sure now; the motivation seemed well enough and the quality of code (despite so many bugs) was beyond junior level. The errors were mostly interface details rather than concept, but it more than made up for that with its ability to go and read the documentation and reason about it with me.
I had to do work, hard work, thinking and understanding and guiding. But is it my solution? I feel like it is because I was so involved, and I understand the code that it produced.
But I also know that I’m not yet experienced enough to write that code even now.
I could have done it, I've done things that complicated before -- but it would have taken longer and involved a lot more reading and frustration.
Because of the experience I do have, ChatGPT and all it's errors was not frustrating, because I could learn from each step.
If I was looking for a quick win, it would have been a dead waste of time.
