What middleware? There is Fulcro logic, but all the middleware used comes from other libs, mainly ring. Encoding with transit

https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/server.clj#L214

https://clojureverse.org/t/what-are-paradigm-differences-between-different-front-end-clojurescript-libraries/2832 hoping this will turn into an interesting thread 🙂 No clue how to "properly" describe fulcro "paradigm and approaches" compared to the others there.

Is it not possible to have a single way to handle querying rooted at an entity id using datomic? The pattern seems to be to get a particular collection through a query in datomic using the datalog API and then using pull once you want a particular entity tree without change to the query

@pvillegas12 you can use lookup refs with pull

which are “Fulcro idents”

I guess

(defn wrap-api [handler uri]
  (fn [request]
    (if (= uri (:uri request))
      (server/handle-api-request
        server-parser
        ;; this map is `env`. Put other defstate things in this map and they'll be in the mutations/query env on server.
        {:config config}
        (:transit-params request))
      (handler request))))

The parser is described elsewhere in the book….it is a function that parses the query/tx, and calls a read and write hook for each element of the tx

The built-in instance called server-parser predefines the read/write handlers, which the defmutation and defquery just create multimethod entries for

The handle-api-request calls this parser every time an incoming request is handled, and it passes the env to the parser, which forwards it to the mutations/queries

the env in your snippet above is {:config config}

so, if you have things to “inject” into the env, add them to that map

Integrating with datomic, I could either inject the db there or manually call the the connection and client in each defmutation. Does that sound right?

or, if you use mount you could jst refer to the defstate items directly…up to you

I’d inject a conncetion

mutations often need that instead

I personally refer to the defstate items in the wrap-api, so they appear in env, so everything is less coupled

so, my Datomic stuff goes in config, then I refer to the config stuff in the defstate thing that holds the connection…so states refer to states, but the rest of the app can just think about the env.

and my “connection” startup does things like conforms schema

meh

just a sec….typing code in here sucks 😜

yeah I know 😛

(defstate main-connection
    :start (try
             (let [db-uri (get config :db-uri)
                   db     (d/create-database db-uri)
                   c      (if (should-mock? db-uri)
                            (mock-conn (d/db (d/connect db-uri)))
                            (d/connect db-uri))]
               (log/info (format "Starting database %s" db-uri))
               (when (should-mock? db-uri)
                 (log/warn "USING A MOCKED CONNECTION. No changes to the database will persist.")
                 (when-not mocking-ok?
                   (throw (ex-info "REFUSING TO START a database that has SNAPSHOT migrations. Please set allow.mocked.connection JVM property if you want to allow this." {}))))
               (log/info "Running Migrations")
               (try
                 (run-migrations c)
                 (catch Exception e
                   (.printStackTrace e)
                   (log/error "Database Migration failed:")
                   (throw e)))
               c)
             (catch Exception e
               (log/error "Database startup failed." e)
               (throw e))))

then I get nice things like development-mode mocked connections, migrations, etc.

so, then I’d put {:connection main-connection} in the env

and {:db-uri "datomic..."} in my defaults.edn config file. Of course, if you want to support more databases, you might use a more complex structure in the config

all assuming, of course, that you use Fulcro’s config 🙂

mock-conn comes from https://github.com/vvvvalvalval/datomock

Highly recommended…really useful for testing as well.

thanks for all of the above very useful! 👍 What do you mean by migrations? I thought they were not necessary with datomic

I mean schema conforms

technically you do run into situations where you want things applied in order, and also I do “snapshot” migrations (I’ve elided those here)

where if a schema change is named with “snapshot”, then it forces a mocked connection

that lets me play with schema without having to roll back the dev database

(I use a postgres dev database instead of a RAM-based one)

that lets me keep dev data around, and play with schema without having to “undo” it

I see