[Jianghong94]

I work in a finance company and basically what our product is in terms of tech is a lot of client-server spreadsheets, with a huge $ amount per cell. So when I saw the demo and the use case I got extremely hooked! Unfortunately due to the hiring conditions and tech competence, there's almost 0 chance of adopting something like this, but still, I'm impressed.

I haven't got enough time to finish the video today, but I'd like to throw out some of our major technical domain problems and see how people familiar with electric would try to solve them:

1. How does it handle multiple different functionality servers? And potentially server-server networking? e.g. if I need to get some data from server A and some other data from server B, and combine them into the UI, is that doable in electric? Also what if I want to save the combined data onto the database on server C? Now for simplicity, let's just assume we're talking about less than 20 servers here and there's no problem with the port, so each one of them can keep 1 websocket per each other server open up. 2. How does it handle listening to a stream of events and triggering if the event meets a certain criteria? e.g. like if the price of GOOG is lower than a certain price then trigger a popup or something like that. This may not be the intended scope of electric Clojure but it is what we do day to day, so I'm curious. 3. How does it handle interop with existing Java apps? Is it just a normal java-clj interop?

Overall I really like the concept of being network transparent, or shall I say that devs would be better served by spending more time on business data and function, but not on coming up with derived request/response obj, API route, etc. Also, if this type of library ends up in some sort of more mainstream programming language, I would vouch for adoption in a heartbeat.

[dustingetz]

3- yes, Electric Clojure is a Clojure library (macro) so the interop story is identical to Clojure’s

2- Electric vars are reactive signals and stock prices are signals, so: (if (< price target) ($ Modal))

1- we can support microservice topologies (N sites) in principle though the work requires a corporate design partner to make sure we get it right.

This is an important capability for the Hyperfiddle layer - a Universal UI is only as valuable as the data it reaches; i.e., as far as RAD platforms go, service connectivity is the only thing that matters. Today, connecting a service to a UI requires immeasurable amounts of glue code (constantly shifting, breaking, requiring ongoing maintenance) at the cost of ~$100k+ per year per service connection, and costs grow superlinearly with complexity of the service! Electric collapses to zero the cost of service connectivity.