Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link

Michael Geers

Author
+ Follow
since Sep 11, 2020
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
5
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Michael Geers

Hi Paul,

it doesn't have to vary. I'd say a project where different page types are built by different teams and where these pages are only connected via links would quality as a micro frontends architecture.
My books starts with exactly this example [1].

However, for many use-cases this very simple approach will not be sufficient. You might want to show functionality from different systems on the same view. To enable this we need a composition technique. The most basic one is to use an iframe, but you can also use solutions like AJAX, Server-Side Includes or Web Components to provide a more performant and seamless user experience.

If your use-case requires client-side rendered page transitions for an app-like user experience you might want to move from links (hard navigations) to an overarching client-side router (aka application shell) that enables soft navigations. Then you're building a Single Page App that consists of Single Page App. I'll address all of these topics in the main part of the book.

I've also set up a little site, The Tractor Store[2], where you can see the running example code from the book. Example #1 is "Links & Pages"  

\ Michael

[1] https://livebook.manning.com/book/micro-frontends-in-action/chapter-2
[2] https://the-tractor.store
Hi,

yes, I think web components are a great and standards compliant way to solve frontend integration between different systems. We build our applications/fragments in techniques like React, Vue or vanilla JS and then package them as web components for the other systems to use. You can see working examples of this here [1] and in chapter 5 of my book I go even deeper into this topic [2].

\ Michael

[1] https://micro-frontends.org
[2] https://livebook.manning.com/book/micro-frontends-in-action/chapter-5
Hi German,

You usually try to make individual micro frontends as self contained as possible. Similar to the advice that microservices shouldn't share a database its common practice for micro frontends to not work on the same state.

If your system boundaries are use-case based you shouldn't need an overarching state management or orchestration layer. We try to slice our systems in a way that e.g. a transaction like a checkout flow is confined in one system and not distributed.

\ Michael
I agree that micro frontends are still in a pretty early phase and many developers are just starting to discover this topic.
That said, many companies have shared their experience with this approach over the last one or two years [1] and you can common patterns and best practices emerge.
Florian Rappl has conducted as survey with 300 people lately and published the result in an interesting blog post [2].


[1] https://github.com/rajasegar/awesome-micro-frontends#posts
[2] https://blog.bitsrc.io/microfrontends-survey-evaluation-d2af7eade306
Yes, totally agreed. The architecture, similar to microservices, introduces overhead. I wouldn't recommend starting a new project with micro frontends unless you are pretty certain that you'll need the technical and organisational benefits this architecture can provide. It can make sense to adopt if from the start if you a) know that your project will grow quickly and b) it's easy for you to make good system boundary decisions early on because you know the domain very well.
You can group the integration solutions into two camps: client- & server-side composition.
With server-rendered applications you can use traditional techniques like server-side includes (SSI), ESI or use a dedicated service (podium, zalando tailor, ara framework) that concatenates your HTML.
For client-side composition AJAX or Web Components are the most often used techniques. There are also library (like single-spa) that provide a custom way of (de-)initialising the individual micro frontends.
In some cases it might even make sense to leverage the good old iframe.
There are different ways of doing this. In our projects we always form vertical teams that include frontend and backend, but I know of other companies that use the micro frontends architecture only on the frontend level where all frontends talk the same backend or a cluster of services.
We believe that it's a good thing to make teams as cross-functional as possible. Our ideal team would also be able to make it's own business decisions in the area it is working on. Here is a link to a diagram that illustrates the different "depths" you can can aim for.
https://livebook.manning.com/book/micro-frontends-in-action/chapter-13/40
Yes, micro frontends is an architectural style where multiple web applications (server-generated, Angular, React, ...) are integrated in the browser to form the final product.
Most companies choose to go this route to achieve faster development speeds because this model enables multiple teams to work side-by-side on their slice of the product without having much coordination with the other teams.
Thanks. I totally agree that many of the micro frontends paradigms are in line with the core principals that contributed to the success of the open web.

I've been a developer in the e-commerce space for over a decade now. The first companies we worked with had rather small development teams of 5 to 10 people. As the companies grew and their online share increased we had a similar effect in multiple project teams: We reached the limit of a single team size. In 2014 we had the chance to build a new e-commerce platform for a German department store chain [1] with the goal to architect the software in a way that enables multiple end-to-end teams working side-by-side with as little inter-team coupling as possible. We opted for a Self-Contained Systems [2] approach and were able to produce quick and high quality results. We had teams staffed with developers from different companies working on this project. The SCS definition was very helpful, but it focuses on the backend architecture. We had to figure out a lot of user interface integration mechanisms and best practices by ourself. In upcoming projects we had the ability to refine and iterate our approaches and techniques. The prior work of the OTTO Group [3] and publications from Gustaf Nilsson Kotte [4] were very helpful in this phase. These focus primarily on server-generated markup. With the rise of frontend frameworks like React we also felt the need to come up with a good solution for client-rendered applications. The results of our experimentations and research is documented here [5].

Hope this gives you a rough idea on where I'm coming from and how the topic has evolved for me over time. Feel free to ask more questions. I'm happy to go more into detail on this topic.

[1] https://noti.st/naltatis/zQb2m5/micro-frontends-the-nitty-gritty-details-or-frontend-backend-happyend#s3CHfXF
[2] https://scs-architecture.org
[3] https://www.otto.de/jobs/technology/techblog/artikel/scaling-with-microservices-and-vertical-decomposition_2014-07-29.php
[4] https://gustafnk.github.io/microservice-websites/
[5] https://micro-frontends.org
Hi there,

I'm Michael Geers, author of https://micro-frontends.org and the freshly published book "Micro Frontends in Action". Looking forward to my upcoming promo here in the forum. If you're curious about dividing your frontend application into more manageable pieces feel free to ask questions. You can also have a look at my book on the Manning website https://www.manning.com/books/micro-frontends-in-action?a_aid=mfia&a_bid=5f09fdeb .

\ Michael
1 year ago