Micro Front ends – extending the microservice idea to front end development
micro-frontends.org
micro-frontends.org
It's quite unanswered how are they dealing with styling. There's always a specific percentage of styles being shared between components. Should we duplicate these styles? I see they are going to talk about it soon (Isolated CSS / Coherent User Interface / Style Guides & Pattern Libraries).
One of the biggest joys that I had recently in front-end development is the idea of a one-way, cross-application shared state. This goes away, too.
Maybe I'm just being hyper-conservative. I need examples of the benefits of this approach in something that it's not a simple product picker.
I'd think, the "right way" would be to have each feature's logic built as a micro-service and styling as a service. That way you have consistency where necessary, but divide up feature needs into more manageable chunks.
I used to think that but nowadays I very seldom come across a situation where sharing styles make sense. I'm trying to make my components completely isolated, styles included. I'm doing CSS-in-JS and if I really need to share something (say a primary color) I import it from an explicitly shared module called "colors". This leads to some duplication but when I change something I know it will only affect that component.
A big motivation for the development of CSS was to get away from the situation in the 90s where elements would have their own styling - complete with duplication - embedded in them using (sometimes non-standard) attributes.
The situation back then made it a nightmare to apply a consistent style across a site, as well as bloating pages at a time when most people accessing the internet at home were doing so using a modem.
Most people don't use modems any more, but many of them do use mobile devices, often with high latency connections depending upon network coverage and contention. In other words unnecessary bloat is still a problem, and that original motivation for CSS is still valid.
I've built many sites using both traditional CSS, with standards like BEM and now CSS-in-JS and this is the first time it actually makes sense. I have yet to encounter a case where I miss the old way of writing CSS.
I think applying "consistent styles" is a fallacy. It sounds like something you want but in the end it becomes a nightmare to maintain once you start sharing styles all across your app. What happens is that you overwrite stuff instead of rewriting because you don't know what rewriting a certain style declaration will affect.
My main point however is that there are very few styles that actually make sense sharing between components. I gave one example; colors, but what else? Take stuff like padding and margin for example. It feels like they are something you want to be standardized but usually in big projects they become extremely context dependent and as soon as you need to deviate from the standard it becomes a headache.
The bloat argument is invalid if you use a proper CSS-in-JS lib which compiles the styles to CSS classes.
You are then not scared of changing existing classes, as they are so simple. In fact you rarely have to change them after writing them the first time. Often you can build a whole new component without writing any new CSS.
It works especially well with components, as it's OK if the HTML is "noisy" with many class names, as generally you're not dealing with large chunks of HTML at once.
Really not a fan of CSS-in-JS. I like to keep my components JS+JSX only.
There are ways to deal with this in a large organisation. E.g. at GOV.UK we had a frontend toolkit:
I always find that these domain boundaries in which teams operate are “leaky”, and result to noticable inconsistencies between them to the end-user. If you can’t afford the overhead of making sure that these inconsistencies are caught and fixed, don’t do this.
The good dimension would be hard security bounds. Lots of people are starting to look very strongly at security in depth and realizing that they need hard boundaries between tasks or security isn't even possible.
The questionable dimension is political. If I can force something into a "microservice", I can extend a political control boundary around it. Now, if something feeding me or consuming me screws up, I can say "Not my fault. Yell at him." This is probably more useful in larger companies than startups.
If you don't have a need to scale to large numbers of people, you almost certainly shouldn't attempt to apply these techniques.
Seems like an interesting idea, but it's barely supported at the moment: https://caniuse.com/#search=custom
You can polyfill custom-elements to all evergreen browsers plus IE11 [1], but yeah that's not good enough for a lot of sites.
[1] https://github.com/webcomponents/webcomponentsjs#browser-sup...
We do this with Stencil, so far so good: http://stenciljs.com/
The problem is that many "full stack" people do not live up to their denomination and when you have all-full stack teams you are raising the odds for having people who are weak at backend engineering.
That is absolutely not something you want. Backend bugs can be catastrophic.
e.g: a guy in team checkout may not know what happens when you process currency with floating point numbers.
Our backend is a monolith so all our front end projects use the same login credentials, permissions, etc.
So far our users are ok with this approach, and since we build projects for certain departments / teams there is no argument to justify having all the front end functionality in one place.
Another benefit of having smaller front end projects is being able to experiment with stuff instead of having to stick with the same libraries / stack / mistakes from the past. I reckon this is a double edged sword, but it works for us so far.
From my limited exposure to the subject, Google's Polymer framework seems like a good base to build on if you are willing to drink the web components kool-aid.
Every microservice ("servant") would reply with an XML document. The partial documents would compose into a large XML document, and an XSLT stylesheed would be applied to it by the renderer service. This allowed to decouple the visual design from microservices' data format, allowed (limited) customization of visual representation of one service's answer depending on data from another, etc.
It worked pretty well, and felt natural.
If you don't have a few hundred people working on the frontend in many different teams, don't try this. This first and foremost solves the problem of coordinating and communicating between these teams by eliminating (some of) the need to do that. There is nothing to gain and a lot of overhead to deal with, if you're in a company without so many engineers.
https://qbix.com/platform/guide/tools
Tools can add behaviors to elements. So customElements will be very easy to add once they are supported by more browsers, or we can already do it with a polyfill.
But yeah, being able to assemble webpages from reusable components is excellent.
i like the idea of running potentially separate apps under separate URLs for the front end because it keeps an artificial encapsulation which allows devs with different js stack knowledge to work to their strengths. It also means one can progressively rewrite when the time comes.
Yikes. At what level of granularity? Do they mean within a single project? Like an ecommerce app where the shopping and checkout teams get to pick completely different front end stacks?
Worked great for some time. Then the original idea was buried under many layers of "abstract stuff CS postdocs like to play with"