DEV Community: Vlad Fedosov

How to build your first Micro Frontend with SSR in minutes

Vlad Fedosov — Mon, 27 Apr 2020 11:19:50 +0000

The current trend is to build a feature-rich and powerful browser application, aka single page app, which sits on top of a micro service architecture. Over time the frontend layer, often developed by a separate team, grows and gets more difficult to maintain. That’s what we call a Frontend Monolith. We faced all the related challenges at Namecheap a few years ago. And so we decided to move further with Micro Frontends.

Michael Geers @micro-frontends.org

Currently we run micro frontends in production for 2 years already using 3 different frameworks (Vue.js, React & Angular), actually the main page of the namecheap.com is composed from a few applications. The approach that we use now is very similar to the one that Zalando uses in Tailor. I wouldn’t be explaining now all the pros & cons of our current approach as it is not the goal of this article 🙂 What matters is that recently we decided to take a step forward & come up with a much flexible & performant approach.

And so we built Isomorphic Layout Composer (ILC) — complete solution for Micro Frontends composition into SPA with SSR support. Don’t forget to check out GitHub to see all it’s features and let’s move to the main goal of this article — creation & launch of your first micro frontend.

We need React app with SSR first

As you might already guess, to build new micro frontend we need to have regular application first. Hopefully I already did all the dirty work for you dear reader.

So you can go and grab it here github.com/StyleT/ilc-learning-react. Or you can use codesandbox.io/s/github/StyleT/ilc-learning-react to have it running for you in the cloud. I would recommend to use codesandbox.io to eliminate all the local environment related issues that may appear as we move forward.

As soon as you started the app — try to play few tic-tac-toe matches 😎

Adapting the app to ILC

To make the application work correctly with ILC we need to make it compliant with ILC to App interface. Fortunately that’s pretty easy, go through the source code and resolve all the //TODO: comments I placed for you there.

As soon as you’re finished with this — restart the app & try to open /microfrontend route. You should get 200 OK response code & some SSR markup.

Note: in case of any troubles — try to switch to the “step_1-ILC_integration” branch in the repo — it has all the changes already done for you.

Configuring ILC to handle new app

In this step we’re gonna use our public demo website and “Develop right at “production”” ILC feature to complete the task. We will do it for the sake of simplicity only. However you can achieve pretty the same results using ILC that you run locally.

To make your new fancy micro frontend work we need to determine your publicPath & ssrPath first.

If you’re using codesandbox.io (recommended approach)

Your publicPath will be somewhat like https://abcde.sse.codesandbox.io/public/. Check the address bar of your virtual browser.
And your ssrPath will be https://abcde.sse.codesandbox.io/microfrontend

If you’re running app locally

Your publicPath will be http://127.0.0.1:5000/public/.
And your ssrPath will be http://XXX.XXX.XXX.XXX:5000/microfrontend where you need to replace XXX with the real public IP address of your machine.
You can use services like https://ngrok.com/ to get one if your Internet provider keeps you behind NAT.

As soon as you’ve figured out all the details — let’s change the ILC config for us. To do so you need to open demo.microfrontends.online/nosuchpath and execute the following code in browser console:

var publicPath = 'https://abcde.sse.codesandbox.io/public/';
var ssrPath = 'https://abcde.sse.codesandbox.io/microfrontend';

var overrideConfig = encodeURIComponent(JSON.stringify({
    apps: {
        '@portal/myapp': {
            spaBundle: publicPath + 'client.js',
            cssBundle: publicPath + 'style.css',
            ssr: {
                src: ssrPath,
                timeout: 10000,
            },
            props: { publicPath },
            kind: 'primary',
        },
    },
    routes: [{
        routeId: 555,
        route: '/nosuchpath',
        slots: {
            body: {
                appName: '@portal/myapp'
            }
        }
    }]
}));

document.cookie = `ILC-overrideConfig=${overrideConfig}; path=/;`

Refresh the page after code execution. If you did everything correctly — you should be able to see your app running inside a public ILC demo website.

If it doesn’t work for you — ensure that ssrPath is accessible not only from your machine (use https://reqbin.com/) and JS/CSS links are actually working from your machine.

Now try to go between different pages using top bar. See that not only server side rendering works but also client one. Disable JS to see how page looks like w/o it.

If it works well together with other apps — my congratulations dear reader 🎉 You just built your first micro-frontend.

If it doesn’t work for you — please leave a comment below or PM me so I can try to help you & enhance this article as result.

Summary

We just turned the simplest React application into a Micro Frontend and I hope it went smoothly for you. As you can see with a proper toolchain it is not as hard as you might think.

It’s also worth saying that this article doesn’t cover a lot of the peculiarities of this process but if it will receive enough feedback from the community — I’ll write more about how you can practically build & launch more complex micro frontends in reasonable time.

Maximizing Your Professional Value, from Junior to Leader

Vlad Fedosov — Thu, 26 Sep 2019 17:04:06 +0000

As I was progressing in my career, from being a beginner in web development to leadership positions in a global company, it was always hard to understand what kind of skills I needed to develop in order to move forward.

Same goes for the moments when I was interviewing candidates for various positions within my teams. How to understand that he/she has a proper balance of technical skills and soft skills as well as proper mindset?

Should you try to catch up with all modern technologies within your profession, or be focused on one specific area and be excellent in it?

So let’s try to answer those questions and create a simple career development model that you can use as a guiding point as you move forward.

I appreciate that the seniority levels and job titles used below may not align 100% with your organization’s structure. Simply use them as reference points for your career and progress.

Basic model

To give you a clearer picture, let’s use the widely spread and simple model of the T-shaped skillset.

So every professional has:

Some fundamental knowledge that is related to the professional area. Without this it would be extremely hard to build up your career. For example, to become a Machine Learning engineer you should have strong math skills.
Basic skills across overlapping disciplines. For example, for Frontend Web Developer it would be Design, UX, Backend development, Project management, etc. This kind of knowledge helps you to communicate effectively with your colleagues.
Soft skills in areas like leadership, emotional intelligence, self-control, mentorship, social intelligence, etc. You need this to be able to communicate your ideas and work results clearly, build trust with your teammates, manager and subordinates, handle your and your team’s failures and build non-formal relationships which are extremely important.
And of course, you have deep knowledge if one or a few specific areas. This is usually the reason why you were hired. And this is your most powerful weapon to conquer the market.

Keep in mind, this is an “average” representation of the career path. But we’re all not average, right? So make corrections according to your strengths and weak points as we go.

Junior Engineer

So you were lucky enough to get hired as “Junior [your tech] Engineer” after several years of intense learning. Very likely your T-shaped skillset looks somewhat like this:

As a graduate of university/courses, you have some basic understanding of the fundamental disciplines. Your soft skills are good but if it’s your first job you still don’t have and understanding of the “corporate” culture and how to behave in certain situations.

Your main skill is at the level that you can do something not really complex under supervision. And this is the main characteristic of the Junior engineer I would say.

Middle Engineer

As you grow within your company, and get more experience in commercial development, you shift your diagram to something similar to this:

Usually, it’s possible to almost double your main skill set in the first 1–2 years, get some understanding of the work your colleagues (with different specialties) are doing and to enhance your soft skills.

Now you can do almost everything under the supervision of a more experienced colleague. Check if you can say this about yourself… Be honest! 😉

Senior Engineer

This step is much harder to do compared to the previous one. As you really need to make a shift in all of the areas. If you succeeded — it should look similar to this:

Same as above, you really need to develop your main skill, as it will be a foundation for your future career and give you the ability to be secure in the competitive market.

Here you also usually need to develop fundamental disciplines a bit, as they are necessary to solve the most complex tasks and write effective code. So it’s time to dust off those books about Computer Science, networking, algorithms, etc…

Your new description: this guy can do everything w/o supervision (and can supervise others) if there are requirements available.

It’s also worth mentioning that this is the right time to start practicing mentorship. It will help you to strengthen your communication skills as well as polish your main skills.

Team/Tech Leader

At some point you will be asked to kick off a new project and gather a team, or become a leader in your current group. Or you may move to another company and obtain a higher position. And the trick is this is only the beginning of the story 😀.

Now you usually need to learn a lot of new things really quickly. And “surprisingly” after all this mess with learning and adaptation period your skills will look something like this:

No progress in your main discipline, at all!. In fact, you may even lose some sharpness there, but let’s be optimistic :)

In this new role, you really need to progress in your soft skills as you now need to take care not only of yourself but also about the whole team. Your main goal is to ensure that the team works in the most effective way possible. So you are not obliged to work within the team, but you must work on the team. This includes things like optimization of internal processes, facilitation of task discussion and planning, helping team members with their self-development, etc…

You can even stop coding (which may not be a good idea as you will lose your skill completely) if your team performs well.

And try to lead by example and constantly grow your team members.

Architect / Head of the department

At this stage, you usually need to make a decision about your future career. Are you a more technical guy that wants to keep coding forever? Or do you want to become a manager and pursue positions like Director of Engineering, CTO, CEO?

Architect

At this position you will be actively interacting with stakeholders in order to envision, model and provide initial designs that can be built by the team. As well as validate more low level decisions made by the team. So you need to improve your fundamental knowledge in order to be able to make objective decisions that are based on facts and knowledge rather than experience and feelings.

Also, I would say that architecture is not only about technical systems design but also about people. You always need to account for the people you work with, and as a result the resources you have (ex: it’s usually a bad idea to suggest usage of Rust language if you have Go developers team). And even if you have a chance to build a brand new team, you should be able to form proper position profiles and hire the right people.

So you should really progress in your understanding of the overlapping disciplines and the ways different specialists collaborate with each other in order to design a system that can be built by the people you have (or will be able to hire) in optimal time. And yes, sometimes it’s ok to sacrifice technical excellence in order to make solutions “doable” for your team.

Head of department

If you selected the “alternative” way for your career, I have a surprise for you 😄 This is how your skills will look soon:

In this new role, you really need to progress in your soft skill set as you won’t be doing a lot (if any) hands-on work now. You will be delivering results with the help of your team(s) and you should be able to keep them in shape, help to solve issues, improve the skills of the individuals, find the right people, etc…

Consequently, you’re going to lose some of the deep knowledge you had before as your knowledge will become outdated and your mind will adapt to a new type of work.

A lot of articles already cover this topic so I don’t want to repeat everything here.

Summary

As you progress in your career path, the qualities needed to obtain the next position can be really different from what you currently have, as well as responsibilities. So I would generally recommend reading not only literature that is related to your current role, but also things that your boss and colleagues from overlapping areas read.

As for the race to catch all hype technologies — I would recommend staying up to date with all the new tools and products in the field of your deep knowledge, and familiarize yourself with the technologies that have come out or come close to the “plateau of productivity” in overlapping disciplines. This will allow you to stay on trend while still being focused.

I wish you all the best in your self-development process and career success.

Leave your comments and remarks below. It is always exciting to hear opinions or stories about alternative experiences from colleagues 😉

Also I want to say a big thank you to Namecheap, Inc for help with this article.

Web Components Landscape in 2019

Vlad Fedosov — Thu, 11 Jul 2019 10:14:20 +0000

Recently I was working on a research of the Web Components technology for my company (Namecheap, Inc) and found that it’s relatively hard to get an understanding of the overall state of the things as for now. So this article attempts to resolve this problem and provide you with a starting point to your journey.

Main concerns

Browser support
Frameworks compatibility
SSR + SEO / Bots
Styling
Accessibility
Versioning
Delivery
Available tools
Web Components vs Frameworks

Browser support

TL;DR: IE 10–11 and Edge (Chakra based) are out of the game as they do not support Shadow DOM. This makes use of the Web Components almost impractical due to the complexity of the polyfills.

All other browsers (Chrome, FF, Safari, considering 2 latest versions) work just fine with all major techs we need. Let’s looks at the table:

Frameworks compatibility

All major frameworks that exist nowadays fully support Web Components. But let’s look closely:

React/Preact — there are some issues with advanced integration :( And you may need to build React wrappers for WCs (can be automated).
Vue.js — works out of the box.
Angular — works out of the box.

SSR (Server-side rendering) + SEO / Bots

It’s theoretically possible to fully render WC at server side (and it even works for simple ones), but… There is no stable implementation yet, as well as way to represent Shadow DOM in HTML 😟 Community is actively working on a solution.

So what should we do then…? 🤯

The answer is simple – you can live without it (for Web Components). Of course this approach has some limitations but we have what we have… Let me explain the idea.

To render Web Components at client side only and do not sacrifice SEO / Bots compatibility you need to keep your content in Light DOM and use ARIA attributes. Treat your Web Components as native HTML elements. You can agree that you don’t need to render Shadow DOM for example for <select> element to see it’s content. If components are well designed, crawlers do not need a flattened tree to get text contents.

Let’s look at the Tab component markup as an example:

<my-tab-group role="tablist" aria-label="My test tabs">
  <my-tab role="tab" slot="tab"> Title for tab 1 </my-tab>
  <my-tab-panel role="tabpanel" slot="panel">Content 1 </my-tab-panel>
  <my-tab role="tab" slot="tab">Title for tab 2 </my-tab>
  <my-tab-panel role="tabpanel" slot="panel">Content 2 </my-tab-panel>
  <my-tab role="tab" slot="tab">Title for tab 3</my-tab>
  <my-tab-panel role="tabpanel" slot="panel">Content 3 </my-tab-panel>
</my-tab-group>

As you can see from this example you as a Bot don’t need access to the Shadow DOM to understand the content present on a page.

Styling

Because in our components we use Shadow DOM for their internal markup and slots for the content — writing CSS may become a challenging task at the beginning. Let’s go through the concepts we have here.

CSS Isolation

Shadow DOM almost completely isolates its content from page CSS. In our example we have <p> tag (that resides under Shadow DOM) content in green because color property was inherited.

How to include CSS into Shadow DOM

Nowadays the simplest way to deliver CSS for Web Components is to embed them inline into Web Component template. If you include them via <link> tag — you will see Flash of unstyled content during page load as in the example above (look at the “(I’m Shared CSS)” label).

However this limitation can be overcome by rather hiding all Shadow DOM content before linked CSS will be loaded or by additionally including component external CSS to the main page code (of course it should be scoped somehow in this case).

I’m looking forward to see Constructable Stylesheets being available in all major browsers. This would give us more control over CSS.

Context dependent styles

Often our components have different view modes depending on the passed arguments. Classic example is <select multiple>. When you pass multiple argument to “select” component — it fully changes its appearance. To achieve similar behaviour Web Platform offers :host() pseudo-class (don’t mix it with :host one).

Unfortunately this feature isn’t supported in Safari and iOS so we can’t really use it. As a workaround we can use power of JS to manually project host attributes and classes into root element within Shadow DOM to get an ability to write regular CSS.

Styling slotted content

Stylesheets that were added to the Shadow DOM may be also applied to the <slot> content. To do this we have ::slotted() CSS pseudo-element. However its browser support still non perfect. Look at the example above, Safari won’t handle ::slotted(p)::before selector correctly.

As a workaround here we can inject styles that are responsible for slot content styling into the page CSS. So the following selector ::slotted(p)::before written for <my-component> will be transformed into my-component p::before. Of course it breaks concept of the Shadow DOM a little bit but I don’t see another way out for now.

Recommendation

At this stage I would recommend to keep CSS, as you likely have it now, in a separate file, include it into the page via <link> tag and every Shadow DOM you’ll have. Currently I use the following code to keep it rolling:

class MyComponent extends HTMLElement {
  constructor() {
    super();

    this.attachShadow({ mode: 'open' });
    this.__injectGlobalCSS();
  };

  __injectGlobalCSS() {
    const globalCssInclude = _document_.querySelector(
      'head > [data-global-css="true"]'
    );

    if (globalCssInclude === null) {
      console.warn(`Can't find global CSS for component ${this.tagName}! Trying to render w/o it...`);
      return;
    }

    this.shadowRoot.appendChild(globalCssInclude.cloneNode(true));
  }
};

Accessibility

When users of assistive technology, like a screen reader, navigate a web page, it’s vitally important that the semantic meaning of the various controls is communicated. But how this can be achieved with Web Components considering that HTML tags will be custom and so will not have any semantic meaning?

Fortunately there is a solution, to bring semantic back to your custom elements you just need to follow WAI-AIRA specification. So if you already take care about accessibility — no much changes here.

Let’s look at the accessible slider component built with Web Components:

<custom-slider min="0" max="10" value="3" role="slider"
 tabindex="0" aria-valuemin="0" aria-valuemax="10"
 aria-valuenow="3" aria-valuetext="3"
 aria-label="Movie rating"></custom-slider>

To see more examples of the fully accessible Web Components you can also refer to the following samples from Google.

Versioning

Currently all Web Components must be registered in global registry. So you can’t have 2 versions of the same component on a single page. This follows approach that Browser use for the DOM, you have single version of it at a time. Simple.

But if you use Microservices approach at the Frontend or just have multiple apps running side-by-side on the same page — it may become an issue for you.

Let’s look at the options we have here:

Never do breaking changes. This is the principle that Browsers use. And while it’s possible to do it and it may even be the best option to start with, it’s obvious that it contradicts to the principle “fail fast, fail safe” and doesn’t facilitate innovations.
Tag based versioning. So instead of having <x-button> you would have <x-button-v1> to accommodate further major versions. So if “Fragment 1” requires button@1.1.5 and “Fragment 2” requires button@1.2.1 — button@1.2.1 only will be used. And if “Fragment 1” needs v1.1.5 and “Fragment 2” needs v2.0.0— both components will be registered.
Fragment based scoping. So instead of having <x-button> you would have <x-button-myfragment>

Delivery to Microservice based Frontend

You can skip it if you have single app at the client side. More info about Microservice based Frontend can be found here.

I would generally recommend to centrally manage bundle that reside outside of the Fragment and loads code of necessary components. Potentially Fragments may declare needed components and we can generate needed bundle on the fly.

Actual registration of the Web Component within Browser registry may happen globally or if picked up the last approach for versioning — at the Fragment level.

Available tools

Libraries you can use to author your Web Components (sorted by my preference, top to bottom):

LitElement – written by the guys from Polymer@Google. Optimal choice IMO.
Stencil – Web Components compiler plus base classes. Built by Ionic team. It has its own build system. Meaning components generated by Stencil can be consumed in any project, but components cannot live in the same project as the application consuming them.
SkateJS – tiny wrapper around native APIs that allows to use various renderers. Built by Trey Shugart who gave us WC SSR PoC.
Svetle 3 — it’s more a framework rather than library to simplify Web Components creation.
Riot.js
Slim.js
X-Tag — latest version still in beta
Smart HTML Elements – paid, framework agnostic library

But hey, do I really need some tool to comfortably write Web Components? And the answer is no , you can write them using Vanilla JS. And it will work for most of the (simple) components you will have.

Web Components vs Frameworks

To be short: they’re different. Don’t try to replace good old frameworks like Vue.js or React with Web Components.

I would say at this stage Web Component are really useful only if you need to have an instrument that allows you to write framework agnostic code for basic UI components from which you will construct pages with the help of your favourite framework.

Another use case may if you write sharable UI components library (like Bootstrap or MDC) and want to keep it framework independent. Example of the Material Design Components in pre-WC era and with WC.

As time goes frameworks may start to use Custom Elements and Shadow DOM internally but I wouldn’t expect to see it in the nearest 1–2 years.

Notes

If you see any gaps or mistakes in the material provided above pls post them in the comments or send me an email.

In case of the positive feedback from the community I hope to continue this topic and provide more in depth materials about nuances of the Web Components usage.

DEV Community: Vlad Fedosov

How to build your first Micro Frontend with SSR in minutes

We need React app with SSR first

Adapting the app to ILC

Configuring ILC to handle new app

If you’re using codesandbox.io (recommended approach)

If you’re running app locally

Summary

Maximizing Your Professional Value, from Junior to Leader

Basic model

Junior Engineer

Middle Engineer

Senior Engineer

Team/Tech Leader

Architect / Head of the department

Architect

Head of department

Summary

Web Components Landscape in 2019

Main concerns

Browser support

Frameworks compatibility

SSR (Server-side rendering) + SEO / Bots

Styling

CSS Isolation

How to include CSS into Shadow DOM

Context dependent styles

Styling slotted content

Recommendation

Accessibility

Versioning

Delivery to Microservice based Frontend

Available tools

Web Components vs Frameworks

Notes

Other articles to read