hyperfiddle

Christian Dean 2025-06-29T23:39:42.594609Z

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?

2025-06-30T10:24:04.363429Z

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 )

๐Ÿ˜ฎ 1
henrik 2025-06-30T13:32:16.781239Z

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.

henrik 2025-06-30T13:33:21.395749Z

โ€œformsโ€ in the language/code sense, not the UI sense.

Vincent 2025-06-30T16:15:15.795649Z

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.

๐Ÿ™Œ 1
grounded_sage 2025-07-01T05:08:46.995989Z

Lexical scoping across the client and server is a real breath of fresh air

๐Ÿ‘ 1
tatut 2025-06-30T05:02:18.181009Z

yes, you skip the "calling convention" boilerplate of having some JSON API endpoint, you can just call a server side function

๐Ÿ’ฏ 1
๐Ÿ˜„ 1