DEV Community: Jan Hommes

Who does even need Microfronteds?

Jan Hommes — Mon, 25 Sep 2023 19:36:54 +0000

I lately have seen a lot of articles emerging around Microfrontends and how to implement them. Sadly, most of them don't answer a simple question: Who does even need Microfrontends?

Before I want to answer this question, let's do a small recap on what a Microfrontend is and what not. A Microfrontend is tightly coupled to Microservice (who would have guessed that 😜). Here, I do not mean the natural coupling of a Frontend to a Backend, but more of the design pattern of a Microservice. By definition, Microservices have three core values:

They are loosely coupled.
They can be deployed anywhere and standalone.
They can scale well.

These core values led to the Microservices popularity as they helped to migrate or avoid a monolithic architecture style where everything depended on each other which is hard to scale and maintain.
The same goes for frontends: If you end up (like me) building a huge frontend application with many features, you find yourself in a maintenance and responsibility hell (regardless of how well you test). Microfronends help to avoid this, by sticking to the core values of microservices (loose coupling, easily deployable, good scalability). Therefore they usually have one shell application and multiple remotes. The shell applications host those remotes (maybe one at a time, or multiple at a time). They are mostly loaded on runtime. You then share certain dependencies (like a common framework) and can load it from different servers. That mostly s serves the three core values of Microservices:

✅ loosely coupled: The shell and remote need to work on their own. You can share libs via e.g. Module federation.
✅ deployable anywhere: As it's just static files, any Webserver can easily serve the files.
✅ scales well: Webserver can be easily scale horizontal. Additional the teams working on them can scale too, as any team can focus on the domain of the microfrontend.

The main difference to Microservices lies in the weight of these 3 factors: For a frontend it is much easier to scale and deploy easily, while it is much harder to be loosely coupled. A simple example: Imagine two product teams, one working on the product listing of an e-commerce website, while the other are working on the search bar at the top. Now imagine, the UX designers decide to update the design principles and the search team adopts them faster than the product listing team. The whole website could look out of place (recently happened on the twitter renaming to X).

This gives already a hint on who really needs Microfrontends: As long as you are a one-man show or a small team, you should definitely avoid using a Microfrontend architecture at all. It just brings complexity overhead, which you should avoid in smaller teams. Even if you consider your teams might scale at a certain time, you should invest more in a domain-driven decoupling (maybe in different libs in a monorepo) than a Microfrontend architecture.

So, who needs in the end Microfrontends? In my experience there are only two types of projects that needs such an architecture:

Huge development teams (+3 teams on the front end) that need clear structures and consistency.
Applications that should be extendable by external plugins. For example, a dashboard that can be extended by external widgets.

If your application/website does not fall into one of the above sections, simply do not consider a Microfrontend architecture. Try to split your frontends into domain-specific sections and serve them in a classical way. Use style guides and shared libs to ensure consistency.

About me: I have been building a Microfrontend architecture since 2019 for Cumulocity (read more about it here). Contact me if you want to discuss Microfrontend architectures or any related work.

noNPM - node packages for micro frontends

Jan Hommes — Wed, 07 Dec 2022 19:47:14 +0000

What I built

I build noNPM (not only NPM) a node package server that serves the content of any package. It's like unpkg.com, but tries to avoid the issues around it.

Unlike unpkg.com, the packages need to opt-in by adding a serve property. Additional noNPM can be used in a local environment by running npx @no-npm/cli and serve all packages.
For demo purposes, also the cloud offering at noNPM.io serving currently all packages. Try for example:

https://noNPM.io/react

You can replace react with any npm package

Go to https://noNPM.io and you can search for all already used packages. You might notice that the base URL redirects you to https://nonpm.io/@no-npm/web/<<version>>/dist/web/. That works, because I simply serve the web interface also directly from npm. You can change the version number of the package to see older versions. For example, to see the first (not working) iteration of the web interface open https://nonpm.io/@no-npm/web@0.1.0.

This exactly is the reason why I build noNPM. It should allow to serve immutable web applications for a micro frontend architecture, so that teams can work better together on different features that get combined into one application without breaking them. With noNPM you can rely on the fact that every package is versioned, you can resolve packages via tags or versions and every version does not change. This allows to avoid running in a "version-hell" when using a micro frontend architecture.

Category Submission:

Search No More: As npm host more then 2 million packages, we needed a fast search. We leverage MongoDB to store the package meta information and search for them.

App Link

noNPM.io

Screenshots

Description

While NPM is great, with upcoming micro frontends trend, NPM does not serve the necessary of remote modules. While one could argue, that anyone could serve simply static files, the ability of NPM to manage versions, tagging and disallow reusing versions is exactly what is needed to run a micro frontend architecture. The following examples all resolve different versions of the @no-npm/example package:

import { remoteHello } from 'https://nonpm.io/@no-npm/example@1.0.1';
import { remoteHello } from 'https://nonpm.io/@no-npm/example@^1.0.1';
import { remoteHello } from 'https://nonpm.io/@no-npm/example@~1.0.1';
import { remoteHello } from 'https://nonpm.io/@no-npm/example@latest';
import { remoteHello } from 'https://nonpm.io/@no-npm/example@beta';

Link to Source Code

https://github.com/janhommes/noNPM

Permissive License

MIT

Background

I work currently on a micro frontend architecture and was wondering if we could leverage NPM to simply reuse the versioning and tagging possibilities.

How I built it

The REST interface is build with nestjs and hosted on Google Kubernetes Engine. On first request to a package which is unknown to the platform it will be extracted to a file storage. The metadata of a package is stored into MongoDB. Atlas search is used to find the package in the web interface.

The web-interface is build in Angular. It is uploaded to npm and as the REST interface can serve npm packages it also can serve this package. It queries the REST interface browse/search endpoint for showing the search-results in an auto-complete.

A CLI exist to use the same ability locally. If used locally, noNPM uses a simple JSON file to store the meta information of the packages.

Additional Resources/Info

noREST - schema-less REST API

Jan Hommes — Mon, 28 Sep 2020 18:14:08 +0000

I finally got the courage to publish my side project which I am working on for nearly one year. It's called noREST -> and, as the name implies, the name is referring indirect to noSQL. That's because the concepts are quite similar. Like noSQL, the differentiating is the non-schema layout of noREST. So basically it's an API without a fixed interface. You might question, what do I need an API without an interface for? It's like buying a house without a contract, or not?

You might be right: Having no fixed schema/interface on an API mostly sounds strange and does somehow contradict the intention of an API. APIs are designed to give the programmer an interface that defines how the data needs to be shaped. Like a purchase contract when buying a house: Everything needs to be in place, there are rules and rights that need to be followed and there is a notary who ensures the contract. If something in the contract is invalid the deal will not be signed.

However, even buying a coffee is already a purchase contract. And they mostly follow the same rules: The barista is offering the coffee and you are willing in on the contract by simply stating "Can I get grande latte chocolate whatever thingy". As soon as the exchange of money and "coffee" is done, the deal is closed. No notary, no fixed contract, no signing. Still a valid purchase contract.

The same goes for APIs: Sometimes the need for a simpler and easier contract then traditional schema bounded APIs is a valid use case. Especially when it comes to server-side-rendering or when you simply just scratching an app and want to focus on building the UI first.

That is what noREST is built for. By simply calling npx @norest/cli you get a REST-full server, which follows very simple rules (like buying a coffee). These rules are designed to allow rapid development. One of the core rules is, that there is no schema. Endpoints are defined by so-called index fragments which are simply data itself with a special prefix:

POST /api
{
   "name": "foo",
   "price": 10,
   "#_products": {}
}

Is the above data posted to the API, the data is requestable via a GET /api/products simply because the index fragment "#_products": {} is added to it. That way you can store any data to the API and still using it in a RESTfull manner. Like noSQL just for APIs. Simply called noREST.

What most people don't know: noSQL stands for not only SQL. Meaning that it allows more than just querying data. The same goes for noREST. Currently, there is authentication, metadata, references, and WebSocket support out of the box and more is planned as plugins.

If you like the idea, you can see all that in action on the small interactive playground at https://notonly.rest. If you want to dig deeper into noREST, the best way to start is the GitHub page.

Thanks for reading about my little side project. I would be happy to hear your thoughts about this?

The power of structural directives

Jan Hommes — Mon, 29 Jun 2020 19:22:38 +0000

Structural directives are a very powerful tool in Angular, but up till now, I rarely used them. The build-in ones are suitable for nearly every use-case I faced so far.
But lately, I reimplemented the *ngFor with a custom implementation of mine to implement an infinity scroll alternative. That was my personal "wow" effect and for the first time, I understood the full power of structural directives. This article should outline this power, but first, to the basics: What is a structural directive?

What is a structural directive?

I could not better phrase it then the angular documentation:

Structural directives are responsible for HTML layout. They shape or reshape the DOM's structure, typically by adding, removing, or manipulating elements.

So basically: Every time you want to restructure something in the DOM you use a structural directive. The most commonly used ones are *ngIf or *ngFor, which represent a condition or a loop on the template. Here is an example of how you could use a *ngIf on an Angular template:

<button (click)="toggle = !toggle">
  Show
</button>
<div *ngIf="toggle">
  I'm added or removed from the DOM with a structural directive.
</div>

Nothing really new about this. But, what mostly is unknown: You can build your own structural directive. Let's try to reimplement the *ngIf next.

Writing you're own structural directive

Basically it's plain easy to write your own structural directive, as it is just a normal directive. You just need to create a directive:

import { Directive } from '@angular/core';

@Directive({
  selector: '[superIf]'
})
export class SuperIfDirective {
  constructor() {
    console.log('init');
  }
}

And you can already add it as a structural directive and as a normal directive:

<div *superIf>Test</div>
<div superIf>Test</div>

When you try that plain example, you will find only one Test output on your app. But the directive was actual initialized two times:

That is because the * is syntactic sugar which will wrap the component where this element is attached within the template. So, in fact the following is the same:

<ng-template [superIf]>
  <div>Test</div>
</ng-template>

You can verify this by using our above *ngIf example. If you change the *ngIf to use the above layout, it will still work the same:

That's basically all of the mystery of structural directives. They are just syntax sugar for writing cleaner templates. As soon as you have access to the ng-template you can manipulate the DOM to your need. The next chapter will show how you roll your own ngIf.

Building your own ngIf

It's really not that hard to build your own ngIf as soon as you understand the basics: A structural directive is syntactic sugar for a directive that is wrapped in an ng-template. That is why you can simply inject the template reference to your directive and use it to attach it to your view.

First, we need to add the TemplateRef and ViewContainerRef:

import { Directive, TemplateRef, ViewContainerRef, Input } from '@angular/core';

@Directive({
  selector: '[superIf]'
})
export class SuperIfDirective {
  constructor(
    private tpl: TemplateRef<any>,
    private vcr: ViewContainerRef
  ) {}
}

The ViewContainer reference is the point, where your structural directive is placed in the current view. Think of it as an invisible placeholder, which you can append any template to. This is what we are doing in the next step:

  set superIf(expression: boolean) {
    this.vcr.clear();  // 1
    if (expression) {  // 2
      this.vcr.createEmbeddedView(this.tpl);  // 3
    }   
  }

The setter with the same name as the directive will ensure that we get the value that is assigned to our directive. Then we simply always clear the view when the setter is called (1), afterward we check if the expression is truly (2) and if yes, we create the template into our view container "placeholder" (3). The result works exactly as the *ngIf we know of:

Easy, right? You might know that there are more functions. For example, there is an else in the default *ngIf. Also, this is fairly easy to implement when you know of the ability to pass multiple values to a directive:

@Input()
set superIfElse(template: TemplateRef<any>) {
  this.elseTemplate = template;
}

This allows you to pass an else template to the directive either with the structural directive micro syntax: <div *superIf="toggle; else notTrue">.
Or, as this is just sugar, we can also use the directive approached on a template: <ng-template [superIf]="toggle" [superIfElse]="notTrueDirective">

What is left is to check if the else template is set. If it is, and the expression is false, we attach this template instead of the one the directive is placed on:

  @Input()
  set superIf(expression: boolean) {
    this.vcr.clear();
    if (expression) {
      this.vcr.createEmbeddedView(this.tpl);
    } else if(this.elseTemplate) {
      this.vcr.createEmbeddedView(this.elseTemplate);
    }
  }

That's all, you now created an *ngIf replacement. You can see the full example here. If this is useful? I don't think so. Why reinventing the wheel? But it's super useful to understand the concept of structural directives. Next up we will build an actual useful directive.

Doing something useful

So rebuilding the build-in directives is nice for understanding the concept but it doesn't bring any benefit. This chapter tries to implement something easy and at the same time useful.
Therefore we are going to develop an usefulAssign directive which should allow to write cleaner templates. The problem is mostly known to Angular developers: When you request an observable which resolves to an object you often end up in reusing the async pipe over and over again:

<div>
  min: {{(interval$ | async).min}}<br />
  s: {{(interval$ | async).s}}<br />
  ms: {{(interval$ | async).ms}}
</div>

That looks strange and gets very confusing soon. The idea is to use a directive for this to bind to an implicit variable. Then you can use this variable instead of reusing the async pipe over and over again:

<div *usefulAssign="interval$ | async; let timer">
  min: {{timer.min}}<br />
  s: {{timer.s}}<br />
  ms: {{timer.ms}}
</div>

The result: Much cleaner templates and less async pipe usage. The implementation is quite easy, we just need to add a context object to the createEmbeddedView function and the first implicit variable gets the value assigned.

The $implicit is a special type of context, which doesn't need an assignment. You can add more which need to be assigned in the template (e.g. interval$ | async; let foo = bar. If bar is defined in the context as { bar: 'foobar' } then the foo variable contains the foobar string).

The directive itself then looks like this:

As you can see in this example, the value passed to the directive is assigned as an implicit context (1) and therefore available in the template. This allows many different approaches as you can pass any context which you can then reuse in the template easily.

What else?

So this article is just a short introduction and should show what structural directives can do. This is just the tip of the iceberg and some more ideas are:

Using it as an infinity scroll solution in combination with paged REST API and the Intersection Observable API. Imagine using *infinityFor="let image of images" and you get infinity scrolling without doing anything more, by simply using the same approach as *ngFor and an additional hidden "load-more" component at the end of the list. This loads more data as soon as it is intersected.
Templating for more complex components like tables (like Material CDK does it).
dynamic components loading

However, it is always questionable to reinvent the wheel. Don't use a custom structural directive, if a build-in can do the same job.