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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
That might make sense in your case but, honestly, it runs entirely counter to the reason CSS exists.
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 disagree. I don't care what the motivation was since I believe CSS with cascading styles and global declarations was a failure to begin with.
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.
After using tachyons (http://tachyons.io/) I've gone the complete opposite direction. While tachyons takes it to an extreme, I found having many small classes that (generally) do one thing, then composing those classes in the HTML, is much nicer than giving each element one "semantic" class name and hiding all the complexity in the CSS, with the large file size and many duplicate rules that approach brings.
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.
I actually take it one step further and have classes such as `border-1-px border-dark border-bottom standard-margin no-margin-top`. Seem weird at first but combined with flexbox (if your target is the evergreens) you never overwrite and you got one stylesheet for pretty much all of your projects. It's a real production boost.
Really not a fan of CSS-in-JS. I like to keep my components JS+JSX only.
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.
"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."
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.
"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?
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.
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.
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.
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.
53 comments
[ 2.9 ms ] story [ 97.4 ms ] threadThat 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.
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.
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.
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.
Worked great for some time. Then the original idea was buried under many layers of "abstract stuff CS postdocs like to play with"
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.
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:
https://github.com/alphagov/govuk_frontend_toolkit
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.
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/
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?
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.