Interactive development workflow with FastAPI

[qubit55]

Hello,

I'm trying to use an interactive workflow with FastAPI - spinning up a server from within the REPL in a separate thread so it's non-blocking. Ideally, every time I redefine a handler, I expect the server to pick it up automatically. Unfortunately, that doesn’t work out of the box with FastAPI. From what I understand, it creates a static routing table that doesn’t allow dynamic updates, which kind of kills the interactive development experience.

That said, I’ve come up with a workaround:

(import fastapi)
(import [uvicorn :as uv])
(import threading)

;; Create FastAPI app
(def app (fastapi/FastAPI))

;; Function to update routes dynamically
(defn update-routes
  [new-routes]
  (.. app -router -routes clear) ;; Clear existing routes
  (doseq [[path [method func]] new-routes]
    (let [route-fn (case method
                     "get" (.get app path)
                     "post" (.post app path)
                     "put" (.put app path)
                     "delete" (.delete app path))]
      (route-fn func)))
  (print "Routes updated!"))

;; Default route function
(defn default-home [] {"message" "Hello, World!!!!"})

;; Initialize with default route
(update-routes {"/" ["get" default-home]})

;; Server function
(defn run-server []
  (uv/run app ** :host "127.0.0.1" :port 8000))

;; Start server in background thread
(-> (threading/Thread ** :target #'run-server :daemon true)
    (.start))

(print "Server running at http://127.0.0.1:8000")
(print "Use update-routes in the REPL to dynamically modify routes!")

Right now, every time I redefine a handler, I have to call update-routes. It works, but I’m not sure I like this approach.

Any suggestions on how to make this process smoother?

[ikappaki]

HI @qubit55,

Please find a hack below using a decorator to remove outdated routes that reference the path once the handler is re-evaluated. This approach can be converted into a macro depending on the application’s needs, ensuring that the path (e.g., \ in the example below) is not repeated unnecessarily.

The purpose of the update-route! decorator is to clean up any routes associated with that path that do not point to the regenerated handler, i.e. whose endpoint is not the same as the new handler.

Just a reminder that decorators are applied right-to-left. This means that the .get decorator will be applied first, creating the new route, and the update-route! decorator will be applied afterward to remove any outdated routes that do not match the new handler.

I hope this helps.

(ns fa
  (:import [fastapi :as f]
           [uvicorn :as uv]))

(defonce app (f/FastAPI))

(defn update-route! [app path]
  (fn [func]
    (let [routes (seq (.. app -router -routes))]
      (doseq [route routes]
        (when (and (= path (.-path route)) (not= (.-endpoint route) func))
          (.remove (.. app -router -routes) route))))
    func))

(defn root  {:async true
             :decorators [(update-route! app "/")
                          (.get app "/")]}
  []
  {"message" "Hi there"})


(comment

  (def server (future (uv/run app ** :host "127.0.0.1" :port 8000)))

  (.. app -router -routes)
  (.. app -router -routes clear)

  ;;
  )

[qubit55]

Hi @ikappaki,

Oh, that's elegant! Works like a charm, thanks a lot!

[amano-kenji]

I'm new to basilisp. Is there a way to remove the hack?