Similar situation here. Except all the routes need to be on the same swagger page, so having them under two routing frameworks seems impossible. I prototyped a layer of macros that expand to reitit routes, it might be interesting to look at for now, eventually I'd like to make it its own library. It would be especially cool to have a tool that could then macroexpand-1 all these compatibility-bridge macros and magically turn the code into reitit. But that's just an idea for now. https://github.com/threatgrid/ctia/pull/1403

The actual compojure-api->reitit bridging macros are in src/ctia/lib/compojure/api/core_reitit.clj https://github.com/threatgrid/ctia/pull/1403/files#diff-c44fa66bbfa3254a08bfbe3f09e1175371728bd59739c2299f4d491ff7e22a01

i don't have access to those channels, but i'll check that out

oh i see, lol that's just slack rendering it funny

The tests explain the approach better test/ctia/lib/compojure/api/core_reitit_test.clj https://github.com/threatgrid/ctia/pull/1403/files#diff-1c3acd943e1aeb074115b5d6103c7598f3b18fc524575be5c640d529512cf554

For example

(is (= '["/my-route" {:get {:handler (clojure.core/fn [req__0] (clojure.core/let [] (do {:status 200})))}}]
         (dexpand-1
           `(sut/GET "/my-route" []
                     {:status 200}))))

Couple of things to keep in mind before embarking. 1. You can't have routing logic based on any part of the request other than the uri or request-method, e.g. (context "foo" req (cond (get req ...) ...) 2. You won't necessarily get the full speedup of a reitit-first app, since you might have route conflicts https://cljdoc.org/d/metosin/reitit/0.7.0-alpha7/doc/basics/route-conflicts#:~:text=When%20a%20Router%20is%20created,thrown%20with%20a%20descriptive%20message.

But also, compojure-api can be incredibly slow if you use context , so it's worth trying. I got a 600% speedup in CI runs by changing (context "" (GET )) to (let [r (GET ))] (context "" r)).

That was also programmatically achieved. Might be worth trying first to get a taste of potential speedups, here's how I did it https://github.com/threatgrid/ctia/commit/d5c24198238145d0b387ef9d905b56982108a66b

Though this is with compojure-api 1.x. There might be better optimizations on the 2.x branch.

this is great, thanks

Oh, and I'm still working out what the equivalent to compojure.api.api/api is in reitit. You might be using a similar batteries-included way of starting the app.

Equivalent in terms of preserving the same middleware.

good discussion. I have migrated few c-api project to reitit. reitit definitely needs the battery-packs, currently copy-pasting the good practice boilerplate from project to another. I have also drafted an functional layer of top of reitit, with ideas picked out from frameworks from other languages. One missing concept in reitit is a module, which would tie together different aspects (routes, data, middleware, schemas) and could be used as a simple abstraction to build up things fast, “web server with api-module”. Opinions and scattered config can be hided an an unified module configuration (backed by malli) - you should be able to write c-api “api” as a module. Has been in the works for 5 years, might be done in a week or in a year. Maybe there should be a open brainstorm of this? c-api + reitit sounds really interesting, looking forward to that.

One way you could migrate incrementally is by creating a reitit ring handler and specifying the old compojure handler as the default handler, then start migrating routes to the new router