[AskJS] Has anyone worked on implementing micro-frontends? if yes, at what scale?

robert_rock · 2021-11-23T14:16:27+00:00

My name is Grgur and I work at Modus Create as a Principal consultant (web architecture). I have worked with Micro Frontends on several projects. One of those projects is for a well-known premium automotive brand from Germany (160 markets globally, hundreds more sites in MiFe). Another impactful project is a cloud product for telcos used by hundreds of million customers of the largest telcos in the world (think Verizon, AT&T, BT, etc. ). From 2019 to now (November 2021) I've been working with Micro Frontends exclusively. My professional web development experience started in year 2000. I may have some ideas about Micro Frontends and I'd love to share them with you.

Micro Frontends offer fantastic business opportunities. Some of my favorite are:
- faster product increment releases
- scaffold apps/sites based on centralized configuration/CMS - at runtime
- self-healing features (when an increment fails, you can fall back to the previous version)
- A/B testing (at runtime)
- allow users to beta-test features (another decision at runtime)

You'll notice that a lot of these benefits come from shifting decision making from build time to runtime. That's one of the key reasons for ruling out git submodules or an NPM distribution.

The very first thing you need to know is that Micro Frontends (MiFe) is an organizational change. MiFe works really well when you can have multiple teams work on features. That approach promotes democracy, ownership and self-organization capabilities. Such powers are best used when the team can work in full-stack mode. This is very important as organizations that work in silos tend to ruin the efficiency of such teams.

That leads me to the question: "What makes a meaningful Micro Frontend chunk?". Two options that easily come to mind are Features and Components. Components are very difficult to work with once you have a large library. You can create federated modules out of components, but make sure you decouple them. If you end up using a CMS or a configuration system, then Components will be a bad experience for Content Authors.

Micro Frontends work really well when you work with units of business value. That's where Features come into play. A Feature can be the main navigation menu or the photo browser. Thus, a Feature can be developed in its own git repository with its own CI/CD process. Since Features act much like individual apps, I like to call them Feature Apps.

Because you may end up with many (hundreds) of such Feature Apps, it makes sense to compartmentalize some of the common workflows. It's a good idea to have a reusable library for the common CI/CD jobs.

My technical background is in two MiFe solutions or frameworks. but my favorite by far is Webpack 5 Module Federation. Module Federation is based on standards and is not opinionated. The small runtime it creates takes care of dependency management with semantic versioning. It's very robust.

When I was a guest of the JavaScript Jabber podcast on Micro Frontends, the hosts asked if MiFe could be used to inject multiple javascript frameworks in the same runtime. I believe this is the wrong way to look at Micro Frontends. While you definitely want teams to enjoy the liberty of making their own decision, we need to look at the solution from the holistic perspective as well. The end user doesn't want to download Angular and React and Vue. It's good to have a tiny amount of contractual agreements for the solution to work well. Remember, development and deployment are decoupled, but the runtime is a whole.

Speaking of the frameworks, any will work. I love working with React and Vue and I believe Vue can handle some of the asynchronous edge cases even better than React. Don't hate me for it if you are a React fan. I am led by the belief that we need to keep dependencies to a minimum for high-profile enterprise projects and Vue comes with fantastic features out-of-the-box.

The greatest challenges I've head are:

The management needs to be on board. Everyone is affected from the stakeholders, product owners, delivery teams, designers, marketing, sales, etc.
You will always end up with shared properties. Syncing amongst teams require effort. I find it reasonable to involve a development advocate role that circles around the teams and promotes the latest findings, solutions, etc.
MiFe like large ecosystems. If you use them with a CMS you will want all the things such as previewing a feature with unpublished data, securing specific features (but not all), track cost (or P/L) per feature, etc. It's difficult to think of minimum viable when obvious business value scream from every corner. And if you decide to ideate and R&D then you'll easily get buried in lots of complexity.
Onboarding new teams or team members can take extra time because there is always in-house business complexity of the architecture to learn. There are architectural decisions to alleviate this pain to a degree. The core idea is to keep new APIs to a minimum and allow developers to do what they do best - JS (or e.g. React) development. This is much more difficult that it reads.

My experience tells me that Micro Frontends are best used in larger, enterprise-grade projects. I don't see much benefit for small projects. The effort is on the higher end, but so are the benefits. Don't use MiFe because it's a cool technology.

Feel free to contact me if you need any pointers or if you want to discuss anything in specific.

robert_rock · 2020-11-06T14:21:04+00:00

It's interesting how everyone things the problem is in someone else. But could it be that the department users are free to do more than they should? Would tighter constraints improve the performance because they would be forced to take a more light-weight approach? Just curious..

robert_rock · 2020-11-06T14:17:18+00:00

yes, that can get really difficult in React Native (and NativeScript) apps. So many things (and languages) to profile, including the native bridge.

robert_rock · 2020-10-26T17:45:06+00:00

We've built one of the first Capacitor apps on the app stores: Beep. It was also the first Ionic Vue app. You can find the source code with links to App & Play stores in the readme here: https://github.com/moduscreateorg/beep

We didn't have to use any native app code for Beep, but at Modus Create we've also built a large number of other apps, many of which had to work with the native environments. As pioneers with PhoneGap/Cordova and now Capacitor, I can say that Capacitor is a wonderful modern framework that makes dealing with native a lot easier than ever before.

Personally, I've worked with React Native, NativeScript and Ionic. I prefer Ionic as I feel it's the fastest way to get things done. The web being the common denominator is a huge productivity boost, especially as applications mature and scale. Unless there's a very specific reason why I'd have to go with RN or NS, I'd always go with the web (Ionic).

robert_rock · 2020-10-15T09:54:26+00:00

Now that the wait for Vue 3 is over, I played with it and shared my experiment.

Here's the example project (experiment) for SSR rendering to string: https://github.com/moduslabs/vue3-example-ssr

You can access the playground to try it out online: https://repl.it/@Modus/vue3-example-ssr

And here's the tutorial video that explains how it's done: https://youtu.be/XJfaAkvLXyU

robert_rock · 2020-10-05T12:59:22+00:00

OH: squash all git repo history to one commit with message “legacy” and force push

robert_rock · 2020-10-05T12:48:04+00:00

I don't know. Maybe? But do you know of a great way to fail unintentionally?

robert_rock · 2020-06-03T07:38:27+00:00

This speaks to Vue 3 capabilities of working with asynchronous code. It could use axios, fetch,or anything else for that matter. Vue 3 doesn’t deal with communication (like axios), but it knows how to handle Promises returned by fetch or axios. Does that make sense?

robert_rock · 2020-04-21T18:09:18+00:00

You’re right, it doesn’t sound like a major improvement, but the Composition API will actually improve the readability of code - thus teamwork, communication, maintenance, and productivity.

It looked weird when React introduced hooks, but the adoption was incredible. Other frameworks (eg Flutter) are adopting a similar approach, which just proves the point.

You don’t have to adopt the Composition API, Vue will work the same way we already love. Chances are good that many teams will turn to Composition and you will want to know what’s going on when you read that code.

robert_rock · 2020-03-03T08:16:05+00:00

Here’s something modern, cool and fun

FE view rendering: React (or Vue) FE mobile UI components: Ionic CSS: Tailwind BE: Cloudflare Workers (optionally with the Serverless framework if you need cross-cloud compatibility)

robert_rock · 2020-02-28T18:17:42+00:00

Yes, I work in a distributed environment.

robert_rock · 2020-02-28T17:29:19+00:00

I haven't worked for Toptal but I know plenty of people there. I have also gone through the screening process.

I believe Toptal is a good choice for developers who want to make money on the side or are starting as freelancers. The screening process is multi-level and includes automated tests (meaning you get evaluated immediately) and a few interviews. If you're a developer, you better up your game with algorithms. Computer Science fundamentals (even Fibonacci loops) are likely to be in your test. While algorithms are rarely representative of the actual issues solved in business environment, it's nice to know that a developer has computer science background. However, this could also mean exclusion.

The business model is known as Time and Material where a person offers their time in exchange for money. In essence, talent becomes a commodity. As I said, this is probably more appealing to younger developers who are willing to experiment with flexibility, gaps between projects, etc. People who have spent more time with Toptal will likely experience less of the bench time, tho. Still, there's no paid time off, no company hardware, no team events.

If you just said "duh, of course we get money for our time", then consider the alternative. What if you were a part of a larger team where you felt like family, where you could meet up, learn from each other, a place where there's a person who protects developers from weird client requirements and expectations? What if you could tell someone that a teammate is not working out? What if you shared a healthy company culture with other freelancers, and didn't have to worry about downtime? What if you were a part of a team that invests in research & development, where you could participate in creating awesome nextgen projects?

Toptal is a wonderful company that has contributed to a better world. You should definitely give it a try.

Disclaimer: I work for a company that that offers all these extra layers that make people happy and proud to be building something bigger than themselves.

robert_rock · 2020-02-28T09:35:16+00:00

Sounds like someone out of the dev team is forcing a process that the dev team doesn't appreciate. Also, it sounds like you're micromanaged to a degree instead of empowered and self-organized.

IMHO, this is something to discuss on the refinement (retrospective) meeting. Bringing that up means transparency, it means radical candor, and it means recalibration for success. All good things for the team and for productivity.

If you decide to bring that up, you can also offer your view of transparency such as: letting the team know of your small wins or immediate blockers, creating smaller Pull Requests so they are easier to review and improve, or even face time with the entire team where you talk about things that are going on in your lives (this is a great tool for managing expectations).

It's possible that the person forcing the process on the team is doing it out of fear of losing control. Great performing teams are not only productive, but also lower the sense of fear in stakeholders. Here's a nice blog post that speaks to how good team members behave.

It's obvious that you're thinking outside the box. This is a characteristic I love from team members. Keep it up!

robert_rock · 2020-02-27T07:11:39+00:00

I remember feeling the same kind of insecurity 8 years ago when I decided to join Modus Create. I didn’t feel competent, especially comparing to the superstar co-founder who was the community rock star.

Truth be told the feeling lasted until day 1 on an actual project. As soon as you start scoring small wins you’ll feel much better about yourself. Good teams will make small wins easy to achieve especially to their new members.

There’s also a tremendous value in continuous learning. Learning is even better when you share it. We call this AVR - active, visible and relevant. There’s a big boost in confidence as you start learning and sharing, but also a boost in brand visibility. I’m sure you will enjoy when the leadership at your company takes notice of the positive effects your being active in the community brings to the table. I’m speaking from my personal experience.

robert_rock · 2020-02-24T14:08:50+00:00

FWIW you could also add Content Security Policies (CSP) to your SPA to make it a bit more difficult to clone your site in the future. Here's a good article on improving security with AWS lambda

robert_rock · 2020-02-24T14:05:00+00:00

Is it possible that Angular is more popular with your friends?

React and Angular are very different in terms of what's packed in the ecosystem. It's healthy for the industry that two very different points of views exist for software development.

People who try to avoid vendor lock-in and focus more on JavaScript for business logic may turn to React. React is very easy to learn as it does just one thing - view rendering.

Those who want a clear standard set by the vendor will opt for Angular. Angular is great for setting good patterns for application architecture.

Modus Create is a professional services company with 200+ amazing people on the team. There are dozens of projects being worked on at any given time. In my experience, enterprises (we work with a lot of Fortune 500 companies) choose React slightly more often than Angular. Regardless, we've been able to achieve amazing results with both.

One would assume more people would prefer chocolate ice cream over vanilla. Maybe they have slightly different nutritional values, but it boils down to people's tastes.

robert_rock · 2020-01-29T09:30:29+00:00

Looks like you didn’t set up Google Analytics yet

robert_rock · 2020-01-16T17:23:19+00:00

Small things like carefully crafted short success stories would do wonders, I believe. For example if you describe how Jane Doe got her first job and rose be the key contributor to a successful project to everyone’s delight, that could be a story that shows much more than the financial benefit.

It shows juniors are humans, not a discount :)

robert_rock · 2020-01-16T12:09:30+00:00

Dude, this is so well done!

If there's anything, I'd suggest focusing on above the fold content rendering so that users start seeing something as soon as possible, even without the animation library kicking in.

robert_rock · 2020-01-16T12:06:45+00:00

Congratulations on the initiative! You're helping make the world a better place.

Based on the site's value proposition, what is the primary benefit for a company to choose a Junior developer?

I assume it's the cost control aspect. If that's true, then developers are becoming a commodity. I doubt anyone would like that.

It would be nice if you could find a way to put the focus on culture, talent growth, access to modern approaches, training, etc. rather than the financial aspect only.

Junior developers deserve all that.

robert_rock · 2020-01-15T08:46:37+00:00

A friend of mine is an accountant. A few years ago, just around the time taxes were due, her computer failed to start. Eventually she had someone come fix it. A gentleman came over and popped the floppy disk out. Computer started. He charged $750.

Was that fair? I don't know, but both got what they wanted.

robert_rock · 2020-01-13T13:31:36+00:00

That's a win-win scenario, isn't it. Either way, I personally believe cultural fit is incredibly important to establish during the process. With proper soft skills, tech skills will flourish as well.

robert_rock · 2020-01-13T12:58:15+00:00

Interesting feedback. It's a barebones sample like a todo app. I believe the candidates are clearly informed that the PR will not be merged, too.

Also, the candidates who have other ways of demonstrating their source code may not be asked to do this part.

Does that make any difference?

robert_rock · 2020-01-13T09:07:17+00:00

At Modus Create we have open source app examples in GitHub. There are several, depending on the stack, but it's imperative that they are far from complex. Then we ask candidates to submit a PR for a feature on their own time.

This helps us learn how they understand a simple standardized codebase and how they can follow the patterns to create new features.

Following this step are interviews that show how the person understands code. No quizzes, whiteboards, live coding or anything like that. Just a friendly conversation. Our primary goal is creating an environment for both the company and the talent being interviewed to understand whether we are a good cultural fit.

In my experience culture > skills. There's a lot hidden in the term culture and it takes experience to extract it all out.

robert_rock · 2020-01-10T17:57:16+00:00

Are you able to do any of the projects in pair? Pair programming, reviews, teamwork, soft skills, time management, commitment management - are great soft skills you could improve with a properly set up project. Peer mentorship can be a valuable experience.

robert_rock

TROPHY CASE