DEV Community: Samim Pezeshki

Micro Frontends: After one year with Single-SPA

Samim Pezeshki — Sun, 23 Jan 2022 09:00:42 +0000

Why did we choose micro frontend architecture?

We have a codebase that was originally written using AngularJS. After some years and when finally the news about AngularJS end of life came around, we started migrating to Angular (actually hybrid Angular/AngularJS). Finally, two years ago we successfully migrated to Angular (You can read the details in another post) having high hopes that by migrating to it we can leverage a new ecosystem. But after some months it became evident that Angular and AngularJS are so different that we need to rewrite everything, which is not very pleasant. Also, the React ecosystem and talent pool seemed much more vibrant so investing again in Angular for new upcoming features seemed like a non-optimal long-term solution. Over the years there were more experienced React developers in our teams so developing features in React would be much faster than having them in Angular.

So we were looking for options to be able to keep our current Angular app while being able to add new upcoming features and sections using React or other frameworks. After some search, we found out that micro frontends were the solution we were looking for! Using Single-SPA one can have multiple frameworks, Angular and React, running side by side. Single-SPA is composed of so-called apps each being a SystemJS or ES module. Each app can use a different framework and technology and it only needs to mount itself somewhere on the page. Apps are mounted and unmounted based on the page route. All of this happens client-side. As a side note, I was thinking if we had known about micro frontends, maybe we would never have migrated to hybrid Angular and would have chosen Single-SPA from the beginning.

Micro frontends are created for various purposes. Mainly it is discussed as a solution for keeping release cycles, deployments, and decisions in each team independent of others, like microservices but for frontend. In our case, we settled on micro frontends to be able to extend the lifetime of a legacy codebase by being able to take advantage of newer frameworks alongside old ones.

We also assessed some other micro frontend frameworks and solutions, even using iframes and server-side routing, but finally, we decided to go with SignleSPA as it is less opinionated, simple and the best fit for our current codebase. The website is fully static (Angular/AngularJS) and is served from a CDN, so using server-side routing was out of options.

Benefits

The main benefit was improving the developer experience. Each Single-SPA app is developed separately, so when a developer starts to work on a React app (Single-SPA app) he/she does not need to install all the dependencies for other apps, like Angular, or to know how other apps are configured. Also because each app is small the development cycle of local builds, hot-reloads, and tests are much shorter in time. Developers can build features (Single-SPA apps) truly independently and separately. So now we could use all the experiences of our React developers in our legacy website.

Each app in single-SPA is bundled separately. Using different apps for different features results in multiple small chunks, instead of a big fat bundle. Splitting the bundle can also be done by configuring Webpack without Single-SPA, but here we got it for free.

Apart from smaller chunks and bundles we got lazy loading too. Some features are not used frequently, so their bundle can be loaded separately in the background after the initial load.

As new feature apps are developed using React, even after migration to a whole new framework like NextJS in the future, those parts can be re-used without the need to rewrite everything from scratch.

Issues

One issue I had was that I could not generate source maps for Angular when it was built as a SystemJS module. I did not dig deep into the issue as it did not have a great impact on the project. But it is was nice to have source maps.

Another issue was the integration between the apps. We used local storage, global events, and shared modules for this and they all worked pretty well. But deciding on the best option was sometimes challenging.

Also as the whole concept is new, it took some time for the new developers to learn how to get on track, although this was negligible and even sometimes exciting to learn about new trends.

Code structure and deployment pipelines

All Single-SPA apps are put into a single repository. Each app has its own package.json file and is developed and built separately. There is also the root app which contains the main router responsible for mounting and unmounting other apps.

├── apps
│   ├── root
│   │   ├── node_modules
│   │   ├── package.json
│   │   └── src
│   │       └── index.html
│   ├── feature-one (Angular)
│   │   ├── node_modules
│   │   └── package.json
│   └── feature-two (React)
│       ├── node_modules
│       └── package.json
└── scripts
    ├── build.sh
    ├── deploy.sh
    └── start.sh

During deployment, there is a shell script that installs and builds each app and assembles them by copying the built files into a final build directory. Then it uses AWS Cloudformation to create a static website on S3, CloudFront, and Route53.

export ROOT_PATH=$PWD
export VERSION=4.0-$(git log -1 --pretty="%h")${BUILD_NUMBER}-$(date --iso)

for d in ./apps/*; do
  if [ -d "$d" ]; then
    echo " * Installing dependencies for $d"
    echo
    cd $d
    npm install
    npm run build
    mv dist $ROOT_PATH/dist/$d
    cd -
  fi
done

As a single deployment pipeline and repository is used for all the apps, we are not gaining from one of the main benefits of using micro frontends architecture which is independent release cycles for each app. But by putting everything in a single repository we could achieve what we were looking for without dealing with the complexity of managing multiple repositories and deciding on how to update import maps (solutions like import-map-deployer).

Development Experience

There are two ways to start developing. One is using the single-spa-inspector browser extension. This way the developer opens the fully-deployed live website (not localhost:3000 or any local address) and overrides the import maps to make the live website connect to the Single-SPA app running locally. This way the developer only runs the one feature app he/she is working on while running it inside the live deployed website. It frees the developer from running the whole website locally and even has the side benefit of seeing and developing the feature app in the context of the deployed website connected to the live database. This way of development was personally very unique and new to me, it was amazing.

Another approach is to start all Single-SPA apps locally. This approach is sometimes needed for debugging the integration between the apps. The below script is used to run all apps:

SCRIPT_ENV="${1:-dev}"
PORT=3000

echo "⚜    Starting ${SCRIPT_ENV}..."
echo
echo ⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺
echo "📡   Listening on https://localhost:${PORT}"
echo ⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽
echo

echo "⚠    Ignore if the below single-spa apps report about their ports! root app is served on port ${PORT}."
echo

npx concurrently --names "ROOT,FEATURE1,FEATURE2" \
  -c "#E0E0E0,#26C6DA,#FFA726" \
  "cd apps/root && env PORT=${PORT} npm run start:${SCRIPT_ENV}" \
  "cd apps/feature-one && env PORT=$(expr ${PORT} + 1) npm run start:${SCRIPT_ENV}" \
  "cd apps/feature-two && env PORT=$(expr ${PORT} + 2) npm run start:${SCRIPT_ENV}"

Road ahead

Adopting micro frontend architecture (Single-SPA) enabled us to further keep our legacy website while utilizing more trendy technologies to deliver new features. Otherwise, we had to rewrite the whole website or stick to what we had. Now that new features are delivered on time and we are on schedule plans can be made to rewrite the whole website without a rush.

With new trends, frameworks, and ideas popping up in the web development space every day, like server-side rendering, statically generated dynamic content, edge serverless workers, etc., I am not sure if we would again choose Single-SPA for a project creating from scratch. But for our use case, the micro frontend architecture served us well. If you have any framework or architecture in mind to suggest for our next project, please share, I would appreciate it.

Steps for upgrading AngularJS to hybrid Angular 9

Samim Pezeshki — Thu, 18 Jun 2020 08:02:15 +0000

Update: What happened a year after, read this

AngularJS end of life is near. Its LTS version will end on June 2021. So many projects using AngularJS have started considering the options. One option is to migrate to ReactJS, but some choose to ``upgrade and continue using Angular.

Recently I had to upgrade a 5-year-old codebase from AngularJS 1.4 to Angular 9. It took some effort as I had forgotten the tools which were popular in the olden times! The project used Gulp, Sass, and server-side Jade (Pug).

These are the steps to upgrade.

Install Angular

The first step was to install Angular CLI and bootstrap a new project right next to the old AngularJS app files inside the same repository.

Remove Gulp

Gulp was used to compile Sass files and concatenate JS files. Angular 9 uses Webpack to do this and it is configured by default. I removed gulp and its related files.

Sass files had a single entry. I added the entry file to the Angular's src/styles.scss so that all existing styles are compiled now.

`scss @import "app/main"; ... `

JS concatenation is not needed anymore because AngularJS is bootstrapped inside Angular and all dependent files are linked and bundled using the import syntax. I will discuss how to bootstrap AngularJS inside Angular in the next step.

If any files outside Angular needs concatenation or Sass compilation, Angular's Webpack can be customized and extended using custom Webpack configurations.

Bootstrap AngularJS

Following documentations here I used ngUpgrade to bootstrap the AngularJS module.

In the app.module.ts file:
`ts
import { UpgradeModule } from "@angular/upgrade/static";
import { angularJsModule } from "../ajs/app";

...

export class AppModule {
constructor(private upgrade: UpgradeModule) {}

ngDoBootstrap() {
this.upgrade.bootstrap(document.body, [angularJsModule.name], {
strictDi: true
});
}
}
`

You can see that I have imported angularJsModule. For it to work I had to refactor the AngularJS app a little bit. I created a new file to define the AngularJS module as angularJsModule and export it to use it in the code above for bootstrapping. Also in the process of refactoring, I decided to put all AngularJS code into a separate directory called ajs inside src.

`ts
import * as angular from "angular";
import ngStorage from "ngstorage";
import ngSanitize from "angular-sanitize";
import ngMaterial from "angular-material";

export const angularJsModule = angular
.module("MyApp", [
ngStorage.name,
ngSanitize,
ngMaterial,
])
.service("toaster", ["$mdToast", ToasterService])
...
`

It is better to define all services or directives you have in this file. If you have other JS files where you have defined services or directives you have to import them too so that they end up in the final bundle.

`ts import "./components/date-tools.svc.js"; import "./components/toaster.svc.ts"; import "./payment/currency-tools.svc.js"; ... `

It is better to import all needed dependencies in the same file where they are going to be used and avoid globally scoped variables like moment or lodash. If you have correctly imported dependencies they all will be in the final bundle. But sometimes refactoring the code and adding import lodash from 'lodash' to many files takes time so I added them to global scope temporarily to mitigate the issue for now.

`ts
import * as lodash from "lodash";
import * as moment from "moment";

(window as any).moment = moment;
(window as any)._ = lodash;
`

There were remaining scripts that did not work with the above method and which I needed to have in the global scope or need something like HTML script tag so I added them to angular.json file's scripts.

`json ... "architect": { "build": { ... "scripts": [ "node_modules/dropzone/dist/min/dropzone.min.js", "node_modules/d3/d3.min.js" ] }, ... `

Previously the project did not use npm to manage the dependencies. It used gulp to concatenate and bundle JS files and they were not pulled from node_modules. The library files were just copied into the project. In the process of removing gulp I also removed all library files from the project and let Webpack and npm manage those.

At this point, the app should have worked.

But I had one specific problem here. Many templates were compiled on the server-side by Jade (Pug) template engine using express's view engine feature. The main problem was the index.html file. Angular and in particular Webpack needs to create index.html to inject scripts and styles. I had to manually edit and convert this file from Jade to pure client-side HTML. Some variables were being injected from the server-side using Jade templates. I had to find other ways to access those variables. I ended up using Handlebars template engine instead of Jade because Handlebars is valid HTML and can be given to Angular. So I created index.html having Handlebar variables. Then Angular injects scripts and styles into it on build time and this file is finally served by express injecting server-side variables through Handlebars template variables. Ideally, I would like to not use Handlebars and passing variables this way seems not clean to me.

Here I configured Angular to use my Handlebars template file:

`json ... "architect": { "build": { ... "options": { "index": "client/main/src/ajs/index.handlebars", } }, ... `

Migrate Routes

The old AngularJS app used ui-router for routing. The good news was that ui-router can share routes between AgnularJS and Angular using angular-hybrid.

In the app.module.ts:
`ts
import { UIRouterUpgradeModule } from "@uirouter/angular-hybrid";
import { routerStates } from "./router-states";

...

@NgModule({
imports: [
UIRouterUpgradeModule.forRoot(routerStates),
],
...
})
export class AppModule {}
`

And in the router-states.ts file one route is using AngularJS and another route is using Angular:
`ts
import { VisaComponent } from "./trip-details/visa/visa.component";

...

export const routerStates = {
states: [
{
name: "documents",
url: "/documents",
templateUrl: "/views/documents",
controller: "DocumentsController",
redirectTo: "documents.manage"
},
{
name: "trip-details.visa",
url: "/visa",
component: VisaComponent,
}
...
`

Change Deployment Scripts

Finally, I had to change deployment scripts used by npm and CI/CD pipelines to use ng build command.

Development Server

There was still one specific problem to this project setup. In this project express server was set up in the same repository for both serving the front-end (and its server-side Jade templates) and also serving the back-end API endpoints. Angular has its own server used in development mode with hot-reload and specific configurations. For development, I wanted to have both the old express server (for APIs and legacy Jade templates) and the new Angular development server running at the same time.

So I used http-proxy-middleware. express can serve the APIs as before and also proxy requests to Angular development server running on port 4200 only in development mode.

in express-app.ts:
`ts
import { createProxyMiddleware } from "http-proxy-middleware";

...

if (process.env.NODE_ENV === "development") {
app.use(
["/client", "/sockjs-node", "/assets"],
createProxyMiddleware({
target: "http://localhost:4200",
ws: true,
pathRewrite: {
"^/assets": "/client/assets"
}
})
);
} else {
app.use("/client", express.static(path.join(dirname, "..", "public")));
app.use(
"/assets",
express.static(path.join(dirname, "..", "public", "assets"))
);
}

The ideal setup would be to separate concerns and put the back-end code into its own separate repository but that is a separate issue.

So, in the end, the development setup is something like this:

In the production setup, there is no Angular dev server.

Sharing Services and Components

To use a service or component from Angular in AngularJS we need to downgrade those services and components. In the same file that I defined the angularJsModule:
`ts
import {
downgradeComponent,
downgradeInjectable
} from "@angular/upgrade/static";

...

.module("GlobalWorldApp", [
...
])
.directive(
"nextPaymentPlans",
downgradeComponent({ component: PlansComponent })
)
.factory("nextPayment", downgradeInjectable(PaymentService) as any);
SonextPaymentis accessible as an AngularJS service and` can be used in AngularJS templates. So now we can start moving components and services from AngularJS to Angular gradually.

To access the AngularJS's rootScope from Angular we can inject it as a service, but better to avoid it if possible.
`ts import { IRootScopeService } from "angular"; ... constructor( @Inject("$rootScope") private _rootScope: IRootScopeService) {} ... `
Good to mention that to properly use the rootScope we need to watch it.

Linter

Setting up the linter is a separate issue and process from upgrading AngularJS. But I just want to mention here that I decided to remove tslint and replace it with eslint. Mainly because tslint is deprecated and also because of the smoother integration of eslint with prettier and other tools. I also love and use prettier everywhere I can.

Upgrade

After all these steps we can just start upgrading the app! I mean now we can let AngularJS and Angular components co-exist. So we can rewrite and move components from AngularJS to Angular gradually. The full upgrade takes months or even may never come. I think we will develop new parts of the app in Angular and only rewrite the AngularJS parts which are buggy or need refactoring.

I hope this helps others and future me trying to upgrade AngularJS apps.

Performance tips to have in mind while writing React components

Samim Pezeshki — Fri, 09 Feb 2018 15:53:47 +0000

As I was fine-tuning the React components I am working on, I tested and played with different ways I could re-write the code. I am compiling all the tips I learned, the performance tips to have in mind while I am writing the code.

Pay attention what you are sending as props into the component. React components trigger a re-render when props or state changes. Send props that change less often. For example, see the code below:

The index and selectedNoteIndex are passed to the component as props, this way changing selectedNoteIndex or anything that changes the index, changes the props and it triggers a re-render for all the components created by map! Another way to write the code above would be:

Now only a Boolean (selected) is sent to the component as props and the comparison is performd upper in the hierarchy.

Break large components into smaller ones. DRY. Big components are hard to maintain and fine-tune. Big components are all rendered at once. Turn the parts inside maps into their own components. For example, even if you have to pass index into the component in the example above, break the component into two parts, one that needs index and one that does not:

This way at least a part of the DOM tree is not re-rendered.

Have small states or none at all. Side effects and states are one of the main sources of bugs. Keeping state in sync with the props needs implementing the React life-cycle hooks which takes maintenance time. Try not to copy what is available in the props into the state. For example, to keep track of which row is selected in a table, you can save the entire row (as a big object) in the state or just save its index (as a number). Saving the entire row is tempting, you may think it is easier to access the row by this.state.selectedRow instead of this.props.rows[this.state.selectedRowIndex]. But the first approach leads to unknown consequences down the road. This may not totally be a performance tip, but having it in mind helps to reduce unwanted consequences tremendously..
Use JSS (or its one of its derivatives like withStyles in material-ui) instead of inline styles. Whenever you are using inline styles, you are creating a JS object. It might be OK for one-time usage. But for example, using inline styles in maps would be a terrible idea. Extract inline styles into their own object and reuse them, or better, use JSS for even more performance.
Reuse functions just like other objects. For example, when you want to pass a function and use it inside a map, instead of creating the function inline, like submit={() => doSomething(note.id)} , create the function in the class and pass the reference like submit={this.doSomething}. If you create the function inline, you are changing the component’s prop each time (because the newly created function has a new reference) and a useless render will be triggered.
Now that the component is small and the props are well known and documented (use flow or prop-types), you can easily implement shouldComponentUpdate and boost performance.
You can use PureComponent instead of Component wherever possible. Use it with care and enough test as the last resort. Make sure shallow comparison of all props is what you want. If all props are known you can implement shouldComponentUpdate yourself instead of using PureComponent.
UPDATE: Avoid having states up in the hierarchy. Use redux. When you have a state up in hierarchy, updating it will cause a render across the whole tree. You can store this state in the redux and connect it only to the component which needs it. So only the component will get updated when the state in redux changes.

In the end, always analyze the performance in Dev Tools while fine-tuning. Sometimes it surprises you by showing that the things that you may have considered beneficial for performance actually have made it worse.

How I transfer my vocabs from my Kindle Paperwhite to Anki

Samim Pezeshki — Fri, 03 Mar 2017 08:47:59 +0000

I read a lot on my Kindle Paperwhite and it really amazes me how many words can homo sapiens invent. When I look up a new word in the dictionary and see the equivalent in my mother tongue I wonder where I have learned this rare word or even when was the last time I heard it. Despite that I totally comprehend the word and the concept behind. Homo sapiens are amazing.

I want to read uninterrupted, save new words for later and add them to my Anki deck so that I can review them on my phone in my free time, or at the gym.

This is how I do it.

As you know when you look up a word in Kindle it is automatically saved in something called the “Vocabulary Builder” which is accessible from the upper right menu on the device. The words are actually saved in an SQLite database on the device along with its surrounding sentence. If you connect the device via USB the database file is located at system/vocabulary/vocab.db.

Then I have a Python script to read this database, ask about the words’ meanings interactively and add them to an Anki deck. Occasionally I copy the database file to my PC and run the script below in terminal.

#!/bin/bash

KINDLE=~/Backup/vocab.db
COLLECTION=~/Documents/Anki/User\ 1/collection.anki2
DECK=Words

kindle2anki --kindle $KINDLE --collection $COLLECTION --deck $DECK --clipboard

I have put the script on AUR if you are of that tribe.