3 ms·
The fundamental problem is cleanly persisting data. There's all sorts of design paradigms we use to attempt to send state through the presentation layer to the
by debt 7y ago
The fundamental problem is cleanly persisting data.
There's all sorts of design paradigms we use to attempt to send state through the presentation layer to the persistence layer.
Ultimately there's no clean way to do it and because of that it's hard to have something like a micro frontend. The presentation layer is always aware of the data persistence layer to some degree.
Take a physical light switch. The switch will still work if the power is out; it goes up and down. The same doesn't have to be true from a purely digital standpoint. If the power is out, we can actually disable the switch(assuming this digital display switch is powered by a battery in this case).
So in the digital switch case, the switch accurately reflects the global state of power. In the analog switch case, the switch still functions regardless of the global state of power.
In the digital case, one must write code that actually checks the global power state to conditionally enable the on/off functionality of the digital switch. So that code, is not strictly presentation layer code, rather it's state-maintenance code or I don't know what you'd call it. Point is, you now have the presentation layer now tightly coupled to the something outside of the presentation layer; in this case, the global state of power("is the electricity working?").
And this is just a simple example of an on/off switch.
Micro frontends are a difficult problem. One solution might be to have all frontends be signal based. So if you send a signal a listener can optionally handle it or not or maybe nothing is listening. In the analog on/off switch case, that's exactly how it works. If the power is off, the switch still flips.
- jerf 7y agoI think that's part of the problem, but only a part of the problem. One of the things I think we're slowly groping towards is the importance of composability in all sorts of programs. The problem is, where we'd like to write "app1 <> app2" and have the result be something sensible (as in monoidal composition in something like Haskell), the problem is that we don't have a well defined definition of "composing" two applications together when those applications each have their own page layout, HTML widgets, style sheet, data persistence, user authentication model, user authorization model, server communication methods, URL scheme, configuration information, and who knows what else I'm forgetting. I was reminded of something like this today as I'm sitting here slicing an application up into bits, and I realized I was basically implementing a composition system for the bits of my app, but the composition of "a thing that has some HTTP handlers, and some data types, and some methods, and some logging code, and some services that it runs all the time, and an API" is really ugly. You have to go out of your way today to structure things that way, because everything is fighting you by forcing you to compose different things in different ways, and encouraging you in a million subtle ways to do something that will add a little spiky bit to your code that will make it impossible to compose. Consider just the HTTP handler. How many "routers" out there make it easy to encapsulate a particular sub-application on a particular URL fragment like "/myforum", and then all you have to do to move the application to a different URL is simply route it to something different like "/public/myforum", and no other changes have to be made? The ones I know that allow that don't particularly encourage it, and there's plenty for which it's all but impossible. It doesn't take many things that can't be composed very well to make composition difficult, and very few things in programming make composition easy right now.
- bcheung 7y agoI've had similar thoughts after learning category theory. I'm trying to develop a conceptual model where each different category (JSX, data layer, data fetching, validation, 2-way binding) cleanly composes. With arcane nature of category theory not being common knowledge, frameworks, libraries, standards, etc, are unfortunately being created in ways that actually prevent patterns of composition. It's almost to the point that I'm wanting to reinvent things from the ground up based on solid patterns of composition. Have you done any work or discovered any patterns to make things behave more like the monoidal "<>" that you mentioned?
- jerf 7y ago"Have you done any work or discovered any patterns to make things behave more like the monoidal "<>" that you mentioned?" Only a lot of hard work, honestly. In the case of the HTTP router case, I think it's important to pass the URL being used to access the resource cleanly down to the resource, but it's still up to the resource to then use relative URLs properly, which is an uphill battle.