DEV Community: Burhanuddin Udaipurwala

Module Federation in Production: architecture, development workflow, and deployments

Burhanuddin Udaipurwala — Fri, 10 Mar 2023 05:56:25 +0000

Introduction

Micro-frontends are an architectural pattern that breaks a web application into smaller, loosely coupled, and independently deployable parts. Each part of the application is owned by a separate team and can be developed and deployed independently, allowing teams to work more efficiently and without interfering with each other

This article focuses on optimising developer experience in a micro-frontend built with Module Federation while achieving team independence in deployments. A general understanding of Module Federation is assumed; if you need an introduction, you can watch my talk on Module Federation and how it works here.

Why Module Federation

Module federation is a feature of webpack 5 that enables developers to share code between multiple webpack builds, allowing them to communicate with each other and build distributed applications with greater scalability and flexibility.

Module Federation has emerged as a powerful tool for enterprise-scale applications. It is easy to configure and allows code to scale horizontally rather than vertically, by distributing the code between different builds

Building a shell based architecture

Module Federation is un-opinionated but my suggestion is to use a shell-based architecture, where the shell is a lightweight base that handles routing between micro-apps, initialisation of shared data stores, and lazy loading of each app. The shell is initialised first, and then, based on the route, it lazy loads the apps to be rendered.

Ideally, the shell should not contain any business logic and should only bring in the micro-apps that perform the actual work. However, routing between apps is one exception where some business logic may be required.

The shell should not use any front-end framework, since the micro-apps themselves could be built with different frameworks. Additionally, any code added to the shell should be independent of any specific framework.

To keep the shell lightweight, it's important to minimise the amount of code added to it. Adding code that is not required by all apps will unnecessarily increase the bundle size of the shell. Therefore, it's best to add only the necessary code and avoid adding anything that is not essential for its functionality.

You could store common code, such as component libraries that are shared between all apps, in the shell. Alternatively, your micro-apps could be either "apps" or "packages". Packages are pieces of code that are imported by apps but can be deployed independently of them. The component library/ design system can be a “package” which is independent from other apps and can be also deployed independently.

Micro apps should avoid direct communication with each other to prevent creating an implicit dependency between them. When one app changes its stored data, other apps that depend on it are affected, which adds undesired complexity.

As an extension of above, one could build an architecture where there are multiple shells, and each shell is its own product. The shells load micro-apps which are required by the product

Optimising for developer experience

A great developer experience in a micro-frontend would involve the ability to build an app in isolation. Unfortunately, this is not always possible due to the need for libraries or shared code that is imported from the shell at runtime. This can cause problems when the development server for the shell breaks because it tries to load code from another app whose development server is not started.

To address this issue, you may have to spin up multiple development servers for different apps, even if you only want to work on one. While tools like Nx and Turborepo can help reduce this pain by allowing developers to share build cache between machines using the cloud, it would be even better if you didn't have to run those development servers at all. In the following section, I will explain how to achieve this.

The goal is to only start the development server for the app you are working on. Other code should always be loaded from either a CDN or an already running server elsewhere. This ensures that you always get the latest code for apps developed by other teams. Additionally, which apps to be loaded from the local dev server and which ones to be loaded from the CDN should be granular and easy to switch between, like the press of a button.

This is the system we'll be looking at: you can switch between a local development server and an already-built bundle of the micro-app with just the press of a button.

In this example, we will use a client-rendered app. We will primarily use two tools: a browser plugin called Redirector and a CDN like AWS's CloudFront. If you prefer serving static files or if the app is server-rendered, you can even use an NGINX reverse-proxy. However, for this example, we will only be using CloudFront.

Switch between pre-built bundles and the development server using the Redirector extension

Let's discuss the switch that enables us to granularly switch between a local build and a cloud build. This switch is essentially the Redirector browser extension.

The advantage of using this browser plugin instead of passing arguments on the command line interface (CLI) is that you do not need to restart the webpack development server.

The way the redirector extension works is by using a regex pattern. It examines all outgoing requests and redirects any request whose path matches the regex pattern to another URL specified by you. This URL can be the path of the local development server.

The extension allows us to add multiple regex patterns, each representing the URL of a micro-app. These can be easily enabled or disabled with the click of a button.

Since we expect to be building many micro apps, it is important to establish a naming scheme. A possible scheme is to include a path in the middle, such as /federated/. This way, each app can have a unique URL like /federated/my-micro-app/.

So lets say the CDN is at the URL https://my-federated-app.com and the remote entry file for the micro-app is at https://my-federated-app.com/federated/my-micro-app/remoteEntry.js. Then, if I want to work on this app using a local development server, I can redirect any request containing the pattern /federated/my-micro-app/ to http://localhost:3000 , where the development server is running. Here’s an example of the configuration that does the above job:

This way, I can have multiple apps running locally, each development server running on a different port. I can switch between their local and cloud builds using the Redirector browser extension by enabling or disabling this rule

The CloudFront configuration

The configuration will be similar to that of the Redirector plugin. The idea is to use CloudFront's “behaviors” option to route requests appropriately to the folder in S3 where the app is stored.

For example, let's consider the following structure for storing builds in S3 for all of your apps.

|-- shell
|---- remoteEntry.js
|---- (other js assets)
|-- my-micro-app
|---- remoteEntry.js
|---- (other js assets)

Next, you can configure the default behavior of CloudFront to fetch files from the shell folder.

If your domain is my-federated-app.com, by default, all requests will go to the shell folder. In the CDN configuration, you can add a behavior to redirect any request that contains the path /federated/my-micro-app/ to the corresponding “my-micro-app” folder using the pattern federated/my-micro-app/*. You will need to configure this for each micro app that you build.

Note: An important thing to keep in mind for client-side rendered apps is cache busting of remote entry files. Since you can't use content hash to name these files, they will get cached at the CDN and in the user's browser, which can cause problems when builds are out of sync. One way to fix this issue is to invalidate the CDN cache after every app deployment.

Note 2: Alternatively, you can create a "federated" folder inside the "shell" folder. However, this is not recommended as a simple mistake could override all the files inside the "federated" folder or even delete that folder.

Note 3: Depending on the size of your team and organisation, you could use the same CloudFront configuration to serve apps from different buckets. Each micro-app would have its own S3 bucket, allowing for even more separation. For even larger scale, each app could have its own CloudFront CDN with a dedicated sub-domain to serve assets from.

Conclusion

In conclusion, Module Federation is a powerful tool for building large-scale micro-frontend architectures. By breaking up a web application into smaller, independently deployable micro-apps, teams can work more efficiently and without interfering with each other. Using a shell-based architecture and minimising direct communication between micro-apps can further optimise the scalability and flexibility of these architectures. Finally, optimising for developer experience can be achieved by using tools such as the Redirector browser extension and AWS's CloudFront CDN.

This is the first article in a new series I am writing on micro-frontends with Module Federation. In the next article, I will discuss state management strategies to be used in a micro-frontend. If you'd like to be notified when I next publish an article, you can subscribe to the newsletter at burhanuday.com

Monolith to Module Federation at RazorpayX

Burhanuddin Udaipurwala — Sat, 18 Feb 2023 10:23:12 +0000

Growing fast at RazorpayX

RazorpayX is a neobank for businesses that combines the best of B2B SaaS and B2B Banking, to make finance simpler and more efficient. Its state-of-the-art Current Account combined with award-winning Payroll, Corporate Cards, Vendor Payments, Tax Filing and Accounting solutions, helps businesses manage all their financial activities from one place

We experienced exponential growth at RazorpayX during the pandemic when online payments became the norm. With more businesses going online, business owners saw RazorpayX as their one-stop shop for all of their banking needs.

As a result, RazorpayX’s frontend developer count has more than doubled. Simultaneously, to serve a broader range of businesses, we introduced significant products such as the Chartered Accountant Portal and Vendor Portal. Our codebase had become a giant monolith and developer productivity as well as the speed of delivery of features was taking a hit.

To give you an idea of how challenging it had become to maintain the monolith, the upgrade from React 16 to React 17 took more than two weeks to complete. Due to the large codebase, we had to upgrade React all at once for the whole dashboard, which meant fixing all breaking changes between the two React versions in one go and risking regression when pushing such a large change.

Why did we reach such a stage?

Lack of a reusable Auth

The authentication system was not designed to be reusable and support multiple apps.

Inability to quickly spin up infra for projects

Creating new codebases required the creation of CI pipelines and other deployment infrastructure on AWS. This was not a priority during a time when getting the product to market quickly was critical.

Lack of a reusable component library

We had UI components built in the same repo rather than a library. As a result, we were unable to easily share UI component code between products.

Issues due to the monolith

We began to encounter some issues as the codebase grew in size:

Long build times

As the size of the codebase increased, it took longer to start the development server and for HMR to reflect developer changes.

Long-running unit tests

Time to execute Unit tests grew exponentially with more and more apps being powered by RazorpayX’s repo.

High cognitive load

Since code for multiple apps resides in the same repository, it increased the surface area of code a developer needs to understand thereby increasing the cognitive load on a developer.

Lack of independent CI/CD

Because the same codebase that powers the RazorpayX dashboard for merchants, also powered the dashboard for vendors, chartered accountants and tax payments, any small change in one app required the deployment of all the apps.

So we began to consider what we could do about it: can we break our codebase into smaller independent modules, where each module could be developed, tested, and also deployed independently from the others?

Finding the right way to do it

The first project to be moved away from the X Dashboard codebase was Vendor Portal. We chose Vendor Portal because, if not for the above explained constraints, it would have been an independent project. It was less coupled with other code in the codebase and would serve well as an experimentation project.

Before adopting a potential solution, we devised a set of criteria that it must meet.

The criteria for the solution

In addition to solving the above discussed pain points, the ideal solution would check all of the following boxes:

Should have good developer experience.
Should not require drastic changes to the codebase.
Should be relatively easy to configure.
Should have a gradual learning curve for developers.

Potential solutions

After a lot of brainstorming around the problem statement, we came up with a few things that could be implemented:

Publish each app as an NPM package

Each app could be published as a package to NPM. The package version in the host can then be updated, and the host must be redeployed
The limitation of this approach is that we would have to redeploy the host every time we published a new version of a micro app. This method works for libraries that require versioning, but it slows down deployments for projects that require continuous delivery

Bundle each micro-app individually and load with a Script tag

Each micro-app is bundled and uploaded to S3 or a similar store. The host app loads the script via the URL
This method is very crude. Deduplication of dependencies, for example, is completely manual and must be configured for each project so that a dependency is loaded only once. In the case of some packages, such as React, the library should only be instantiated once as a singleton which adds more complexity

Using micro frontend frameworks

There are numerous micro-frontend frameworks like Single SPA, Open Components, Mosaic, and so on
The configuration for these tools can get complex and difficult to manage as we add more apps since they require configuration at each layer — routing, dependency management, and development. This would complicate our tooling and hence, would not work for us.

Using Module Federation with webpack 5

Module federation is a webpack5 feature that allows a JavaScript application to run code from another build. It allows us to reference code from a different project at runtime. You can read more about the concept here.

Module Federation is a run-time concept, and other tools, like Jest and Typescript, lack the same functionality. Making other tooling operate with Module Federation is complicated and requires a lot of configuration

Among the solutions we tried, Module Federation turned out to be the solution that ticked all the boxes.

What is Module Federation?

In simple words — it allows you to share code between different webpack builds at runtime. It enables you to expose files from one build and consume them in another. It is a method of achieving a micro frontend architecture.

Module Federation creates a very thin but well-defined contract layer between apps. It allows you to be flexible with what you want to slice out of the codebase and if the transition doesn’t work well, it also makes it easy to bring the application piece back in.

Our proposed architecture

The architecture we are aiming to build is a shell driven federation. The shell contains the logic for navigation, lazy loading of routes, instantiates a common Redux store to be shared between all apps, and exposes code shared between all micro apps. Each team can deploy their changes independently.

An important thing to note here is that we do not want to share any code between apps. This can create a mesh of dependencies which might result in future bugs.

After the migration of the Vendor Portal to a federated bundle, the system currently looks like this (simplified)

The monolith (shell) exposes UI components that are used in the Vendor Portal codebase. The shell and Vendor Portal have their own independent deployment pipelines and are stitched together at run-time by webpack in the browser.

Migration and Challenges

Moving to a federated architecture wasn’t easy. It took us a little less than 3 months to properly migrate Vendor Portal completely. We faced a few hurdles along the way and built tooling and processes that worked for our teams.

As a part of the migration process, we also migrated the Vendor Portal code to a monorepo because it makes solving the below challenges easier.

Now, let’s deep dive into some of the challenges we faced and how we solved them.

Sharing dependencies

A common problem with all micro frontends is how to de-duplicate dependencies. This is important because we don’t download the same dependency twice

Examples:

MomentJS: Both, X Dashboard and Vendor Portal, use moment for date and time, and we want it to be loaded only once in the browser. At the same time, we want to ensure that the version loaded is compatible with the modules that rely on it.
React: Dependencies that have an internal state, like React, should be instantiated only once and then reused across all federated modules as a singleton.

We wrote a utility function to solve this problem:

const dependencies = require('../package.json').dependencies

const getSharedDependencies = () => {
  const singletonPackages = [
    'react',
    // other singleton dependencies here
  ]

  const sharedDependencies = {}

  Object.keys(dependencies).forEach((dependencyName) => {
    sharedDependencies[dependencyName] = {
      singleton: singletonPackages.includes(dependencyName),
      requiredVersion: dependencies[dependencyName],
    }
  })

  return deps
}

Then in the configuration for Module Federation plugin:

new ModuleFederationPlugin({
   // ...
  shared: getSharedDependencies(),
}),

Testing in federated modules

We run tests on the pre-commit hook using Husky. Since the code in Vendor Portal is dependent on UI code from X Dashboard, it must be present when tests are run (this is not an issue if the code is in a monorepo).

We leveraged jest’s moduleNameMapper to rewrite certain imports by Jest. This allows us to use actual code for running tests and not mocks as mock code in our tests would mean that tests will pass even after a breaking change if the dev forgot to update the mocks.

const xRepoBasePath = '<rootDir>/../../razorpayx'
module.exports = {
  // ...
  moduleNameMapper: {
    // ...
    // module federation related config
    '^razorpayx/store': `${xRepoBasePath}/src/js/store`,
    '^razorpayx/ui': `${xRepoBasePath}/src/js/ui/index`,
    '^razorpayx/views': `${xRepoBasePath}/src/js/views/index`,
    '^razorpayx/model': `${xRepoBasePath}/src/js/model/index`,
    '^razorpayx/modules': `${xRepoBasePath}/src/js/modules/index`,
    '^razorpayx/api': `${xRepoBasePath}/src/js/api/api`,
  },
  // ...
}

Type-checking

At RazorpayX, we have been migrating towards Typescript and want to be able to use the types defined for our UI code. We want type safety and auto-completion for developers writing their code locally. On CI, we want to run type checks to make sure that there are no TS errors.

For this, we use Typescript’s Project References feature. It enables a project to reference types from a different project:

{
  "compilerOptions": {
    // ...
    "paths": {
      "razorpayx/ui": ["<razorpayx>/src/js/ui/index"],
      "razorpayx/views": ["<razorpayx>/src/js/views/index"],
      "razorpayx/model": ["<razorpayx>/src/js/model/index"],
      "razorpayx/modules": ["<razorpayx>/src/js/modules/index"],
      "razorpayx/api": ["<razorpayx>/src/js/api/api"],
      "razorpayx/store": ["<razorpayx>/src/js/store"]
    }
  },
  "references": [{ "path": "<razorpayx>" }]
  // ...
}

The above example is tsconfig.json file of Vendor Portal. In the references array, we add a path to the RazorpayX Dashboard codebase. It tells TypeScript about which other projects to reference for types. In the paths property, we assign types to the code exported from the RazorpayX dashboard using their path. This does require you to have both codebases on your local machine as well as CI, although this is not a challenge if your code resides in a monorepo.

Note: If your code is not inside a monorepo, you could take a look at the recently open-sourced Types Federation Plugin. One drawback of this plugin is having to manually add types to imports which the above approach does not suffer from.

CI actions with multiple repositories

We use GitHub actions for running tests and type-checking on PRs. Since not all of our code is in a single repository, for the time being, we clone both the repositories we need in the workflow. Checking out code is fast on GitHub actions so it has not affected the CI times in a significant manner.

We then run the tests command and type-checking on the Vendor Portal codebase on every push to the repo against the master branch of the RazorpayX Dashboard codebase.

What has this effort resulted in?

After the migration, vendor portal has its own codebase, independent CI/CD pipelines, independent dependency management. All this has led to the following improvements:

	Before (entire dashboard)	After (independent module)
Build time	180+ seconds	14 seconds
Starting development server	90+ seconds	12 seconds
Running tests	8-10 minutes	~2 minutes
Deployments	The entire codebase has to be built and all apps will be deployed.	Only Vendor Portal code is built and a single app is deployed
Cognitive load on developers	High cognitive load owing to the large codebase size	Limited codebase size ensures faster onboarding and ease of development
Dependency management	Change in dependency version affects all apps powered by the codebase	Dependency versions can be scoped to apps which ensures that each app loads its supported versions

Where do we go from here…?

Overall, Module Federation has solved a lot of problems for us and we are migrating towards a federated architecture to enable developers to ship faster.

We are working on solving the developer experience hurdles that a distributed micro frontend can create and at the same time, ensuring that the code we ship is resilient.

Having infrastructure pieces that support this architecture has been of tremendous help. Check out Devstack on GitHub which allows us to use different commits when we develop Vendor Portal.

If you want to understand our decision-making and reasoning about Module Federation in more detail, you can watch this talk we gave about the same on YouTube

This article was originally published at Razorpay's Engineering Blog

Get updated when I next post, subscribe at burhanuday.com

Hitting the tech local maxima

Burhanuddin Udaipurwala — Wed, 05 Oct 2022 08:31:31 +0000

What exactly is a local maximum?

I am not using the mathematical definition of the term. For the purpose of this discussion, let’s have two functions of effort spent vs value generated.

Initially, both functions are linear in nature, where spending more effort generates more value. Spending more effort leads to diminishing returns after the point where the most value is generated.

Now you have to make a decision about which function you choose:

The first requires a lot less effort to reach the point where you generate the most value. The caveat is that it does not generate as much value as the other option in the end.

The other option is a “global maximum”. It is a decision, which if you take it, will need high effort. The advantage of taking this decision is that it will generate more value before you reach the maxima.

To limit the scope of this discussion, we will limit the functions to the point where the maxima are reached.

Let’s assume that once the maxima are reached, no more effort is spent.

Also, let’s not argue about where the points are on the graph. The graph is not to scale.

So you might be thinking “boring problem” or “how does it relate to my job?”. Well, let me give you an example:

The library conundrum

Let’s imagine a scenario. You started working on a new greenfield project at your company. You have to architect the frontend, so you start working on how the codebase will be structured and which libraries will be used.

State management is an important choice to be made. You think about using a server state management library since the dashboard you are building is a UI that displays some data to the end user. You research which server state management libraries are popular at the moment, and you see two of them being talked about a lot — React Query and SWR. You also have to keep in mind that nobody in the team for the project has used either of them before.

You start evaluating the two of them and come to the following conclusions:

React Query is a powerful library that can handle both queries and mutations. It has a steeper learning curve compared to SWR. It does a lot more than SWR can, and you’ll be extracting a lot more value from it. But it requires a lot of educational effort to be made
SWR is a simple data fetching library. It cannot handle mutations, but the learning curve is very gradual and the developers will pick it up quickly

Which brings us to the original conundrum:

You could use React Query. It would have a steep learning curve, and the developers would take more time to get onboard with it. It could also slow down the development a bit in the initial phases. A steep learning curve would also mean that a lot of mistakes would be made before best practises are established.
Or you could use SWR. It is simple to get onboarded to and does not require a lot of configuration to get working. But the issue with SWR is that it does not handle mutations and might be missing some things. Due to the simplicity of the library, there will be fewer mis-steps and development speed will not be affected.

Concerns

In an ideal world, there would be a right decision to be made with a book explaining why. Since we don’t live in an ideal world, we often have to make decisions based on incomplete information and an optimistic mindset.

The time dilemma

Do you know what’s worse than making the wrong decision? Making the right decision but leaving it half done

Making a decision is one thing, but driving it is another. If the decision you take requires more sustained effort, you have to make sure that the effort is actually put in. Otherwise, even if you commit to the “higher effort, higher final value” option, you will never extract the full value. The incomplete work will live in pieces and cause more problems

On the other hand, if you have to spend less effort, it might be comparatively easier to get it prioritised. It will also reach its full potential in less time.

Post completion shock

Let’s say you chose the "lower effort, lower final value" and then drove it to completion. At the end of it, you are not happy with the value you have extracted. Now that the decision has been made and the work is completed, you can’t do anything about it.

You feel like you should have taken the other decision, even though it required more effort to be put in. You would have received more value out of it on completion. What if…

Making the choice

Looking for an answer? I don’t have one. Ask an experienced engineer and they’ll tell you.

Have you made a decision? Let me know on Twitter or by Email

Driving technical change

Burhanuddin Udaipurwala — Tue, 05 Jul 2022 03:55:50 +0000

A young engineer just joined your company. They've come straight out of college and have mostly worked on solo projects prior. They discover that the documentation in the codebase is inadequate, so they add a new user-friendly tool to improve the documentation. Nobody cares. The newbie is surprised at how nobody wants to see an improvement made. In the newbie's mind, the tool they added improved the documentation of the codebase. Why would everyone not want to contribute to it?

A senior engineer then mentors them on how to drive technical change. He tells them:

Implementing something is the first part. Driving change is the next. Like a bus going at high speeds, an engineer has inertia. Until a force is applied, they won't change the direction they're going.

Now imagine the newbie is you.

Is it worth the effort?

Bringing about change requires active work to be done. Before you even start driving it, you must ask yourself the following questions:

Do you completely understand the problem that you're trying to solve?

Before you even start solving it, make sure you have a deep understanding of the problem. For this, you can speak to your colleagues and ask around if the problem you're trying to solve is being faced by a lot of people. You'll come to understand the challenge and gain a deeper understanding.

Is the problem you're trying to solve "important" enough

Some problems are just inconveniences that one can live with. Like auto-formatting not working for a file extension. Then some problems are productivity killers. For an example, think how much slower web development would be without Hot Module Reload.

So it's better first to solve problems that you know are "important" problems that if solved, would have a large impact

Has someone else tried (and failed) before you?

If the problem is obvious, then there is bound to be someone who has tried to solve it before you. Ask around if something of the sort has happened. They probably solved it differently, and as the saying goes:

Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others

Not only that, knowing the previous solutions and their shortcomings, you'll be able to come up with a better one that caters to your specific requirements.

What solution do you have in mind?

So you discussed the problem, and you know it exists, but can you solve it? It's best to come up with multiple ways to solve a challenge and then compare them to figure out which one works best for your particular use case. Not every solution is created equal, after all.

Enforceability

Is it possible to enforce the change? For example, if you intend to set a standard for code style, you can use a tool like Prettier or Eslint to enforce this. On the other hand, let's say you are proposing that all developers write unit tests. There might not be an easy way to enforce this.

Is the result worth the investment?

This is the most important question to answer. The costs should justify the returns. This again ties back to a previous question—"is it important enough?" You need to weigh the outcomes with the effort you're putting in to solve the problem.

What if your solution only works for a short term and becomes completely obsolete after that.

To pave the way for the future

So you've understood the problem, figured out the solution and are wearing your battle armour ready to mash some buttons on your keyboard. But hold on, you can't do everything alone, right? Not forever, anyway. So you need to convince your peers to help you. But why will they? They have plenty to do on their own. They don't want to do extra work they aren't getting paid for.

Convincing the leadership

You decide to talk to your manager about it so your peers can get dedicated bandwidth for it. But how exactly are you going to explain it to them? They are not from the same domain as you are, and even if they are, they haven't written a line of code in years. And god forbid, your manager is not a tech person at all.

So you build a demo. A simple MVP that demonstrates both the problem and the solution without any other bells and whistles. The manager seems to be impressed with your demo. They speak to the skip manager about the change you are proposing and how it is going to solve a problem. The skip manager then asks -

Well, our sales numbers for the past year ain't lookin' so good. Can this tool help with that?

Hmmm... so how do you convince a company that is working on rapid product development to slow that down and give you, and probably others, bandwidth to work on this pure tech project?

It's pretty simple really - Show its business impact.

Can your proposed change reduce the build time by half? Tell them faster deployments equate to better developer productivity, which equates to more stuff being built faster.

Can your proposed change make documentation more intuitive? Tell them better documentation equates to better developer productivity, which equates to more stuff being built, faster

Can your proposed change reduce production errors? Tell them it will improve customer delight.

Every company cares about profits, but companies also care about customer satisfaction, employee productivity, and attrition rates. If you can push any of these metrics in the company's favour, then you will be allocated what is required.

Defining a success metric

That alone won't suffice. You need to decide on a metric. A number to push will not only tell leadership that progress is being made, but it will also give confidence that your solution is working.

When starting, decide on a baseline. Then decide on a short-term goal for the next month and a long-term goal for the next three months. This will give you direction and tell you how slow or fast you are moving.

There's another thing to keep in mind regarding this number. It should be transparent, easy to compile, and visible to all.

To give you an example, if the change you are driving is the addition of e2e tests, then maybe your metric can be the number of P0 incidents every month. And your goal is to reduce that number. You can also count how many times e2e tests have prevented a bug from going into production and saved your butts. You could compile this metric at the end of every month and show how e2e tests are helping prevent money loss incidents.

Tracking adoption

Another thing to do is report on the progress of your change. It will keep you motivated to achieve your goals. Similar to the success metric, you also need to keep track of the adoption metric.

For tests, it could be the test coverage of the codebase. If you are migrating to Typescript, it could be the percentage of the files in the codebase that are in Typescript.

Similar to having transparency in success metrics, it helps to be transparent here as well. It keeps you responsible for delivering on your promises and tells leadership that effort is being put into this migration.

Gaining adoption

Now then, coming to the change itself - you won't be able to drive it alone

You will need help and contributions from your peers too. Since we have already spoken about managers and leadership, let's talk about your peers. There are different kinds of engineers with different beliefs. From the perspective of driving change, I'll categorise them into the following categories:

The Skeptics

They will question the change you are driving. They are usually experienced engineers who have been burned in the past by incomplete migrations or flimsy tooling that someone else, just like you, built. The way to align them is to first, know your problem, have an approach outlined, and be confident. With some work, a skeptic will turn into one of the other categories

The Pilots

These will be the first contributors to the change. Your focus must be on motivating these people to start contributing to the change. They will provide valuable feedback that will help you

The Mentors

They will not contribute directly to your project. However, they will help align other engineers, managers, and leadership to your efforts. To give you an example - they will help engineers get allocated sufficient bandwidth to work on the project

The Mid Stage Adopters

Initially, they might or might not know that a change is being driven. They will come into the picture when the project has approached a more stable stage.

Remember that they are the vast majority. So once you have gained a few early adopters, you can focus on this group. You will need to educate and evangelise them in order to persuade them.

The Late Adopters

Like the name suggests, they understand your change but do not want to exert effort towards it. The reason might be that they either don't believe in it or they might be time-crunched. I suggest not spending too much time on this group since they will be a minority

Note: There will be overlaps between these groups. They are not strict categories

Experiences may differ

Every company is different. So I'm excited to hear about your experiences. Have you driven a change at your organisation? How did you align the stakeholders? What challenges did you face? Let me know on my Twitter

Did you like what you read? I try to publish two articles a month on this blog. You can subscribe for updates on my site https://burhanuday.com

Credits and attribution

Cover image - Industrial automation vector created by pch.vector - www.freepik.com

Why is there hype around Module Federation

Burhanuddin Udaipurwala — Fri, 24 Jun 2022 04:35:26 +0000

I joined Razorpay last year on the frontend team building RazorpayX, the neo baking solution for startups and SMEs. Our front-end is very much a complex dashboard with multiple products, each handled by a different team. With multiple frontend devs working on the codebase, I have witnessed the codebase grow at an exponential rate.

It took longer to start the development server, tests ran for longer, building was slower and CI jobs ran for over an hour. So I asked the question, does every company face this? See their codebase turn into a monolith, with unwanted coupling between apps. And the answer seems to be a yes.

I want to ship the product faster. I don't want a text change to take 3 hours for deployment. I want deployments to be scoped to individual apps. But I also want to be able to share a common store between apps and share UI code easily. I dont want complex configurations and architectures.

So I started reading about the possible solutions to this problem. I found out about the following methods:

NPM Packages flow

Each micro app would be an NPM package published to the company package registry. The host app would be a shell that would have all of these packages listed as dependencies. The package versions would only increase by a minor (ie 0.0.x) so that NPM would always resolve to the latest version to download

To update an app, you would have to only publish a newer version for that particular app. Which is something that can be automated on a merge to master and can be done multiple times a day

To deploy a newer version of the dashboard, you'd have to run the pipeline for shell again. This can be done as many times as a new deployment was required.

There was still a problem here, I'd have to migrate all library code (or common UI code) into its own package to be shared between apps. I would also have to manually depulicate these dependencies myself for each package. This would be a major migration effort for a pretty sizeable codebase. Hard pass.

There was still another problem here. When I wanted to deploy a newer version for an app, I would have to trigger two deployments sequentially. First, publish the app itself. Then remember to also rerun the shell pipeline so that the latest app goes into production. All that effort would not be worth it for a minor improvement

Microfrontend frameworks

Then I started looking at the existing microfrontend frameworks. I went through the docs of the popular ones - SingleSPA, Open Components, and Mosaic.

In each of them, I found that it required a lot of configuration to set them up. Configuration would be required to handle routing, state sharing, code sharing, dependency deduplication.

Each project would have to be configured manually to deduplicate the dependencies between them. Each solution had its tradeoffs that I was either not comfortable making, or couldn't make due to the architecture of the existing dashboard that we have.

Module Federation

The new kid on the block. Module federation in the words of its creator:

Webpack 5 Module Federation aims to solve the sharing of modules in a distributed system, by shipping those critical shared pieces as macro or as micro as you would like. It does this by pulling them out of build pipeline and out of your apps.

Translated to simple words:

Module federation allows you to use code from other projects in your project, at runtime

It allows you to share code at runtime, as opposed to build time. This is the major difference between Module Federation and mono-repos. But then, Module Federation is not a microfrontend framework, it is simply a tool that allows you to share code at runtime.

The Module Federation plugin for Webpack 5 simplifies a lot of configuration that would otherwise be required to be done for the above-mentioned solutions:

It simplifies dependency deduplication by allowing you to pass a list of dependencies via the shared parameter.
Exposing code and using it is simple, it looks something like this

// Remote App
new ModuleFederationPlugin({
   name: "microapp1",
   filename: "microapp1.remoteEntry.js",
   exposes: {
   "./index": "./src/index",
   },
}),

// Host App
new ModuleFederationPlugin({
   name: "host",
   filename: "host.remoteEntry.js",
   remotes: {
      microapp1: "microapp1@http://localhost:3001/microapp1.remoteEntry.js",
   },
}),

// Usage in host
import Remote from "microapp1";

And so, code sharing is pretty simple. Does not require you to make any changes to how your codebase is structured

Conclusion

So to conclude, I see the value proposition of Module Federation. It fits right into the build toolchain since its a part of Webpack. The configuration required is little and the learning curve is non existent. It does not seem to require any drastic changes to the codebase. If you are interested in trying out Module Federation hands-on, I have a demo available here - Module Federation with Webpack5

Did you like what you read? I try to publish two articles a month on this blog. You can subscribe for updates at https://burhanuday.com

Don't over-engineer it

Burhanuddin Udaipurwala — Wed, 26 Jan 2022 05:08:26 +0000

Of course you should write your new side project with the newest fad in trend.

Of course it must be server-side rendered with the smallest JS bundle and the most optimised user interactions.

Of course it has to be served from the Edge in under 120ms.

Of course it's fine if it takes 6 more months to build.

Of course it's fine if the competition takes the lead.

Your site is the best because you are using the best new framework recommended by everyone on YouTube.

No! you don't need to do the above because no one is going to use your shitty product anyway.

To nobody's surprise - 10xer discovers that side projects move slowly when you rewrite them in a new JavaScript framework every 3 months

You might think I'm being mean and I might be. However, this is something that every engineer needs to hear from time to time. You are spending too much time thinking of optimisation when you don't even have a product-market fit.

Does it really matter if your habit tracker runs at 120 FPS if nobody uses it?

In the early days of your product, performance shouldn't be the top of your priorities. Finding a market fit and a user base should be. That will only happen if you build rapidly and are agile enough to move according to customer demands. Products that fail to understand this, just fail at everything.

Recently a friend asked me if they should use a combination of React and React Native for their new business idea. I asked them if they had a team of 3 developers working for them. On being told "no", I advised them to just use Capacitor to bundle their web app into an Android and iOS app.

I expected to hear "Isn't that bad for user experience?" (which I did). Can most users tell the difference between native and non-native apps? No, not really. Before you tell me that hybrid apps are UX nightmares - There is no bad framework, only badly written code.

When building a business, start with something you already know. For tools of convenience, you don't need the best framework in the world. JUST START

You must prioritise your business requirements over fun-to-do things in the initial phases of your product for the following reasons:

If you are going to fail, you'd rather fail fast. Waste less time learning things while building your product. For learning, build smaller side projects with no intention of monetising them
If you work with what you are already comfortable with, you will build much faster than someone who is still learning

Last weekend, I met a friend who is working on a proximity-based chat application as a side project. They told me they were using MongoDB as the database with Firebase Cloud Functions (FCF). I asked them the reasoning for not using Firestore (Firebase's NoSQL datastore) since it's much easier to configure and use. They told me it was because MongoDB is more performant than Firestore at geolocation queries. A week later, they came back to me and said they were moving to Firestore because it was easier to use.

Again, emphasises the point that you should start with whatever you know. When the demand comes, move quickly

How many of your side projects did you start with a new framework but never finished building. Was it because you were too busy learning that new framework when you should have been actually been focused on building your project.

I am working on a small utility for readers. If you are someone who reads a lot of blog articles or newsletters, hit me up at @burhanuday or email me at udaipurwalaburhanuddin@gmail.com. I'd love to have a chat!

To get updated when I write my next article, subscribe to my newsletter at burhanuday.com

How not to let social media and your phone destroy your life

Burhanuddin Udaipurwala — Sun, 16 Jan 2022 14:20:45 +0000

Phone addiction is a serious problem across all age ranges. Recently, a friend told me that they went to bed at midnight but were up till 3 AM scrolling Instagram. They said they lost track of time.

I suffered from the same syndrome and would constantly have the urge to check my phone every few minutes. Even in the middle of work. To the point that my phone and social media apps were distracting me from working

My average phone usage time would be close to 6 hours a day. I was in a bad mental state and my phone (read social media) addiction was making it worse. I wanted to reduce my usage of Instagram, Twitter, Linkedin, Discord, and Reddit.

How to use your phone without being miserable

There are two ways to cure your phone addiction. The first is to take the band-aid-like approach and pull it off in one go. Most people are likely to give up on this. I still recommend that you start with the "Quick and painful" approach and only use the milder method when it doesn't work for you. Regardless of the approach you take, I still think that these techniques are likely to help you.

Quick and painful

The quick and painful method is to uninstall all social media apps from your phone and only open them from the browser

Use social media only from the browser

Social media apps like Twitter and Instagram have never-ending feeds and timelines. We get addicted to them because they give us a small dopamine rush every time we scroll the feed.

I uninstalled social media apps from my phone. I logged into all these apps from my desktop computer. It helped because firstly, it took more effort to go to the browser and type in the URL. And secondly, I could use LeechBlock to restrict myself from opening social media sites during my work hours

You can also experiment by logging into these apps from your phone's browser. Since those web apps are not optimised for mobile devices they give you an inferior experience. If you hate the scrolling experience, you wouldn't want to scroll

If you hate the scrolling experience, you wouldn't want to scroll

This is how I got rid of using Instagram because the web version sucks. Try watching a story or two on Instagram web, you don't want to. It is slightly more difficult to uninstall system apps. The method demonstrated by XDA here requires caution. As long as you don't uninstall random things, your phone should be fine. This is how I got rid of YouTube and I still don't have it installed on my phone.

Put your phone on silent mode permanently

Sometimes I would get the feeling that my phone was vibrating even when it wasn't. I kid you not, this is a real illness that has been extensively documented and is a sign of mobile phone addiction.

The easy way out is to put your phone on silent mode and forget. Then when feeling like it is vibrating, you tell yourself that it isn't because it can't be.

Another way is to put your phone in silent mode and to leave it in a different room. Putting the phone out of your sight will reduce the urge to pick it up again and again because you don't see it that often

Mild and slower

A lot of these solutions revolve around using the app Digital Wellbeing (Play Store).

If it's not available for you on the Play Store, you can side-load the APK from APK Pure.

I recommend also using Nova Launcher. I like it because it is functional, customisable and doesn't do too much. You can also use Lawnchair Launcher.

Keep an empty home screen - out of sight, out of mind

The problem was that whenever I turned the screen on, I saw shortcuts to those social media apps on my home screen. I would open them out of muscle memory. I would then forget why I picked my phone up and started scrolling whatever feed I had in front of me. The easy solution was to remove all home screen shortcuts. The only way to open those apps was through the app drawer. That would require extra effort which increased my resistance to opening the app again and again.

When I started, I built a special launcher for myself that would be boring yet functional. miny is still available on the Play Store but I don't use it anymore. You might want to give it a try. I haven't worked on it in a while so expect plenty of bugs

Turn off all unnecessary notifications

If you don't want to give up on the installed apps that quickly, another way is to disable notifications. You can go to Instagram's and Twitter's settings to disable alerts. Disable as many as you'd like. If you get fewer notifications, you are less likely to open those apps. I have notifications enabled only for Direct Messages. I have disabled all other notifications

You can also go to Digital Wellbeing and see which apps send you the most amount of notifications every day. There are also apps available that aggregate notifications for a few hours and send them all at once at times you specify.

Digital Wellbeing also has a focus mode that blocks notifications for specific apps. It gives you the choice to allow important apps to still send you important alerts. I like this feature a lot and use it while I am working. It prevents me from getting distracted

You can also use Android's DND mode and switch off all notifications. You can keep notifications for calls on so if there's anything urgent, someone is likely to call you

Use direct shortcuts to features instead of navigating

This is again if you haven't uninstalled social media apps from your phone. The launcher I use, Nova Launcher, has this cool feature that allows me to go to different parts of the app directly. This saves me the effort of navigating through unnecessary parts of the apps and going to where I want directly. For instance, if I want to message someone on Instagram, I can directly go to the chats screen rather than opening the app and getting distracted by the feed.

I also use a Nova launcher extension called Sesame Shortcuts (it's a paid app with a free trial) that takes this idea to the extreme and provides a ton of other features. You probably don't need it but it's pretty cool nonetheless

Limit usage with digital wellbeing

I used Digital Wellbeing to set timers for social media apps. Once the assigned time gets depleted, Digital Wellbeing will restrict your access to those apps. They will appear greyed out and you won't be able to open them. It will also hide the notifications from those apps to prevent any further distraction.

You can start by allocating larger amounts of time for each app and then reducing the time at the start of the week until you have reached your desired usage.

How it has helped me

I used to be glued to my phone for about 5-6 hours a day. I have now brought it to somewhere close to 1.5 hours. That is if you ignore the time spent calling. It's erroneously reported since that's the amount of time I spent talking to people outside of social media.

I don't believe that you should completely go off of social media. I do believe that you should restrict the time you allocate to it.

Connect with me

If you'd like to discuss, DM me on Twitter. For updates, subscribe to my newsletter at burhanuday.com

Get the most out of your Root Cause Analysis meetings

Burhanuddin Udaipurwala — Tue, 21 Dec 2021 14:36:39 +0000

Whenever something breaks in production, an INCIDENT ticket gets created on Jira. An Engineer/ Developer will figure out what went wrong and attach a document called RCA document to the ticket. This article talks about the process of what happens after the problem is figured out and how you can encourage other developers to learn from mistakes made in the past.

At RazorpayX, we have a scheduled RCA meet every Thursday. We discuss issues that occurred in the past week and what we learned from them. The environment is of curiosity and the theme is to understand and learn.

RCA meetings are also called Postmortems at some organisations. They refer to the same thing

An RCA meet or Root Cause Analysis meet is a formal meeting where you discuss why and how a particular problem occurred. It is not specific to the tech industry and this practice originated in the medical industry to analyse the cause of patient deaths. However, it is also useful in debugging and educating developers about software related problems.

The goal of this exercise

The goal of this exercise is to understand all contributing factors and causes, document the incident for future reference and also create action items to reduce the likelihood of this problem occurring again. This exercise can also be performed async but from what I have seen, most folks prefer scheduling a meeting to discuss the document.

It could be a frontend bug, backend failure or even a DevOps issue. The goal is to inform and educate other stakeholders about what went wrong and analyse the cause of the problem. These meetings are not to assign blame towards an engineer or interrogate the team on why a particular system failed. If this is what is happening at your RCA meets, you need to restructure how you perform them.

An engineering leader organises and leads the meeting. The meeting should be conducted with a clear goal and theme in mind and the participants should be pre-informed about the topic. Usually, an RCA document is created to be shared across stakeholders to read up before joining the RCA meet. If the problem has affected parties outside your organisation, a separate external RCA may also be created with relevant information to be sent to the third party.

The RCA Document

The RCA document is a story where your bug is the antagonist. It explains their rise to power as well as their eventual downfall and the changes they brought about.

There are a few things that an RCA document must contain:

1. Problem Description

This is a no brainer. Every RCA document should succinctly describe the problem at the top of the document and give a brief overview

2. Timeline of events

It should contain all the details about when the issue was discovered, by whom and how was it reported. It should also contain the first response time to the issue as well as every escalation event. If the issue has been fixed, it should contain the timeline events about the fix as well.

3. The 5 WHYs

The 5 WHYs are a great way to explain the issue. It is an interrogative technique where each question forms the basis for the next one. A very simple example would be:

Why does the Earth have seasons?

Ans) because the Earth revolves around the Sun

Why does the Earth revolve around the Sun?

Ans) Because of the Sun's gravitational pull

This is a great tool because it helps you get closer to the root of the problem

4. Action Items

Hurray! you identified the problem... but now what? Every RCA document should contain action items about what is/was done to resolve the issue. These items help the broader audience understand how the problem was mitigated and might help them in the future.

5. Impact

An issue can impact one customer or thousands of customers. It is important to understand the scale at which the problem has occurred and the impact that it has created. This also helps estimate the severity of the problem

The meeting

It is a good idea to limit a meeting by time. At RazorpayX, our RCA meets are time-limited to one hour. Sometimes we discuss more than one issue depending on how complex the problem is. This helps you keep discussions on point.

Ask the participants to pre-read the document before joining the meeting. This will help save time which would have instead gone into explaining the problem during the meeting.

A team member from the team performing the postmortem of the issue takes the participants through the RCA document. At the start of the meeting, describe the problem and clarify any doubts about the problem itself. After which, you get into the probable causes, discuss the timelines and speak about the action items. Here, participants may give suggestions about the action items and may ask for more information about the issue.

You should also leave time in the end for questions from the participants of the meeting. Focus on the pointers above in the meeting as you go through the document with the participants.

What you shouldn't do in the meeting

Place blame upon someone: as I stated before, these meetings aren't for blaming other people. They are there to offer learnings and help stakeholders understand the problem
Get sidetracked into side issues: focus on the issue at hand and don't rant about an irrelevant issue
Become a victim of bias. In hindsight, everything is obvious

Conclusion

You will see that in these meetings that resolutions were "common sense" and the problems were all "obvious oversights". You will also encounter many flawed assumptions as well as learn about different systems and how they interact with each other. See these meetings as learning opportunities at your company rather than a way to shift the problem onto someone else. Engineers should not be penalised because, frankly, bugs are expected even with software having years of maturity

At the end of an RCA meet, you should have the following points clarified:

How did the issue occur
How was the issue resolved
What was the turnaround time for resolution
What were the process gaps that led to the issue
Were there any architectural mistakes that led to it
How can similar problems be mitigated in the future
What are some suggested changes that could be made to reduce issues like these

7 lessons from a fresher after 3 months at Razorpay

Burhanuddin Udaipurwala — Tue, 19 Oct 2021 15:44:49 +0000

Time flies

I started programming about 6 years ago when I built my first shitty Android app. It was a phone directory of sorts, and I had no idea what I was doing. Fast-forward to 6 years later at Razorpay and I still felt like I had no idea what I was doing

3 months have passed since I joined Razorpay in July and I feel like I am a full 3 months wiser. Here's some stuff that I have picked up in the past 3 months

Disclaimer: There isn't going to be any code whatsoever in this post.

Don't work more, work extra: What's the difference? Let's say you have a project that if you worked 7 hours on every day, you'd complete in a month. If you instead worked on it for 8 hours a day, you would complete it 4 days before the deadline. The only person you would be making happy is your product manager. If you instead spent that 1 hour trying to improve your codebase, or automating something or reducing tech debt or even building something that makes life easier, you'd make a team full of developers happy. You'd be creating a much greater impact
Stick to your deadlines: The thing about working at Razorpay is that I decide my own deadlines. The problem with that is that if my timelines are not accurate or are not running on time, everyone else who depended on my tasks being complete to continue their work will also be delayed. This snowballs into the whole project being delayed. Estimation is a skill that comes to you with experience and thought. Only promise what you can deliver. Take into consideration your sick days, holidays, and vacations.
Talk to your colleagues: This is not so obvious. When I started working, my conversation with my colleagues was limited to work. Your colleagues, especially the ones with more experience, have a lot to share. You will only get their wisdom when you talk to them informally. This is especially difficult due to remote work so it will take effort on your side to form a relationship
Buy a good chair: You will be sitting on a chair for the greater part of your day. Save your back and buy a comfortable chair that has good lower back support. I don't have any recommendations to give but buy something comfortable. It doesn't have to cost 15k, you can get one for around 1.5k that will be just as comfortable. Also, stand up and stretch after every 45mins of work. Backache will be a real problem even for someone in their 20s
Don't work on the weekends: Don't fall for the hustle culture crap. Weekends exist for a reason. They exist because they allow you to rest and take time off of work. Rest rejuvenates your mind and body and allows you to be more productive in the coming week.
Learn outside of work: To progress in your career, you will have to do more than is expected of you. You can increase your technical skill by learning new stuff on your own time. Build something with what you have learnt. Take out 30 mins every day in the morning, before starting work to read up about something. What I generally do is make a reading list in a To-Do app and try to read 2 articles every day.
Have a goal in mind: You will not progress unless you have a realistic goal in your mind. "Where do I see myself in the next appraisal cycle?" It sounds cringy but appraisals are a record of your performance throughout the year. If you have nothing impactful to show, you won't go far. This point ties well with point 1. Your goal does not have to be limited to the next appraisal cycle either. Ask yourself "do I want to code for the next 20 years?" "Do I want to manage people instead and become an Engineering Manager?" "Do I instead want to talk to customers and become a Product Manager? This choice is difficult but once you think about it and have clarity, it will help you in making decisions.

There's a lot more I'd like to add to this post, and maybe I will. Subscribe to my newsletter at burhanuday.com,or follow me on DEV and you will be notified when I post my next article. If you want to talk to me, come over at my twitter @burhanuday

Bundle a React library with Parcel

Burhanuddin Udaipurwala — Sun, 17 Oct 2021 14:29:57 +0000

Parcel is a bundler for Javascript and Typescript projects. They recently released version 2 of the project, and it comes with a lot of performance and usage improvements. It automatically installs required dependencies without having to do any complex config or setup. It really lives upto its name when it says it's "The zero configuration build tool".

Initialise your project

Create a new project with either npm or yarn. For this guide, I will be using yarn
To create a new project

yarn init

Then follow through the guide to create your package.json file.

Since this is a library, you need to add the following lines to your package.json file so that the consumers of your library can automatically figure out the build paths

source tells Parcel the entry point of your project
main will be the path for generating your output JS bundle
module path creates an ES Module target

"source": "src/index.js",
"main": "dist/main.js",
"module": "dist/module.js",

if you are using Typescript you can change the source property to src/index.ts instead and add "types": "dist/types.d.ts" to tell Parcel where to spit out types for your library

To generate a tsconfig.json file for your project, run

npx tsconfig.json

and select React from the menu. That will generate the appropriate config.

After that, add the following scripts to your package.json file

"scripts": {
    "dev": "parcel watch",
    "build": "parcel build"
},

You will use these scripts to develop and build your project later

Installing dependencies

We need to install Parcel, React and React DOM as dev dependencies

yarn add -D react react-dom parcel

Also add React as a peer dependency in your project. Add to package.json

"peerDependencies": {
    "react": "^18.0.0"
}

This tells library consumers what version of React your library supports

Optionally, if you are using Typescript, you also need to install Typescript

yarn add -D typescript @types/react @types/react-dom

Creating a component

To demonstrate the bundling process. I created two files in the src directory. Create a directory called src and add the following files

Button.tsx

import * as React from 'react'

export interface IButton extends React.HTMLProps<HTMLButtonElement> {}

const Button: React.FC<IButton> = ({ children, onClick }) => {
  return <button onClick={onClick}>{children}</button>
}

export default Button

index.ts

import Button from './Button'

export { Button }

Your directory structure should now look like

src
    -> index.ts
    -> Button.tsx
package.json
yarn.lock

Bundling

To build your project, run

yarn build

This will generate the output inside the dist directory

You can run

yarn dev

to start a development server and Parcel will listen to changes in your files

Closing note

I think Parcel v2 is a fantastic bundler and simplifies project configuration. It automatically detects the framework and language you are using and will install appropriate helper packages

Checkout the Parcel website (Its pretty cool!) - Parcel

You can follow me on DEV or subscribe to my newsletter at https://www.burhanuday.com/ to get notified when I publish my next article

Build your own styled-components

Burhanuddin Udaipurwala — Wed, 04 Aug 2021 14:10:54 +0000

styled-components is a CSS-in-JS library that uses the tagged template syntax in JavaScript and allows you to write actual CSS inside your React components as opposed to the object syntax. If you haven't used styled-components before, the below example from the official documentation should give you a brief idea about what styled-component is:

const Title = styled.h1`
  font-size: 1.5em;
  text-align: center;
  color: palevioletred;
`;

Why is styled-components important

styled-components does a lot more than just enabling you to write CSS inside your React components. Here are some other advantages:

Automatic Vendor Prefixing: Since some CSS features need to be prefixed for different vendors like -moz or -webkit, styled components handles this for you automatically, so you write styles without having to worry about browser compatibility
Duplicate class names: In large projects, you may run into clashing class names. styled components prevents this by assigning random hashes as part of your class names. So your class names remain readable yet random and prevent clashes at the same time
Simplified dynamic styling: The styled-components syntax makes it easier to apply dynamic styles without having to change the class name of components using JavaScript.

There's a lot more that I skipped for brevity's sake. Read more here.

Haven't used styled-components before?

styled components also allow you to pass the same props as you would pass to normal HTML tags.

const Title = styled.h1`
  font-size: 1.5em;
  text-align: center;
  color: palevioletred;
`;

const Wrapper = styled.section`
  padding: 4em;
  background: papayawhip;
`;

render(
  <Wrapper>
    <Title>
      Hello World!
    </Title>
  </Wrapper>
);

The above code renders the following

The tagged template syntax

Tagged templates may look weird at first but it is valid JavaScript syntax. I won't go into a lot of details here but you can read more about it at MDN

Setting up the development environment

I am going to be using CodeSandbox as my development environment. If you want to publish your library to npm, I'll suggest using method 2 to generate a React library

Method 1

Using codesandbox.io React template

Method 2

Using create-react-library to scaffold a React component library.

First, create a new JavaScript project with

npx create-react-library stylish

then CD into the folder

cd stylish

To start the dev servers, open two terminals and use the following commands:

Terminal 1

npm start

Terminal 2

cd example
npm start

The first terminal compiles your JavaScript component. The second terminal starts a Create React App project dev server, which allows you to use the component in a project and makes it easy to visualize your changes.

Let's work on the library

We will develop the project in steps

Installing necessary libraries

stylis — stylis is a lightweight CSS preprocessor that handles cross browser compatibility for our library
nanoid — nanoid is a unique string generator that we will use for randomizing class names and preventing clashes.

Run the following command to install these two libraries only if you have setup your project with Method 2. In CodeSandbox, you can add these libraries from the left sidebar.

npm i stylis nanoid

Basic structure

Let's create a function that returns a React component and export it as the default export from the file

const stylish = (Tag) => (styles) => {
  const NewComponent = ({ children, ...props }) => {
    return (
      <Tag>
        {children}
      </Tag>
    );
  };
  return NewComponent;
};

export default stylish;

If you now consumed stylish, you would see that this renders an h1 tag in your DOM. It does not match the exact styled components syntax, but we will fix that later. Also, the styles don't work yet since we aren't using the prop

import stylish from "./stylish";

const H1 = stylish("h1")`
  color: red;
`;

export default function App() {
  return (
    <div>
      <H1>Hello CodeSandbox</H1>
    </div>
  );
}

Styling the component

Right now, we aren't using the styles passed down at all. But before we use them, these styles need to be preprocessed using stylis. To do that,

import { compile, serialize, stringify } from "stylis";

const preprocessStyles = (styles) => serialize(compile(styles), stringify);

This does two things, it first adds vendor prefixes to your CSS code and minifies it so that it takes less memory

Now we want to generate a unique class name for our component and then inject it into the browser stylesheet. To generate a unique component, we will use nanoid.

import { customAlphabet } from "nanoid";

const alphabet = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
const nanoid = customAlphabet(alphabet, 10);

const generateUniqueClassname = (styles) => {
  const uniqueId = nanoid(10);
  return uniqueId;
};

After we have generated a unique class name, we want to inject the styles in the browser. To do that:

const injectCSS = (className, styles) => {
  const styleSheet = document.styleSheets[0]; // get the browser's stylesheet
  styleSheet.insertRule(`.${className} {${styles}}`);
};

Now that we have all the utility required for styling our components, it is time for us to use them
We first check if any styles are passed, if no styles have been passed, we return without doing any of the above steps

const stylish = (Tag) => (styles) => {
  const NewComponent = ({ children, ...props }) => {
    if (!styles[0]) {
      return <Tag className={props.className || ""}>{children}</Tag>;
    }
    // ...

Otherwise

const preprocessedStyles = preprocessStyles(styles[0]);
const className = generateUniqueClassname(preprocessedStyles);
injectCSS(className, preprocessedStyles);

return (
  <Tag className={className} {...props}>
    {children}
  </Tag>
);

Your component should now look like this

import { compile, serialize, stringify } from "stylis";
import { customAlphabet } from "nanoid";

const alphabet =
  "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
const nanoid = customAlphabet(alphabet, 10);

const preprocessStyles = (styles) => serialize(compile(styles), stringify);

const generateUniqueClassname = () => {
  const uniqueId = nanoid(10);
  return uniqueId;
};

const injectCSS = (className, styles) => {
  const styleSheet = document.styleSheets[0]; // get the browser's stylesheet
  styleSheet.insertRule(`.${className} {${styles}}`);
};

const stylish = (Tag) => (styles) => {
  const NewComponent = ({ children, ...props }) => {
    if (!styles[0]) {
      return <Tag>{children}</Tag>;
    }

    const preprocessedStyles = preprocessStyles(styles[0]);
    const className = generateUniqueClassname(preprocessedStyles);
    injectCSS(className, preprocessedStyles);

    return (
      <Tag className={className} {...props}>
        {children}
      </Tag>
    );
  };
  return NewComponent;
};

export default stylish;

You should see that it now works as expected, and it correctly renders the HTML

import stylish from "./stylish";

const H1 = stylish("h1")`
  color: red;
`;

export default function App() {
  return (
    <div>
      <H1>Hello CodeSandbox</H1>
    </div>
  );
}

Exporting all HTML tags as components

The API does not yet match the styled-components API exactly. To use the same syntax, we must export all components as a function.

The styled-components DOM elements list is pretty handy for this — domElements.ts

You can copy the array and put it in its own file in your codebase. Then export a stylish function for each of the DOM nodes, like this:

domElements.forEach((domElement) => {
  stylish[domElement] = stylish(domElement);
});

The API should now be the same as the styled-components API and should work exactly the same way

const H1 = stylish.h1`
  color: red;
`;

End of Part 1

This is the end of Part 1 of this multipart series. Here's the tentative list of contents of the next articles in the series:

Part 2 — Working with component composition and making reusable styled components
Part 3 — Optimizing and deduplicating styles
Part 4 — Global styles and handling multiple themes
Part 5 — Publishing your library to NPM

You can find the complete code for this part at CodeSandbox — Part 1

You can follow me on DEV to get updated when I post my next article

The const keyword does not create immutable variables

Burhanuddin Udaipurwala — Wed, 28 Jul 2021 15:25:02 +0000

An introduction to the `const` keyword

The value of a variable created with the const keyword can't be changed. Although this statement is true in the case of primitive values, it is complicated when it comes to objects and arrays.

For objects and arrays, only the reference to the memory location that contains the data is stored in the variable. So the data underneath can be changed without changing the reference

Example:

const foodsILike = ['Shwarma']
foodsILike.push('Jalebi')
console.log(foodsILike) // => ["Shwarma", "Jalebi"]

In this example, we created an array with the const keyword and were still able to add items to it

What is immutability and why is it important?

Functional programming techniques and design patterns are very common in the Javascript world. We have tools like RxJS which bring reactivity to Javascript. Redux also depends on its state to be immutable. As a JS developer, you must take care that you do not mutate the state directly while updating it. In Redux, our reducers are never allowed to mutate the original / current state values!.

To prevent issues like these from occurring, you want to make your data immutable.

Using the `Object.freeze()` method

The Object.freeze() method freezes an object (duh!). What does this exactly mean? A frozen object cannot be edited. New properties cannot be added and existing properties cannot be removed or modified in any way.

'use strict'
const obj = {
  prop: 42,
}

Object.freeze(obj)

obj.prop = 33
// => TypeError: "prop" is read-only
// => will fail silently in non strict mode

There is however, a flaw to this approach

'use strict'
const obj = {
  prop: 42,
  propObject: {
    name: null,
  },
}

Object.freeze(obj)

obj['propObject']['name'] = 'Burhan'

console.log(obj)

/**
{
  prop: 42,
  propObject: {
    name: "Burhan"
  }
}
*/

This works perfectly fine since we are not modifying any properties of the frozen object directly.

You could use the deep-freeze package that recursively freezes all your objects

var deepFreeze = require('deep-freeze')

deepFreeze(Buffer)
Buffer.x = 5
console.log(Buffer.x === undefined)

Buffer.prototype.z = 3
console.log(Buffer.prototype.z === undefined)

/**
true
true
*/

This will help you prevent issues with mutations

Conclusion

The const keyword creates a read-only reference to a value. It does not mean that the value itself is immutable. It's just that the variable identifier cannot be reassigned

If you plan on using immutable objects with React or Redux, check out ImmerJS. It enables you to create new objects without writing extra code for deep clones. It also has some great utility hooks to use with React