At QCon NY, Adam Ernst talked about the way Facebook is rewriting their UIs to use a functional approach. When all the UI components subscribing to the model, and the model subscribing to UI components (even through the controller), it’s a whole wad of interconnectedness.
Instead, it has been decreed that all data flows from the top. The GUI structure is a function of the model state. If a GUI component wishes to change the model state, that event triggers a regeneration of the GUI structure. Then, for performance, React.js does a comparison of the newly-desired DOM with the existing one, and updates only the parts that have changed.
Data flowing in one direction is a crucial part of functional programming. Persistent data structures, copy-on-mutate with structural sharing, and two-way links between parts of the structure don’t go together. Choose the first two.
In higher-level architectures, microservices are all the rage. Unlike old-style legible architecture diagrams, the dependency diagram in microservices looks like the death star. Services connect directly to each other willy-nilly.
There are alternative microstructure architectures that, like React.js, get the data flowing in one direction. Fred George describes putting all the messages on a bus (“the rapids”) and let services spy on the messages relevant for them (“the river”). The only output a service has is more messages, delivered into the rapids for any other service to consume.
This is cool in some ways. New services can build on what’s out there, without anyone knowing to send anything to them directly. However, the dependencies still exist. And it’s slower than direct connections.
What about… (also from a QCon session) OSGi is the very well-developed solution to this on the JVM. Anyone can look for a particular service, and get connected up through a trusted broker. Once the connection is made, it’s direct, no more overhead. Is that ideal?