6 ms·

Micro Front ends – extending the microservice idea to front end development

114 points by fagnerbrack 9y ago

fuckuservices 9y ago
Christ, can we stop with the goddamn microservice nonsense already? Please?
- chmike 9y ago
  Could you elaborate ? Any arguments ?
  - hoppelhase 9y ago
    It can be seen as a design pattern that people use just for the sake of using the design pattern. This is not good practice, IMHO.
  - fuckuservices 9y ago
    99% of the time you don't need to complicate your software to this point. Most people don't need a complicated architecture like this. Really.
    - icebraining 9y ago
      I agree that people seem to be using microservices where it doesn't make sense. That said, the 1% still exist, and it's normal that they generate more proposals and discussions, since they're the ones dealing with the harder problems.
stingraycharles 9y ago
I think this is an artifact of domain driven design taken too far. Perhaps it works well in organisations like Netflix, Spotify, etc but I would tread very carefully with this indeed in an organisation with less engineers. 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.
- bsder 9y ago
  It's an artifact of two dimensions, one good and one questionable. 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.
- glenjamin 9y ago
  Both this and microservices are primarily tools to attempt to make it possible to scale software teams to large numbers of people. If you don't have a need to scale to large numbers of people, you almost certainly shouldn't attempt to apply these techniques.
  - DigitalJack 9y ago
    I feel like there is another aspect that is helpful. It's another way to partition an application into surmountable "bite size" chunks. There are plenty of other ways to do this, but if this is what helps you think about the problem, go for it.
pier25 9y ago
We do something similar in our company because it's easier to manage many small projects than less bigger ones. It requires less people per project which in turn requires less communication overhead and since projects are way simpler productivity is also better. 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.
adityapurwa 9y ago
Read it, seems complicated, will not use it.
EGreg 9y ago
We've already been doing something very similar at Qbix: https://qbix.com/platform/guide/tools 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.
weego 9y ago
This just seems like a mess of existing ideas and abstractions mashed into a pseudo-philosophy.
- coldtea 9y ago
  It only looks like that because it is.
usgroup 9y ago
The team I work with is partitioned across 3 dev languages. Micro services on the backend make a lot of sense for that reason. 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.
baybal2 9y ago
I feel this is how it was when Angular 1.0 concept was laid. Worked great for some time. Then the original idea was buried under many layers of "abstract stuff CS postdocs like to play with"
sametmax 9y ago
Shameful but relevant plus here, the Foss project crossbar.io helps with that kind of thinking. It creates transparent pub/sub and routed rpc that work between microservices and cross languages. But because it uses websocket as a transport, it also work with no adjustments in the browser.
xj9 9y ago
you mean components?
partycoder 9y ago
Basically this promotes the idea of "full stack microservices". 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.
- icebraining 9y ago
  I think this is intended for large organizations, where you can have specialists on each team - e.g. instead of having a "backend team" of thirty developers and a "frontend team" of twenty, you might have five teams each with six backend and four frontend developers.
oh-kumudo 9y ago
How could u prove it is useful outside of the example in the article? I found several listed goodies of this idea pretty questionable. Weirdly feel like a renaissance of the old architecture astronauts.
tzahola 9y ago
The article implies that you should architect your system around your existing team boundaries. This is harmful and counterproductive. You should identify the sub-units of your system first, and then you can come up with an organizational structure that work effectively with your architecture.
- reificator 9y ago
  That might work for software companies. Doesn't hold up in my experience in companies that happen to need software.
- taspeotis 9y ago
  https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- icebraining 9y ago
  I think the idea is that you've already done that on the backend, and you're just extending it to the frontend.
  - tyingq 9y ago
    There are unique downsides of extending it there. Bloated downloads and less caching benefit since pages need competing frameworks. How to deal with shared elements like a cart widget or login widget. Overlap...search results and shopping pages may be very similar on an ecommerce site. Their example shows those as 2 separate teams able to make all of their own stack decisions.
  - coldtea 9y ago
    Because there's some misguided assumption that what fits one domain should fit the other too.
hectorlorenzo 9y ago
I really really don't like the idea of having 3 different runtime libraries (or maybe even the same library with slightly different versions) loading at the same time. 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.
- deleted 9y ago
  [deleted]
- pedalpete 9y ago
  I'm assuming they've taken the example to the n-th degree. You're right to question why you would want 3 libraries, but it does happen. 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.
  - hectorlorenzo 9y ago
    I agree, that's a nicer solution, but still one that could be solved working on a agreed set of principles on a shared "monolithic" framework. Part of the appeal of React and Vue is that you can think of components as black boxes with a sound API. Different teams can be mostly unaware of other teams' components, and this concept makes the chunks already manageable.
- Kiro 9y ago
  > There's always a specific percentage of styles being shared between components. 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.
DasIch 9y ago
Zalando does this as well with Mosaic: https://www.mosaic9.org https://www.mosaic9.org 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.
aaimnr 9y ago
"Custom Elements, the interoperability aspect from the Web Components Spec, are a good primitive for integration in the browser. Each team builds their component using their web technology of choice and wraps it inside a Custom Element (e.g. <order-minicart></order-minicart>). The DOM specification of this particular element (tag-name, attributes & events) acts as the contract or public API for other teams. The advantage is that they can use the component and its functionality without having to know the implementation. They just have to be able to interact with the DOM." Seems like an interesting idea, but it's barely supported at the moment: https://caniuse.com/#search=custom https://caniuse.com/#search=custom
- allover 9y ago
  > Seems like an interesting idea, but it's barely supported at the moment 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-support https://github.com/webcomponents/webcomponentsjs#browser-sup...
- yesimahuman 9y ago
  Chrome and Safari (including iOS) have native support, which also means mobile browser native support is near universal. For Firefox and IE/edge, the v1 polyfill works really well. I’m optimistic these browsers will soon support it natively but until then it works very well today conditionally loading the polyfill for that percentage of browsers w/o native support. We do this with Stencil, so far so good: http://stenciljs.com/ http://stenciljs.com/
je42 9y ago
Interesting . We are calling this approach internally: component-based. Other names, i heard were widget based.
Xoros 9y ago
So it's the widget come back ? One for the weather forecast, one for stock exchange informations...
- tyingq 9y ago
  Ugh. Java portlets.
deleted 9y ago
[deleted]
tyingq 9y ago
"Each team should be able to choose and upgrade their stack without having to coordinate with other teams" 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?
bradmwalker 9y ago
Encapsulation can be useful.
coldtea 9y ago
"Let's take a bad idea to its slippery slope conclusion"
tuan 9y ago
I feel like Microservice idea does not seem to translate well to front end. When thinking of microservices, one can think of collection of well encapsulated functions that are composed together. The keywords are function & encapsulation. This is not usually the case for frontend development. UI components in the same app can't be completed sealed off of each other. You can model UI component as functions of state, but those functions usually depend on at least 2 globals: DOM event system and styling. This is where encapsulation is broken and leads to all sort of maintenance issues.
- proc0 9y ago
  In other words, UI manages monolithic state by definition. Whenever you're able to completely break off from the monolithic state, then probably that logic can be its own app. Typically this is not the case with widgets on the same screen. Usually you want UIs to display integrated data of some kind, that is intertwined with the rest of the app somehow.
plq 9y ago
The web rediscovers what Delphi, VB and similar tech did at nineties -- components :) 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.
nine_k 9y ago
At Yandex ca 2006, we had a microservice-like system that allowed to build various parts of a large page in parallel, using a graph of microservice dependencies. 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.
proc0 9y ago
Inherently, UI IS state. Anytime you have a user interface, you literally are writing software to manage state of some kind. Take the TV remote... the user controls the state of the TV, namely the channels, and properties like volume. The remote is an interface to change this state. Microservices is like trying to solve the problem of a really, really complicate TV with crazy channels and multiple volume properties by creating 10 different isolated controllers. It won't work because there exists a shared state, yet each controller is aiming to not share any state while still having a scaleable system. This is of course only possible in simpler UI's, because the more complex the UI, the more state will need to be shared, unless you want to throw away DRY principles and duplicate logic and styles all over what is seemingly the same app.

114 points by fagnerbrack 9y ago

fuckuservices 9y ago

Christ, can we stop with the goddamn microservice nonsense already? Please?

chmike 9y ago
Could you elaborate ? Any arguments ?
- hoppelhase 9y ago
  It can be seen as a design pattern that people use just for the sake of using the design pattern. This is not good practice, IMHO.
- fuckuservices 9y ago
  99% of the time you don't need to complicate your software to this point. Most people don't need a complicated architecture like this. Really.
  - icebraining 9y ago
    I agree that people seem to be using microservices where it doesn't make sense. That said, the 1% still exist, and it's normal that they generate more proposals and discussions, since they're the ones dealing with the harder problems.

stingraycharles 9y ago

I think this is an artifact of domain driven design taken too far. Perhaps it works well in organisations like Netflix, Spotify, etc but I would tread very carefully with this indeed in an organisation with less engineers. 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.

bsder 9y ago
It's an artifact of two dimensions, one good and one questionable. 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.
glenjamin 9y ago
Both this and microservices are primarily tools to attempt to make it possible to scale software teams to large numbers of people. If you don't have a need to scale to large numbers of people, you almost certainly shouldn't attempt to apply these techniques.
- DigitalJack 9y ago
  I feel like there is another aspect that is helpful. It's another way to partition an application into surmountable "bite size" chunks. There are plenty of other ways to do this, but if this is what helps you think about the problem, go for it.

pier25 9y ago

We do something similar in our company because it's easier to manage many small projects than less bigger ones. It requires less people per project which in turn requires less communication overhead and since projects are way simpler productivity is also better. 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.

adityapurwa 9y ago

Read it, seems complicated, will not use it.

EGreg 9y ago

We've already been doing something very similar at Qbix: https://qbix.com/platform/guide/tools 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.

weego 9y ago

This just seems like a mess of existing ideas and abstractions mashed into a pseudo-philosophy.

coldtea 9y ago
It only looks like that because it is.

usgroup 9y ago

The team I work with is partitioned across 3 dev languages. Micro services on the backend make a lot of sense for that reason. 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.

baybal2 9y ago

I feel this is how it was when Angular 1.0 concept was laid. Worked great for some time. Then the original idea was buried under many layers of "abstract stuff CS postdocs like to play with"

sametmax 9y ago

Shameful but relevant plus here, the Foss project crossbar.io helps with that kind of thinking. It creates transparent pub/sub and routed rpc that work between microservices and cross languages. But because it uses websocket as a transport, it also work with no adjustments in the browser.

xj9 9y ago

you mean components?

partycoder 9y ago

Basically this promotes the idea of "full stack microservices". 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.

icebraining 9y ago
I think this is intended for large organizations, where you can have specialists on each team - e.g. instead of having a "backend team" of thirty developers and a "frontend team" of twenty, you might have five teams each with six backend and four frontend developers.

oh-kumudo 9y ago

How could u prove it is useful outside of the example in the article? I found several listed goodies of this idea pretty questionable. Weirdly feel like a renaissance of the old architecture astronauts.

tzahola 9y ago

The article implies that you should architect your system around your existing team boundaries. This is harmful and counterproductive. You should identify the sub-units of your system first, and then you can come up with an organizational structure that work effectively with your architecture.

reificator 9y ago
That might work for software companies. Doesn't hold up in my experience in companies that happen to need software.
taspeotis 9y ago
https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
icebraining 9y ago
I think the idea is that you've already done that on the backend, and you're just extending it to the frontend.
- tyingq 9y ago
  There are unique downsides of extending it there. Bloated downloads and less caching benefit since pages need competing frameworks. How to deal with shared elements like a cart widget or login widget. Overlap...search results and shopping pages may be very similar on an ecommerce site. Their example shows those as 2 separate teams able to make all of their own stack decisions.
- coldtea 9y ago
  Because there's some misguided assumption that what fits one domain should fit the other too.

hectorlorenzo 9y ago

I really really don't like the idea of having 3 different runtime libraries (or maybe even the same library with slightly different versions) loading at the same time. 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.

deleted 9y ago
[deleted]
pedalpete 9y ago
I'm assuming they've taken the example to the n-th degree. You're right to question why you would want 3 libraries, but it does happen. 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.
- hectorlorenzo 9y ago
  I agree, that's a nicer solution, but still one that could be solved working on a agreed set of principles on a shared "monolithic" framework. Part of the appeal of React and Vue is that you can think of components as black boxes with a sound API. Different teams can be mostly unaware of other teams' components, and this concept makes the chunks already manageable.
Kiro 9y ago
> There's always a specific percentage of styles being shared between components. 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.

DasIch 9y ago

Zalando does this as well with Mosaic: https://www.mosaic9.org https://www.mosaic9.org 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.

aaimnr 9y ago

"Custom Elements, the interoperability aspect from the Web Components Spec, are a good primitive for integration in the browser. Each team builds their component using their web technology of choice and wraps it inside a Custom Element (e.g. <order-minicart></order-minicart>). The DOM specification of this particular element (tag-name, attributes & events) acts as the contract or public API for other teams. The advantage is that they can use the component and its functionality without having to know the implementation. They just have to be able to interact with the DOM." Seems like an interesting idea, but it's barely supported at the moment: https://caniuse.com/#search=custom https://caniuse.com/#search=custom

allover 9y ago
> Seems like an interesting idea, but it's barely supported at the moment 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-support https://github.com/webcomponents/webcomponentsjs#browser-sup...
yesimahuman 9y ago
Chrome and Safari (including iOS) have native support, which also means mobile browser native support is near universal. For Firefox and IE/edge, the v1 polyfill works really well. I’m optimistic these browsers will soon support it natively but until then it works very well today conditionally loading the polyfill for that percentage of browsers w/o native support. We do this with Stencil, so far so good: http://stenciljs.com/ http://stenciljs.com/

je42 9y ago

Interesting . We are calling this approach internally: component-based. Other names, i heard were widget based.

Xoros 9y ago

So it's the widget come back ? One for the weather forecast, one for stock exchange informations...

tyingq 9y ago
Ugh. Java portlets.

deleted 9y ago

[deleted]

tyingq 9y ago

"Each team should be able to choose and upgrade their stack without having to coordinate with other teams" 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?

bradmwalker 9y ago

Encapsulation can be useful.

coldtea 9y ago

"Let's take a bad idea to its slippery slope conclusion"

tuan 9y ago

I feel like Microservice idea does not seem to translate well to front end. When thinking of microservices, one can think of collection of well encapsulated functions that are composed together. The keywords are function & encapsulation. This is not usually the case for frontend development. UI components in the same app can't be completed sealed off of each other. You can model UI component as functions of state, but those functions usually depend on at least 2 globals: DOM event system and styling. This is where encapsulation is broken and leads to all sort of maintenance issues.

proc0 9y ago
In other words, UI manages monolithic state by definition. Whenever you're able to completely break off from the monolithic state, then probably that logic can be its own app. Typically this is not the case with widgets on the same screen. Usually you want UIs to display integrated data of some kind, that is intertwined with the rest of the app somehow.

plq 9y ago

The web rediscovers what Delphi, VB and similar tech did at nineties -- components :) 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.

nine_k 9y ago

At Yandex ca 2006, we had a microservice-like system that allowed to build various parts of a large page in parallel, using a graph of microservice dependencies. 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.

proc0 9y ago

Inherently, UI IS state. Anytime you have a user interface, you literally are writing software to manage state of some kind. Take the TV remote... the user controls the state of the TV, namely the channels, and properties like volume. The remote is an interface to change this state. Microservices is like trying to solve the problem of a really, really complicate TV with crazy channels and multiple volume properties by creating 10 different isolated controllers. It won't work because there exists a shared state, yet each controller is aiming to not share any state while still having a scaleable system. This is of course only possible in simpler UI's, because the more complex the UI, the more state will need to be shared, unless you want to throw away DRY principles and duplicate logic and styles all over what is seemingly the same app.