DEV Community: Dmitry Ruban

Web-Essentials Reminder

Dmitry Ruban — Sun, 23 Apr 2023 22:21:37 +0000

This is a simple reminder to help refresh your knowledge or prepare for a Junior position interview.

JavaScript Engine

Data Types
- number: for any kind of numbers, integer or floating-point.
- string: for strings. A string may have one or more characters; there’s no separate single-character type.
- boolean: for true/false values.
- null: for unknown values – a standalone type with a single value null.
- undefined: for unassigned values – a standalone type with a single value undefined.
- object: for more complex data structures.
- symbol: for unique identifiers. Learn more
Boxing/Unboxing: Learn more
Variables: const, let, and var. Learn more about const, Learn more about var
Closures: MDN, JavaScript.info, Medium
Arrow functions vs regular functions: Vinta, MDN
Objects: Learn more
Prototypes: JavaScript.info (Inheritance), JavaScript.info (Function Prototype)
Property flags and descriptors: Learn more - value, writable, enumerable, configurable
Decorators: TypeScript Documentation
Generators (yield): Learn more
Promises: Learn more
Memory allocation: Learn more

TypeScript

Basic concepts

Node.js

Overview
Dependencies and npm
Event loop: Learn more
Streams: Medium, YouTube, freeCodeCamp
Google V8 and Libuv
Garbage collector: Learn more
Pros and cons of Node.js
Express and other frameworks

Browser

Web APIs, JavaScript runtime, browser event loop, and browser promises: ITNEXT (1), ITNEXT (2)
Web Workers
Document Object Model (DOM)
Virtual DOM: React.js Documentation, Habr (Russian)
Shadow DOM: Learn more

SQL

Database design
Indexes
N + 1 problem
Joins
ACID properties

NoSQL

Overview
Sharding
Comparing with SQL databases
CAP theorem: Wikipedia, Quora

REST API

Overview
API design
Examples
Bulk operations

Authentication and Authorization

Cookies
Session
LocalStorage
JWT
OAuth 2

HTTPS

Protocol
Methods & Status codes
Limitations

Testing

Behavior-Driven Development (BDD)
Test-Driven Development (TDD)

Object-Oriented Programming (OOP)

Fundamentals
Examples
SOLID principles
Design patterns

Build tools and preprocessors

Webpack
Sass
Less

Micro-frontends communication approaches

Dmitry Ruban — Wed, 22 Mar 2023 12:37:04 +0000

Micro-frontends

The engineering world tries to simplify and decompose big elements to separated pieces. Big classes can be decomposed to dedicated elements using different concepts such as SOLID and others. Applications can use libraries. Backend services can be sliced to modules or micro-services.

In Frontend sphere we hear more often about the concept to decompose big Single Page Application (SPA) to modules working as micro-services, they got the name “Micro-Frontends”. We have the one orchestrator managing and playing services - micro-apps by helping to launch and connect them together.

One of the most critical aspects of micro-frontends is the communication layer.

Communication challenges

Let's consider a scenario where a user wants to use an Instagram-like application with albums, photos, and related functionality.

The user opens the main domain URL, and the browser loads the orchestrator, which then initiates the process of loading the remaining dependencies.
The application can be divided into frames or based on business logic. The second approach is more efficient for creating a pluggable system. As the user opens the first micro-app with the home page, user can see own profile with an empty album. By clicking the "Upload Photo" button, the system asks the orchestrator to mount a new micro-app, such as an uploader popup with prerequisites or context.
Let’s keep in mind the first queue of questions: how to ask orchestrator to delivery these prerequisites such as popup position, user context?

Once the user uploads a photo through the popup, the system needs to unmount the popup, refresh the profile photos, and update the album counters on the screen.

Without a long-polling mechanism or websockets, the question remains: How can we deliver an event about a new photo from one isolated micro-app to another?

Although it's a simple scenario, choosing the right concept for exchanging events between micro-apps or designing their input/outputs is the challenge.
There is no silver bullet solution, but various architectures can help address these questions such as utility modules and the centralised event manager.

Utility modules

In the context of the photo uploader module, we can identify several APIs and events, such as opening the application, uploading a photo, and closing the application. By using existing MFE frameworks like single-spa, we can handle mounting and unmounting issues. The main challenge is to communicate between micro-apps to notify them of an event like a photo upload.

An observable mechanism can be beneficial in this scenario. We can create a simple class that encapsulates an observable, allowing us to emit events specified by an interface and subscribe to them.

export class UploaderManagerUtils {
  private static newPhotoSbj = new Subject<Photo>();

  public static get newPhoto$(): Observable<Photo> {
    return UploaderManagerUtils.newPhotoSbj.asObservable();
  }

  public static createPhoto(photo: Photo): void {
    UploaderManagerUtils.newPhotoSbj.next(photo);
  }
}

Another visual component can import this module from my lib and handle updates:

UploaderManagerUtils.newPhoto$.subscribe((photo) => {
  this.collection.add(photo);
});

And another component can trigger this event:

UploaderManagerUtils.createPhoto({ id: 1, blob: ... });

As a result, we can send uploading events with payloads without any event management systems, and all consumers can utilize them without limitations. For delivery purposes, UploaderManagerUtils should be wrapped in an independent npm package to request webpack to import a single class instance for all micro-applications. This approach is called "Utility modules".

Pros:

Framework-agnostic solution.
Supports any event implementation under the hood. The utility module should support two interfaces: one to emit and one to subscribe to payloads.
Easy to test by mocking modules.

Cons:

Each micro-app requires an additional library to manage events, leading to logistical issues like maintaining multiple libraries, updating them for all micro-apps, and handling delivery issues.
No specification. Theoretically, different and inefficient solutions could be used under the hood.

The centralised event manager

The micro-apps concept emphasises isolation, but at the same time, we can imagine our own specification or API for them. We can create a simple wrapper for our micro-apps, which takes all external context and uses our libraries and API to integrate internal events with the external world, and vice versa. This is achieved by passing one event manager instance that transfers events and optionally helps with state management.

While we lose some isolation because our micro-app relies completely on external parameters, we gain a robust communication layer. For example, if you want to communicate that a user uploads a photo, you don't need to create a new utility; you can just dispatch your command with the payload to the channel, and all external consumers can fetch your event. Additionally, your app can subscribe to external actions (e.g., Logout) to stop uploading properly.

The one from the most popular system helping to organise it - Redux. It seriously was recommended by any SPA framework, has the big community, materials, solutions. Official single-spa shares the tip to use it if we want to simplify our application.
So our app doesn’t need any additional libs and classes, I can take dispatch function for the global store or use store API manually:

Redux is one of the most popular systems that can help organise this centralised event manager. It is widely recommended by many SPA frameworks and has a large community, materials, and solutions. The official single-spa guide suggests using Redux if you want to simplify your application. So your app doesn't need any additional libraries and classes, and you can use the dispatch function for the global store or use the store API manually:

this.store.dispatch({ 
    action: UPLOADER__NEW_PHOTO,
    payload: {id: 1, blob: ... },
});

After that I can subscribe to this.store and filter actions or use reducers approach and work with my states.

Pros:

Popular solution having many articles from React world.
Can be easily integrate with any system.
Provides a robust, consistent environment for all micro-apps.
Avoiding many external dependencies.
Easy to test my mocking events or using existing test redux frameworks.

Cons:

Micro-app will have a bottleneck and strict relationships by using the one communication stream.

Summary

Micro-frontends have emerged as a popular approach to simplifying complex applications by breaking them down into smaller, more manageable modules. When implementing micro-frontends, the communication layer is the cornerstone for seamless interaction between micro-apps.

Consider the following solutions for efficient communication between micro-apps:

Utility modules offer a framework-agnostic solution that supports emitting and subscribing to payloads. However, they may require additional libraries for each micro-app, leading to logistical challenges. Utility modules are ideal when you're uncertain about the future development of your product and need flexibility to balance requirements and needs.
Centralised event managers, such as Redux, provide a consistent environment for all micro-apps and simplify communication. However, they may introduce a bottleneck and strict relationships between micro-apps. Centralised event managers are suitable when you want to focus on a single foundation and grow your product by adding new functionality, delivering modules, and providing continuous updates.

Ultimately, the choice between utility modules and centralsed event managers depends on the specific requirements and constraints of your project. Carefully evaluate your project's needs to determine the most appropriate solution for efficient communication between micro-apps in your micro-frontend architecture.

Yarn workspaces and change detection

Dmitry Ruban — Wed, 23 Feb 2022 18:17:56 +0000

Hello dev.to community!

Perviously I wrote a short article about “How to create your own modern yarn cli bundle” where I explained how we can build own CLI containing our plugins set. The one important plugin from my own CLI - enhanced workspace plugin which can help to provide more predictable and controllable change detection mechanism helping to optimise CI/CD and reduce additional operations on developer machines. But before…a short history and motivation to create another one bicycle in npm repo.

Motivation

The long time ago in the one Galaxy my R&D team where I’m participating decided to choose Node.js + TypeScript as the main platform for FE & BE Web products in order to have the one efficient and scalable environment. Good idea! But after creation the many product our ecosystem we faced to the problem: we have many repositories and is really time consuming thing to manage all PRs over them, link them between each other, organise version management, request our CI/CD sequently and etc.
The one obvious solution is to reduce repositories count and group them by the one monorepo. Fortunately we have many tools solving this problem: Bazel, Lerna, NX, Rush and Yarn. I my third article I have a plan to compare them by details and examples, but for now I just shortly say that after long discussions we decided to start from something quickest, easiest and extendable for us - yarn from the second version which provides flexible and good API for many cases.

We updated our Jenkins Pipeline to support Yarn V2 workspaces, designed a project transaction plan to monorepos and everything was good except performance. Yarn workspace plugin has (till 3.1.1 version) has two critical issues for us:

Wildcard operation has problem with appropriate topological ordering. In rare cases parent dependencies can be built only after children.
It doesn’t support the partial detection only for changed from some snapshot but it’s really important feature for any environment! (I know that is working from NX under the box)

In this time we still wanted to support Yarn and decided to start a creation of our Magic tool doing everything and specially:

Provide robust dependencies tree control for monorepo dependencies.
Help to determine what workspace was changes after previous commit or specific branch (master/main).
Build graphs helping to organise parallel CD/CD jobs.
Speedup development and CI/CD life by above points.

Great ambitious! And I can say that they were been achieved in this plugin: https://github.com/RuBAN-GT/yarn-plugin-enhanced-workspaces, hope it can help to other developers and make the Yarn more great and popular.

And for now more details how does it work.

Enhanced workspace plugin details

First of all sorry for the code, if you’ll find any moments that can be improved, feel free to open issues or your PRs.
And for now about organisation.

When I started to design core principles of my plugin I marked the several key moments:

Tree manager - the tool helping to build a workspace dependency tree with dependencies chunks & breadcrumbs that should forecasts appropriate ordering and allow the group nodes by groups in the future.
Change detection manager - the tool which can distinguish necessary/unnecessary nodes by following specific config parameters, diffs from commits or branches or other rules.
Group manager - the tool allows to combine tree nodes by groups with configurable limitations and ordering, it also ranks them in order to solve problems with the following dependency ordering (parent should be utilised before children).

Following these concepts the plugin exposes commands allowing to get nodes in different variants and provide operations over them like original yarn workspaces foreach but with own logic and configuration.

Instead of copy-pasting README I’ll show how to start to work with this plugin.

How to work

To get started everything whatever you need is to execute the command from your project:

yarn plugin import https://raw.githubusercontent.com/RuBAN-GT/yarn-plugin-enhanced-workspaces/master/bundles/%40yarnpkg/plugin-enhanced-workspaces.js

It should import plugin into your project.

After it, for example, we have a common frontend monorepo where we have publishable packages as libraries and a one application.

Is better to have a convention for your project in order to keep consistent infrastructure. For example you decided to provide build script from each project and package. We decided to use root package.json and ask our pipeline to try to execute build script:

yarn workspaces changed foreach -p --ancestors --ignored-ancestors-markers="dist" run build

This command tells:
“Please, look on changed workspaces from previous master/main commit, perform for them build command in parallel, if some of them require parent workspace, build it as well BUT if it already has dist directory on package folder - skip it.”

Simple but efficient. Moreover we can setup incremental builds using default TypeScript if we use set appropriate paths for example.

You can play with already configured environment at https://github.com/RuBAN-GT/monorepo-demo/tree/master/yarn. 
In our case, our pipeline after all builds and tests will try to publish public packages (workspaces) using yarn workspaces changed list --no-private by gathering all not private changed packages and using default yarn --cwd=workspace_path npm publish --tolerate-republish to publish them.

Summary

I hope this solution can help to organise your development and CI/CD environment and speed up your processes. It doesn’t solve issues with watchers or caching but from the other hand is better that nothing) Moreover it may be can help somehow to the yarn community.

If you have any questions, ideas, suggestions, feel free to ask!

Good code everyone!

How to create your own modern yarn cli bundle

Dmitry Ruban — Sun, 20 Feb 2022 18:40:12 +0000

Hello dev.to community!
This is my first post so I'm happy to start to share my experience (hope this will be useful for somebody) with monorepos and yarn tool here.

In my current job I work with the big infrastructure of Node.js multiple repos such as single codebase or monorepos in different customer domains (Angular projects, pure JS, Node.js backends, etc) therefore is so critical to provide better developer and CI/CD experience when we need to work with hundreds projects by the one strategy.

As a package manager we chose yarn berry (I believe I’ll prepare another one post where I’ll compare monorepo tools) because:

Pluggable system where we can extend existing functionality using JS.
Efficient strategies to work with dependencies.
New features from plugins such as modern workspaces like Lerna.
Is easily to start to use yarn from any project without specific code base changes.
We had experience with this tool.
The way to control consistent client for all environments (CI, developers) with the one client version.

And in this post I want to focus about latest point and how I enhanced it.

The problem

As I said above Yarn allows to add many really useful plugins to any project, all its binaries and extensions are stored at repository, it provides benefit that each developer or CI/CD environment uses the one consistent environment but from the other had we can face to the problems:

Yarn doesn’t provide any plugin version manager, I can’t verify that I have latest plugin version and therefore is more difficult that my plugin in specific project has needed version.
If we have hundreds projects developer have to copy the one plugins set from one to one projects and is more pain to update them one by one.

And when I read yarn API documentation I found very interesting part of it: yarn builder build bundle which helps to build own yarn cli clients having my own custom set of all required plugins with specific versions with my own version mark - this is solution!
When I use it I can organise my own plugins manifest in package.json and commit their versions using simple dependencies versions where plugins work as simple npm packages.

But this API has the one restriction - is internal building API. I didn’t find an appropriate way to use this builder in my clean project without additional artefacts but this is not a big problem and for now I can share a simple solution of it.

How to create CLI environment

First of all you should initialise your project using yarn cli:

yarn init

After you should to set yarn berry in order to work with appropriate API:

yarn set version berry

In the next step you should think about what you want to archive into your CLI: what plugins, versions, etc. You can take as example official yarn berry cli: https://github.com/yarnpkg/berry/blob/master/packages/yarnpkg-cli/package.json
This package.json has several important sections:

@yarnpkg/builder key where you can define profile with buildable plugins (it can be any local or custom plugins), if you don’t need to variate different plugins sets just define “standard” profile from example.
In your dependencies (or dev) section set related from plugins list packages. It requires by builder to put sources into your cli.
Add dev dependencies relying to your yarn version:
- @yarnpkg/builder
- @yarnpkg/cli
version - this is your own version printed by “yarn --version”.

Additionally you can add build script for your CI/CD or just for simplifying:

builder build bundle

Looks easy? Ok, let’s try to execute:

yarn builder build bundle

But for now this is the problem of internal APIs:

➤ YN0000: ┌ Building the CLI
➤ YN0001: │ Error: Build failed with 1 error:
error: Could not resolve “/sources/cli.ts"

Yarn bundle builder is oriented to original berry repository and some internal scripts. I didn’t find any ways to solve this problems without fetching these files, therefore you should copy https://github.com/yarnpkg/berry/tree/master/packages/yarnpkg-cli/sources directory to your project/sources directory.

If you’ll retry build command you should see a new one bundles/yarn.js file - this is your bundle.

As another one example, you can look on my bundle: https://github.com/RuBAN-GT/yarn-ultimate-cli having my own plugin helping to work with workspaces and determine their changes.

How to use your CLI

From 2-3.1.1 yarn versions yarn doesn’t support fetching external yarn clients from CDN but my simple enhancement was merged recently (https://github.com/yarnpkg/berry/pull/4089) and we’ll can simply set our versions using

yarn set version https://your_address/yarn.js

But while yarn team didn’t published a new one minor release we can take the next workaround using availability to fetch yarn clients from file system:

Fetch yarn js bundle using curl like:

 curl -L 'https://raw.githubusercontent.com/RuBAN-GT/yarn-ultimate-cli/master/bundles/yarn.js' > '/tmp/yarn.js'

Set local fs version:

yarn set version berry && yarn set version /tmp/yarn.js

If you’ll execute yarn --version you should to see your own version name.
My congratulations!

Summary

I hope my post can help to know more about awesome Node.js package manager - Yarn and its API and ways to enhance your infrastructure. If you’ll face to issues with configurations of your bundles, feel free to ask from comments.

Good code everyone!