By design firebase should be a remote. All asynchronous behavior can be handled there more elegantly, and the mutation will then be more natural. Promesa is nice for promises. You can also adapt a promise into core async fairly easily. Personally I would probably also make a rad database adapter for saves that runs on the front end.

Ok, I will implement the remote, in my case, for the basic stuff I should just in :transact! look into ast and then call firebase api? I was looking Chapter 14. and I really don't know what should, to cause rollback of the transaction. This is my another "I'am not smart enough moment": {:body some-edn :original-transaction original-tx-or-query :status-code n} I was looking for rad adapters in another project, saving in postgres, but implementing updates with preserving the history, so basically converting updates into inserts. at the end i just created a new formsafe mutation (in cljs is a copy of yours) and in the backed was like, for this tables, create this updates in inserts, and return this. not very generic. :) (end of confession, expecting frogs from the sky)

While watching https://www.youtube.com/watch?v=bqA250jqMTg I got an idea, that would be nice to create a Fulcro response. but i still on wax on, wax off 🙂

So there are a number of ways you could create a cljs “remote”. One would be to use pathom to make resolvers and “firebase mutations” (it has a cljs async parser that can deal with the read async) and then just pass the query/mutation through to that. Otherwise, yes, you have to look at the AST (or convert it to a query/mutation) and figure out what to do.