I've never worked on a big project so I'm still trying to grok exactly what code can be totally forgotten about when using Electric. Re: frontend/backend + DB communication, I'm used to writing 3 files: api.cljs, server.clj, and db.clj. Anytime I need a new way to query or append to the DB, or connect to some other api, I'll write a api.cljs function like (defn new-query [id] (js/fetch ... etc). Then a new endpoint in server.clj, like (GET "/new-query...), and a fn in DB.clj to get the data. I guess in big projects these can grow pretty large. Is it exactly this kind of thing that Electric lets you omit entirely, where you can just write in one cljc file and have the (e/server) fn go straight to my DB.clj query call and return the data back into the frontend?
It also acts like a db, as one call to the server will 'cache' the response so if your component renders again, it doesn't go to the server again ( if invoked with the same params )
Good point, and DB calls arenโt special in this case. Forms only rerun if given different arguments from the first time they were called.
โformsโ in the language/code sense, not the UI sense.
The network divide between client and server is what demands writing a clientside acceptor and serverside dispatcher, as is the classical database case. With electric you wrap serverside calls in (e/server ...) like you said and now you're in server context. Furthermore you cam nest contexts.
Lexical scoping across the client and server is a real breath of fresh air
yes, you skip the "calling convention" boilerplate of having some JSON API endpoint, you can just call a server side function