DEV Community: Valor-software-tech

Medusa Resources Overlimit in Realtime Notification

Valor-software-tech — Fri, 06 Jan 2023 18:03:24 +0000

Medusa Dashboard

Issue

**
A user has a "Free Subscription" price plan with some limited resource usage. Currently, it looks like this

Let’s play with builds now.

How does it work?

When a user builds his application on his own (an application is connected to Medusa via tokens and medusa-plugin), medusa-plugin makes an API call to Medusa Server with a request to update application builds inside Medusa Dashboard, it creates some records in the database and you can manage and use those builds in the Dashboard then.
At the current moment, we don’t have any restrictions for build amount and usage according to the Price Plan so users can easily get a quote over the limit like for usage of 130 builds with 100 builds in the Plan.

The task sounds like "Restrict overlimit usage of Medusa Resources according to Quota". Sounds like a five-minute task, just insert a checker before business logic. If the check is positive – go further, if negative – stop action.
Okay, it’s done. Even works. But there’s another issue – it will look for a User like a bug. No… like a BUG. As all things, described above, are under-the-hood processes, the user cannot know at that moment that he got overlimit, so we have to notify the user somehow in some way.

We don’t have any real-time solutions implemented inside yet, so it seems that, easy from first sight, the task becomes a task of implementing real-time technology. Okay, what do we know about it? Web Sockets – cool, but they are unidirectional, we do not need them. In addition, we might have an issue if the load balancer doesn’t support WebSockets (like a basic AWS Load Balancer).

What else?

SSE – Server-Sent-Events. Technology, which might cover a lot of cases where people use WebSockets. In addition, it brings less headache with integration as it uses HTTP protocol only.
Some words of difference between WebSockets and SSE.

Okay, we said it, we did it!
On the Back End side, we use NestJS, Front End is NextJS (for a non-native speaker, it’s quite difficult and funny to try to pronounce them instantly one by one :) ).

Let’s start. NestJS documentation has some words about the implementation of SSE. So it looks easy to do, it has simple examples, and it works… But in our case, not always and not everywhere.

There are a few issues I have faced during implementation.

Issue 1

An example in NestJS documentation is related to interval usage and sends messages once a second. We do not need that way, we need to send messages at the moment we want, and only to users whom this message concerns.
So we had to alter the event emitter to send messages only at that moment we need.
It was done.

@Injectable()
export class ServerEventsService {
private readonly emitter: EventEmitter;

constructor() {
this.emitter = new EventEmitter();
}

subscribe(userId: string): Observable {
return fromEvent(this.emitter, userId);
}

emit(userId: string, data?: SseEventMessage): void {
this.emitter.emit(userId, { data });
}
}

Issue 2

As we are using NextJS, it means that most pages are SSR (Server Side Rendered). That means, in addition, that we cannot create the EventSource instance anywhere we want. So we have to initialize the eventsource after the component has been rendered in the browser.

Firstly, we need to receive messages and show them globally, it should not be related to a certain page. Another thing is how to make it work in our case of SSR.

We just need to do that in useEffect, to make it start working in a Browser already. So we created a Global Modal with some inputs, integrated our solution and it worked. Cool, we are so happy!

Issue 3

Our solution worked well in the case of real-time processes, but what if Medusa Dashboard was closed? We need to notify a user that he has some issues with using Medusa because of quota overlimit. Easy, just make a check. The thing is that we need to make an async call in useEffect and linter tells us that we are incorrect with that decision… But, there’s a workaround. We need to wrap the async function into the self-invoking unnamed function.

(async () => {
await task();
})();

Issue 4
It’s a bad thing to have a checker on the Back End side for the under-the-hood process and the same checker on the Front End side, so on a Front End we just make an API call without using a response. On the server side, we check all related data, and in case the checker responds negatively, we emit a new message from Server to UI.
But it didn’t work.

Under-the-hood things emitted the message from one controller, check by demand the emitted message from another controller.

What is the issue? Why doesn't it work? I’m emitting a message, and it emits but the UI doesn't get it…

I checked if my emitters have listeners. One of them had one, and another one – did not.
Whaaat?

I have created an SSE Service and injected that as a provider into the App Module, then into another Module. It’s not directly said anywhere in the documentation that by doing things in this way, we will get different multiple instances of Services. Hmmm… Okay.
Creating a separate module with a separate service, then injecting modules into other modules – saved me… The Next JS modules are Singletons, so now I have only one instance of the SSE part and really can use this service everywhere in the Server and emit messages to a certain channel.

That’s it. We have integrated SSE into the System, it works great and this is a base to develop that further.

Now we can notify a user if something is happening under the hood and the user should be aware of it. Great!

WATCH ME

Video Plan:

1. Who we are and what we are doing? What do we need now? What is the issue? What are we going to do and how are we going to resolve this?****

We are Valor Software, an international company, created by the Developer for Developers.
We are fans and sponsors of NestJS and NativeScript and do a lot of awesome things by ourselves, like ngx-bootstrap, and a current one called Medusa.
Medusa is a kind of Dashboard and management system for Module Federation. With Medusa, you can finally have visibility into your Module Federation-powered applications. See what versions are deployed, their underlying dependencies and relationships, and which teams are committing to them. That’s in general about Medusa evolving all the time, development moving further and further.

Today we have to resolve the following thing:

When a user is building his connected application on his own, medusa-plugin makes an API call to Medusa Dashboard with the request to update application builds inside Medusa Dashboard, it does some logic and creates a few records in the database so then you can manage and use those builds in the Dashboard then.
At the current moment, we don’t have any restrictions for builds' amount and usage according to the Price Plan so users can easily get a quote over the limit, like for using 130 builds with 100 builds limit in the Plan.

The task sounds like "Restrict overlimit usage of Medusa Resources according to Quota". Sounds like a five-minute task, just insert a checker before business logic. If the check is positive – go further, if negative – stop action.
2. Add a checker
3. Add Stripe data to the checker to check the user payment method
4. Add a checker for quotas
5. Make it reusable
Okay, it’s done. Even works. But there’s another issue – it will look for the User like a bug. No… like a BUG. As all things, described above, are under-the-hood processes, the user cannot know at that moment that he got overlimit, so we have to notify the user somehow in some way.

6. Add SSE Service, tell that it should be a Singleton as it’s important and nobody tells that.
We don’t have any real-time solutions implemented inside yet, so it seems that, easy from first sight, the task becomes a task of implementing real-time technology. Okay, what do we know about it? Web Sockets – cool, but they are unidirectional, we do not need them. In addition, we might have an issue if the load balancer doesn’t support WebSockets (like a basic AWS Load Balancer).
What else?

On the Back End side, we use NestJS, Front End is NextJS (for a non-native speaker, it’s quite difficult and funny to try to pronounce them instantly one by one :) ).

Let’s start. NestJS documentation has some words about the implementation of SSE. So it looks easy to do, and it has simple examples.

7. Say that the EventSource listener should be fully FE and as we use NextJS – should be in useEffect.
8. Check that it works, and set the channel based on UserId.
9. Check that it works for app builds and on login, remove redundant code.

Module Federation in mobile apps powered by NativeScript

Valor-software-tech — Fri, 06 Jan 2023 16:56:49 +0000

Module federation has been one of the most popular topics in development lately. People love the way it allows teams to develop applications independently and integrate them all into a single final application. While that seems good for the web, how could Module Federation look in a mobile native application?

Let’s get the elephant out of the room first. The whole point of module federation is that teams can deploy their applications independently, but native apps have their bundles and code shipped holistically with the app. Even if they didn’t, having the user wait or be unable to load your app in bad or no connectivity would lead to terrible UX. Before going down this path, you need careful thought and a really good reason.

So let’s start with a use case. One of our large enterprise clients has a WYSIWYG editor for NativeScript, complete with their own native components library. They have their own SSO and app “shell” that is common to all of their apps, but their users are able to customize the content, including pushing changes only to specific screens. To generate this they needed to be able to generate bundles dynamically and push them to the application so they could easily switch between apps, and update only the user’s bundle.

This application highlights one of the beauties of NativeScript. The users don’t need to have knowledge of native code at all, and if they need to extend something, they can do it directly in JavaScript or TypeScript, while also allowing them to add native code once they feel like they need it.

Now back to the application. This was initially built before bundlers were widely used, and once bundlers became the norm, it became a tricky situation where they’d need to map the available modules and override the require functions to provide the user code with the expected module. A mess. Enter Webpack Module Federation.

Exposing an application
For this example, I’ve decided to use Angular as it’s one of the frameworks officially supported by NativeScript. So first we create our app

import { Component, NgModule, NO_ERRORS_SCHEMA } from "@angular/core";
import { RouterModule } from "@angular/router";
import { NativeScriptCommonModule } from "@nativescript/angular";
import { timer } from "rxjs";

@Component({
  template: `<Label>Hello from wmf! Here's a counter: {{ timer | async }}</Label>`,
})
export class MyComponent {
  timer = timer(0, 1000);
}

@NgModule({
  declarations: [MyComponent],
  imports: [NativeScriptCommonModule, RouterModule.forChild([{ path: "", component: MyComponent }])],
  schemas: [NO_ERRORS_SCHEMA]
})
export class FederatedModule {}

Since we’ll need to download all the JS files anyway, for testing purposes I’ve made it all compile to a single chunk and discard the non-remote entrypoint. To do this I used the default NativeScript webpack config and augmented with a few details to build it directly to my current app’s assets directory.

const webpack = require("@nativescript/webpack");
const coreWebpack = require('webpack');
const path = require(`path`);
const NoEmitPlugin = require('no-emit-webpack-plugin');

module.exports = (env) => {
  webpack.init(env);

  const packageJson = require('./package.json');

  // Learn how to customize:
  // <https://docs.nativescript.org/webpack>

  webpack.chainWebpack((config, env) => {
    config.entryPoints.clear();
    config.resolve.alias.set('~', path.join(__dirname, 'federated-src'));
    config.resolve.alias.set('@', path.join(__dirname, 'federated-src'));
    config.plugins.delete('CopyWebpackPlugin');
    config.output.path(path.join(__dirname, 'src', 'assets'));
    config.optimization.runtimeChunk(true);
    config.module.delete('bundle');
    config.plugin('NoEmitPlugin').use(NoEmitPlugin, ['dummy.js']);
    config.plugin('MaxChunks').use(coreWebpack.optimize.LimitChunkCountPlugin, [{ maxChunks: 1 }]);
    config.plugin('WebpackModuleFederationPlugin').use(coreWebpack.container.ModuleFederationPlugin, [{
      name: 'federated',
      exposes: {
        './federated.module': './federated-src/federated.module.ts'
      },
      library: {
        type: 'commonjs'
      },
      shared: {
        '@nativescript/core': { eager: true, singleton: true, requiredVersion: "*", import: false },
        '@nativescript/angular': { eager: true, singleton: true, requiredVersion: "*", import: false },
        '@angular/core': { eager: true, singleton: true, requiredVersion: "*", import: false },
        '@angular/router': { eager: true, singleton: true, requiredVersion: "*", import: false },      }
    }]);
  });

  const config = webpack.resolveConfig();
  config.entry = { 'dummy': './federated-src/federated.module.ts' };
  return config;
};

Loading the remote entrypoint
One of the tricky parts of this whole process is that we can’t download the app piece by piece, as underneath we’re using commonjs (node’s require) to evaluate and load the modules into memory. To do this we need to download all of the output into the application and then we can load it.
As a POC, we can start with a simple remote configuration which allows us to load the entrypoint as a normal module.

// federated webpack config
{
  name: 'federated',
  exposes: {
    './federated.module': './federated-src/federated.module.ts'
  },
  library: {
    type: 'commonjs'
  },
}

// host config

{
  remoteType: "commonjs",
  remotes: {
    "federated": "~/assets/federated.js"
  }
}

And the import it as a route like:

{
  path: 'federated', loadChildren: () =>  import('federated/federated.module').then((m) => m.FederatedModule),
}

Unfortunately, we’d have to have all the federated modules shipped in the final application, so to load things dynamically, we should instead use the following code to load arbitrary entrypoints:

/// <reference path="../../node_modules/webpack/module.d.ts" />

type Factory = () => any;
type ShareScope = typeof __webpack_share_scopes__[string];

interface Container {
  init(shareScope: ShareScope): void;

  get(module: string): Factory;
}

export enum FileType {
  Component = "Component",
  Module = "Module",
  Css = "CSS",
  Html = "Html",
}

export interface LoadRemoteFileOptions {
  // actual file being imported
  remoteEntry: string;
  // used as a "key" to store the file in the cache
  remoteName: string;
  // what file to import
  // must match the "exposes" property of the federated bundle
  // Example:
  // exposes: {'.': './file.ts', './otherFile': './some/path/otherFile.ts'}
  // calling this function with '.' will import './file.ts'
  // calling this function with './otherFile' will import './some/path/otherFile.ts'
  exposedFile: string;
  // mostly unused for the moment, just use Module
  // can be used in the future to change how to load specific files
  exposeFileType: FileType;
}

export class MfeUtil {
  // holds list of loaded script
  private fileMap: Record<string, boolean> = {};
  private moduleMap: Record<string, Container> = {};

  findExposedModule = async <T>(
    uniqueName: string,
    exposedFile: string
  ): Promise<T | undefined> => {
    let Module: T | undefined;
    // Initializes the shared scope. Fills it with known provided modules from this build and all remotes
    await __webpack_init_sharing__("default");
    const container = this.moduleMap[uniqueName];
    // Initialize the container, it may provide shared modules
    await container.init(__webpack_share_scopes__.default);
    const factory = await container.get(exposedFile);
    Module = factory();
    return Module;
  };

  public loadRootFromFile(filePath: string) {
    return this.loadRemoteFile({
      exposedFile: ".",
      exposeFileType: FileType.Module,
      remoteEntry: filePath,
      remoteName: filePath,
    });
  }

  public loadRemoteFile = async (
    loadRemoteModuleOptions: LoadRemoteFileOptions
  ): Promise<any> => {
    await this.loadRemoteEntry(
      loadRemoteModuleOptions.remoteEntry,
      loadRemoteModuleOptions.remoteName
    );
    return await this.findExposedModule<any>(
      loadRemoteModuleOptions.remoteName,
      loadRemoteModuleOptions.exposedFile
    );
  };

  private loadRemoteEntry = async (
    remoteEntry: string,
    uniqueName?: string
  ): Promise<void> => {
    return new Promise<void>((resolve, reject) => {
      if (this.fileMap[remoteEntry]) {
        resolve();
        return;
      }

      this.fileMap[remoteEntry] = true;

      const required = __non_webpack_require__(remoteEntry);
      this.moduleMap[uniqueName] = required as Container;
      resolve();
      return;
    });
  };
}

export const moduleFederationImporter = new MfeUtil();

export const moduleFederationImporter = new MfeUtil();
This code is able to load any .js file on the device, so it can be used in conjunction with a download strategy to download the files and then load them dynamically. For example, we can first download the full file, and then load it:

{
 path: "federated",
 loadChildren: async () => {
   const file = await Http.getFile('http://127.0.0.1:3000/federated.js');

   return (await moduleFederationImporter
     .loadRemoteFile({
       exposedFile: "./federated.module",
       exposeFileType: FileType.Module,
       remoteEntry: file.path,
       remoteName: "federated",
     })).FederatedModule;
 },
},

Alternatively, we could also download it as a zip and extract, or you could, theoretically, override the way that webpack loads the chunks in the federated module to download them piece by piece as needed.

Sharing the common modules
The complexity of sharing modules cannot be understated. The initial Webpack Module Federation PR (https://github.com/webpack/webpack/pull/10838) that provided the full container and consumer API is smaller then the PR that introduced version shared dependencies (https://github.com/webpack/webpack/pull/10960).
A native app is not just a webpage, but the full browser itself. While the web provides a lot of APIs directly, NativeScript provides a lot of them through the @nativescript/core package so that’s one dependency that has to be a singleton and we can’t under any circumstance have multiple versions of it. In this example we’re also using angular, so let’s share that as well:

shared: {
  '@nativescript/core': { eager: true, singleton: true, requiredVersion: "*" },
  '@nativescript/angular': { eager: true, singleton: true, requiredVersion: "*" },
  '@angular/core': { eager: true, singleton: true, requiredVersion: "*" },
  '@angular/router': { eager: true, singleton: true, requiredVersion: "*" },
}

Here we also share them as eager, since those packages are critical to the bootstrap of the application. For example, @nativescript/core is responsible for calling UIApplicationMain on iOS, so if you fail to call it, the app will instantly close.

Result
First, we create a simple standalone component that will show a Label and a nested page which will be loaded asynchronous:

import { Component, NO_ERRORS_SCHEMA } from "@angular/core";
import {
 NativeScriptCommonModule,
 NativeScriptRouterModule,
} from "@nativescript/angular";

@Component({
 standalone: true,
 template: `<StackLayout>
   <Label>Hello from standalone component</Label>
   <GridLayout><page-router-outlet></page-router-outlet></GridLayout>
 </StackLayout>`,
 schemas: [NO_ERRORS_SCHEMA],
 imports: [NativeScriptCommonModule, NativeScriptRouterModule],
})
export class ShellComponent {}

Then we can define the Federated Module:

@Component({
 template: `<Label>Hello from wmf! Here's a counter: {{ timer | async }}</Label>`,
})
export class MyComponent {
 timer = timer(0, 1000);
}

@NgModule({
 declarations: [MyComponent],
 imports: [NativeScriptCommonModule, RouterModule.forChild([{ path: "", component: MyComponent }])],
 schemas: [NO_ERRORS_SCHEMA]
})
export class FederatedModule {}

And finally, we can setup the routing:

import { NgModule } from "@angular/core";
import { Routes } from "@angular/router";
import { NativeScriptRouterModule } from "@nativescript/angular";
import { FileType, moduleFederationImporter } from "./mfe.utils";
import { Http } from "@nativescript/core";
import { ShellComponent } from "./shell.component";

const routes: Routes = [
 { path: "", redirectTo: "/shell", pathMatch: "full" },
 {
   path: "shell",
   component: ShellComponent,
   loadChildren: async () => {
     const file = await Http.getFile("http://127.0.0.1:3000/federated.js");

     return (
       await moduleFederationImporter.loadRemoteFile({
         exposedFile: "./federated.module",
         exposeFileType: FileType.Module,
         remoteEntry: file.path,
         remoteName: "federated",
       })
     ).FederatedModule;
   },
 },
];

@NgModule({
 imports: [NativeScriptRouterModule.forRoot(routes), ShellComponent],
 exports: [NativeScriptRouterModule],
})
export class AppRoutingModule {}

Which results in the following screen, fully working module federation in NativeScript!

Conclusion
Although Module Federations is still limited on the native application side, we’re already exploring possibilities on how to import modules from the web directly, instead of having to download them manually, giving it first class support and allowing full code splitted remote modules:

const entry = await import('https://example.com/remoteEntry.js');
entry.get(...)
// entry magically fetches https://example.com/chunk.0.js if needed

Module Federation is very promising for creating distribution of efforts and on demand releases without having to go through the pain of constant app store approval processes. While not for everyone it is a very exciting opportunity for large teams.

Need help?
Valor Software is both an official partner of both the NativeScript organization and Module Federation organization. If you're looking at using Module Federation with your NativeScript application and would like some help. Reach out to our team, sales@valor-software.com

Nx, Next.js, and Module Federation

Valor-software-tech — Wed, 20 Jul 2022 20:50:00 +0000

Table of Contents:

About the author
Micro Frontends, Nx, and monorepos
Next.js, Nx + Next.js
Module Federation, Next.js + Module Federation
Starting the project
Generating new pages and new applications
Running in the development environment
Generating new components
Installing nextjs-mf
Creating hooks
Deploying projects on Vercel + private dependencies with Vercel
References

The author

Bruno Silva, the Next.js developer of Valor Software with the team's support, has created the solution described below and this material which was originally published on the Valor's blog.

The article is also available in Portuguese: https://valor-software.com/articles/nx-next-js-e-module-federation. Enjoy the reading and the dev experience :)

Micro Frontends

You’ve probably heard about microservices and the number of benefits they bring to both the scalability of a backend application and the team that develops it. Now imagine if these same advantages could be brought to the frontend. Well, that’s what we’re going to talk about today.
First, let’s talk about what a micro frontend is and what are its benefits. Micro frontends are a way to organize both an application and the team that develops it. Think about the following: a web application is usually composed of several resources, and depending on the size of the application it depends on certain synchrony between the teams that develop it so that new versions are released for production. Let’s take an example: Imagine that we have an online course sales website and that website has the following features:

Institutional page (landing page/marketing)
Catalog / advanced search
Checkout
Courses player page
Upload page
Forum (for students to interact with tutors)
Account Settings pages (for students and tutors)

Imagine that each of these features can be easily split into microservices when it comes to the backend, but most of the time the frontend ends up being a kind of “monolith” containing a single stack and forcing the entire team to stay in sync at all times. that a new feature goes into production. Can you see this? Clearly, we could split each part of this eCommerce into distinct applications for smaller teams with unique responsibilities and possibly different stacks. Think about it, the team responsible for the checkout could work 100% focused on improving the user’s shopping experience flow, reducing noise that made them give up on the purchase, or for example the catalog and institutional team (landing page) that could work on different marketing fronts, as well as the team responsible for the video area of the platform, which would be focused on ensuring speed / high quality in the delivery of classes to students.

Anyway, there are many examples that we could cite about the use of micro frontends, but as the purpose of this article is to be a little more practical, let’s skip this part and if you are more interested in understanding the advantages of using micro frontends, I suggest you read more about it in this article.

Nx and monorepos

Well, as we saw earlier it is possible to divide some web applications into microfrontends which, initially, may bring you some questions such as: “But then I need to divide all applications into separate repositories? Imagine the headache it will be to test all this!” and that’s where we’ll talk about mono repositories. Mono repository or Monorepo is a single git repository that seeks to manage all the source code of an application, this brings us a series of advantages and some disadvantages, here are some of them:

Pros

Standardization (lint) of the code for the entire team
Test management in one place
Centralization of dependency management
Code reuse between applications due to dependency centralization
Transparency as we can see all code from a single workspace

Cons

.git folder can end up getting big due to a high number of contributions, because the whole team is contributing commits in the same project
Increase of build time of some applications depending on the dependency level and size of shared files/data
No permission granularity, since the entire team needs to have access to the monorepo, the power to restrict the access of certain users to certain parts of the application is lost Looking at the benefits and the context, I saw that it would be an excellent opportunity to use Nx as a manager for our project. Nx is a monorepo manager with a huge range of plugins to facilitate the creation of new applications, libraries, tests, build execution, lint standardization, centralization, dependency management, and many other features.

Next.js

It is indisputable that currently Next.js is one of the web frameworks that has been gaining more and more adoption in recent times and all this is due to the range of features such as server-side rendering, static optimization, file-system routing, API routes and data-fetching strategies he proposes. Next.js is an awesome tool, but we’ll assume you already know it and skip to the next part.

Nx + Next.js

According to the Nx team, their development philosophy is very similar to Visual Studio Code’s, in which they focus on maintaining a powerful and generic tool, while extensions, or plugins, are fundamental for increasing your productivity with it. As such, @nrwl/next is the plugin that we will use to create and manage our applications with Next.js within our Nx workspace.

Module Federation

Module Federation is a Webpack 5 feature that has arrived to make it possible to share parts of an application to another at runtime. This makes it possible for multiple applications compiled with webpack to repurpose parts of their code as the user interacts with them, which takes us to the next step.

Next.js + Module Federation

Let’s start with our first example of this article where we talk about an eCommerce application, now imagine that our marketing team decides to create a mega Black Friday campaign and decides to change several parts of our application by inserting different components with dynamic banners, carousels, countdowns, themed offers, etc… this would probably be a headache for all teams responsible for our microfrontend applications since each one would have to implement the new requirements of the marketing team in their projects and that would have to be very well tested and synchronized so that everything went right and nothing could be released ahead of time… Anyway, all this could easily generate a lot of work and a lot of headache for the team, but that’s where the very powerful Module Federation comes in.

Thanks to it, only one team would be in responsible for developing the new components along with their respective logic, and the rest of the team would only be responsible for implementing the use of these new complements, which could bring with them, hooks, components in React, among others.

Unfortunately, implementing and using the Module Federation features of Webpack with Next.js is not that easy, as you would need to deeply understand how both tools work to be able to create a solution that facilitates the integration between the two. Fortunately, there is already a solution and has several features including support for SSR (server-side rendering), these tools are called nextjs-mf and nextjs-ssr and together we are going to explore a proof-of-concept application that I created to show you the power of these tools together.

⚠️ Attention: for the application to work with Module Federation features you need to have access to the nextjs-mf or nextjs-ssr plugin which currently requires a paid license!

About the project

This project will show, how to create the basis for a fully scalable application both in production and in development. In it, we will see some small examples of how the tools mentioned above can be used.

Starting the project

Initially, we will need to install Nx in our environment to handle the commands needed to manage our monorepo. To do this, open a terminal and run:

npm i -g nx
Once this is done, navigate to a directory where you want to create the project and run the command below, this command will use @nrwl/next to create our workspace (monorepo) and our first application:

npx create-nx-workspace@latest --preset=next
An interactive terminal will guide you through the creation process, you can follow as I did below:

Once this is done, you must wait for the workspace (monorepo) to be created and the project’s dependencies to be downloaded after that you can open vscode in the workspace root, in my case:

code ./nextjs-nx-module-federation
Looking at the file explorer you can see that the project has a structure similar to this:

├── apps
│   ├── store (...)
│   └── store-e2e (...)
├── babel.config.json
├── jest.config.ts
├── jest.preset.js
├── libs
├── nx.json
├── package.json
├── package-lock.json
├── README.md
├── tools
│   ├── generators (...)
│   └── tsconfig.tools.json
├── tsconfig.base.json
└── workspace.json

ℹ️ Note that our application in Next.js is inside the "apps" folder, this folder will contain all the other applications you are going to create, we can also see other configuration files of our workspace. It is important to note that there is only one "node_modules" folder in the entire project, this happens because all dependencies will be in one place, at the root of the repository.

Generating new pages

The @nrwl/next plugin has several generators, and commands that serve to automate the creation of pages, components, and other common structures in the project.

Knowing this we will create our first page using a generator called "page" for this run the following command in the terminal

nx g @nrwl/next:page home --project=store
ℹ️ Note that we use the --project flag to indicate to the generator in which project the new page should be created.

This will generate a page called "home" which will be located at

apps/store/pages/home/index.tsx

Generating new applications

Now we will need to create another application, which we will call "checkout". Unlike the first application we created together with the workspace, we will need to use the following command to create a new Next.js application in the current workspace:

nx g @nrwl/next:app checkout

Your "apps" folder should look like this:

├── apps
│   ├── checkout (...)
│   ├── checkout-e2e (...)
│   ├── store (...)
│   └── store-e2e (...)
...

Running in the development environment

To see our changes running, we will need to run the following command in the terminal:

nx serve store
ℹ️ serve is an executor command

Also, we can run all applications at the same time using:

nx run-many --target=serve --all
ℹ️ Note that we use the --target flag to indicate to nx which executor we want to run on all projects.

Generating new components

As we saw earlier, we have the possibility to create structures in our application using the Nx CLI tool, now we are going to create a simple button component in the "checkout" project, that execute the following command:

nx g @nrwl/next:component buy-button --project=checkout
Now let’s edit the component in the directory below so that it looks like this

apps/checkout/components/buy-button/buy-button.tsx

We’ll use this simple app "checkout" component in the app "store" to exemplify code sharing with Module Federation and that takes us to the next step.

Installing nextjs-mf

⚠️ Attention: for the application to work with Module Federation features you need to have access to the https://app.privjs.com/package?pkg=@module-federation/nextjs-mf[[nextjs-ssr^] plugin which currently requires a paid license!

To install the tool, we need to login to [PrivJs}(https://privjs.com/^) using npm, to do so, run the following command:

npm login --registry <https://r.privjs.com>

Once this is done a file containing your credentials will be saved in ~/.npmrc. Now you can install nextjs-mf using the command below:
npm install @module-federation/nextjs-mf --registry https://r.privjs.com

Now we will need to modify our "next.config.js" file in both projects so that the installed plugin can work, for that open the following files:

apps/store/next.config.js
apps/checkout/next.config.js You will see that in them we have an Nx plugin being used, we will need to maintain it, for that, make the files of each project similar to these:
store/next.config.js
checkout/next.config.js You will notice that we have two environment variables being used in this file, we will need to define them in each project so create a ".env.development.local" file in each project and leave each file with the following values:

NEXT_PUBLIC_CHECKOUT_URL=http://localhost:4200
NEXT_PUBLIC_STORE_URL=http://localhost:4300

So far no new changes can be noticed, but we can already use the Module Federation resources, but before that, we will make some modifications in our development environment so that applications can communicate without generating warnings in the console by local port collision, to this open and edit the following files:

"apps/store/project.json"

{
  // ...
  "targets": {
    // ...
    "serve": {
      // ...
      "options": {
        "buildTarget": "checkout:build",
        "dev": true,
        "port": 4300
      },
      // ...
    },
    // ...
}

"apps/checkout/project.json"

{
  // ...
  "targets": {
    // ...
    "serve": {
      // ...
      "options": {
        "buildTarget": "checkout:build",
        "dev": true,
        "port": 4200
      },
      // ...
    },
    // ...
}

In order for the component to be federated, we must add it to the "next.config.js" file, open the file and add a new entry in the "exposes" object:

module.exports = withFederatedSidecar({
  // ...
  exposes: {
    './buy-button': './components/buy-button/buy-button.tsx',
  },
  // ...
})(nxNextConfig);

Now with everything configured, we must restart any next process that is running and we are going to import the button component that we created in the "checkout" project in the "store" project using the Module Federation resources, for that open the "home" page that we created in the "store" project and import the Next.js dynamic function as shown below:

import dynamic from 'next/dynamic';
This function will help us to import the component only on the client-side, so add the following code snippet on the page:

const BuyButton = dynamic(
  async () => import('checkout/buy-button'),
  {
    ssr: false,
  }
);

And then we can use the component in the page content

export function Page() {
  return (
    <div className={styles['container']}>
      <h1>Welcome to Store!</h1>
      <BuyButton onClick={() => alert('Hello, Module Federation!')}>Add to Cart</BuyButton>
    </div>
  );
}

Now you can see the following result

Creating hooks

One of the powers of nextjs-mf is the federation of functions, including hooks. An important detail is that we cannot import hooks asynchronously, which leads us to adopt a solution where we import functions using "require" and the page or component that uses the hook being loaded lazily/asynchronously, what we call "top-level-await".

First, we will need to create a hook, for that, we are going to make a simple state function. Create a file in the "checkout" app in "apps/checkout/hooks/useAddToCart.ts" and insert the code below in the file:

import { useState } from 'react';

export default function useAddToCartHook() {
  const [itemsCount, setItemsCount] = useState<number>(0);
  return {
    itemsCount,
    addToCart: () => setItemsCount((i) => i + 1),
    clearCart: () => setItemsCount(0),
  };
}

Once this is done, add the file to the list of modules exposed in the "next.config.js" file:

module.exports = withFederatedSidecar({
  // ...
  exposes: {
    './buy-button': './components/buy-button/buy-button.tsx',
        './useAddToCartHook': './hooks/useAddToCart.ts'
  },
  // ...
})(nxNextConfig);

To import the hook, let’s create a new page that will be imported asynchronously, for that create a new folder in the store app called async-pages. Create a custom-hook.tsx file that will be our page inside the async-pages folder, then add the following code to the file:

// typing for the hook
type UseAddToCartHookType = () => UseAddToCartHookResultType;

// hook function return typing
type UseAddToCartHookResultType = {
  itemsCount: number;
  addToCart: () => void;
  clearCart: () => void;
};

// hook default value
let useAddToCartHook = (() => ({})) as UseAddToCartHookType;

// import the hook only on the client-side
if (process.browser) {
  useAddToCartHook = require('checkout/useAddToCartHook').default;
}

export function Page() {
    // on server side extracts the values as undefined
    // on the client side extracts the hook values
  const { itemsCount, addToCart, clearCart } =
    useAddToCartHook() as UseAddToCartHookResultType;

  return (
    <div>
      <h1>Welcome to Custom Hook!</h1>

      <p>
        Item Count: <strong>{itemsCount}</strong>
      </p>
      <button onClick={addToCart}>Add to Cart</button>
      <button onClick={clearCart}>Clear Cart</button>
    </div>
  );
}

// here you can use the getInitialProps function normally
// it will be called on both server-side and client-side
Page.getInitialProps = async (/*ctx*/) => {
  return {};
};

export default Page;

Now we need to create a page in the "pages" folder that loads our page asynchronously, for that use the command below:

nx g @nrwl/next:page custom-hook --project=store

Now open the newly created page file and add the following code

import dynamic from 'next/dynamic';
import type { NextPage, NextPageContext } from 'next';

// import functions from page in synchronously way
const page = import('../../async-pages/custom-hook');

// lazy import the page component
const Page = dynamic(
  () => import('../../async-pages/custom-hook')
) as NextPage;

Page.getInitialProps = async (ctx: NextPageContext) => {
    // capture the getInitialProps function from the page
  const getInitialProps = ((await page).default as NextPage)?.getInitialProps;
  if (getInitialProps) {
        // if the function exists, call the function on server-side and client-side
    return getInitialProps(ctx);
  }
  return {};
};

export default Page;

Now you can see the following result

Some errors at the time of writing this article may be occurring, so if in doubt, consider looking at this project I created as a proof of concept, I’m actively working with Zackary to make it up to date and functional.

Deploying projects on Vercel

The procedure that we are going to perform now will be done at Vercel, but we can replicate it without much difficulty on other serverless hosting platforms such as Netlify, AWS Amplify, and Serverless with a plugin for Next.js or even in a self-hosted way using Docker with a private server.
We can carry out the process in two ways: by interface or by CLI, but to facilitate the process we will do it by the interface, you just need to host the project on GitHub so that we can import it in a few clicks, once the project is on GitHub you can open this page on Vercel to deploy the first application… exactly, although it’s a monorepo, we’re going to configure everything so that separate deployments are made.

First, we will deploy the "checkout" app because it has fewer dependencies, for that select the repository as in the following image and click on the button to import it:

Choose a name for the application on the screen that opens but remember that we are still going to do the same step for the app "store" so define a different name for each project. We must change some commands for the project build in the "Build and Output Settings" tab, for this, check the override option and leave the fields as shown below:

Build command (checkout)

npx nx build checkout --prod

Output directory (checkout)

dist/apps/checkout/.next

For now, let’s skip the environment variables section, as we don’t have the URLs where the applications will be hosted, we can click on the "Deploy" button. You may notice that we may have an error during the build, but don’t worry if that happens, we’ll solve this soon. Now we are going to deploy our app "store" and we are going to do the same steps as before, just changing some fields on the "Build and Output Settings" tab. Build command (store)

npx nx build store --prod

Output directory (store)

dist/apps/store/.next

Once that’s done, we can click on the "Deploy" button. Again, you’ll notice that the build resulted in an error, but that doesn’t matter, the important thing is that we now have the two URLs of the two projects and we can use them to configure our environment. Now go to the settings panel of each application and set the following environment variables

Note that I am using a URL of the “deployment” that I made of my app store, you must do it with the URL that Vercel generated for yours, remember to define the two environment variables "NEXT_PUBLIC_CHECKOUT_URL" and "NEXT_PUBLIC_STORE_URL" each with its respective URL of production.

Private dependencies with Vercel

If you open the project build logs, you will notice that in both the error is the same, probably something like this

npm ERR! 403 403 Forbidden - GET <https://r.privjs.com/@module-federation%2fnextjs-mf/-/nextjs-mf-3.5.0.tgz> - You must be logged in to install/publish packages.
npm ERR! 403 In most cases, you or one of your dependencies are requesting
npm ERR! 403 a package version that is forbidden by your security policy, or
npm ERR! 403 on a server you do not have access to.
npm ERR! A complete log of this run can be found in:
npm ERR!     /vercel/.npm/_logs/2022-06-24T21_11_19_939Z-debug-0.log
Error: Command "npm install" exited with 1

This happens because Vercel does not have the necessary credentials to access a package that is in a private repository, to give access to the repository we need to configure an environment variable called "NPM_RC", the value of this variable must be the same as what is inside the "~/.npmrc" file which was created when we used the "npm login" command.

To do so, just create a new variable in Vercel’s environment variables settings panel called "NPM_RC" and insert the entire contents of the "~/.npmrc" file, if you have any doubts read this document.

Finally, you can open the “Deployments” tab and “Redeploy” your application!

Navigating to the application "store" URL you can see the button whose source code is in the "checkout" project being "federated" to our site.

References

Debugging NgRx in NativeScript with Redux DevTools

Valor-software-tech — Wed, 08 Jun 2022 11:33:00 +0000

The solution and the story were kindly provided by Eduardo Speroni, a NativeScript developer at Valor Software, a talented open-source activist and contributor.

Intro
NgRx needs practically no introduction in the current state of Angular applications. It allows you to manage your app’s state easily and make your UI react to the changes seamlessly. This tool is not exclusively for the web, so we can expect many NativeScript Angular applications to use it quite extensively.

Although NgRx is amazing, it still adds certain complexity to your application that is often harder to debug. For such cases, using Redux DevTools becomes indispensable in the debugging process, as it allows you to have a clear view of your state and how it changes over time. Those features, alongside time travel and custom action dispatch, make it a very powerful tool.

Many stacks have to implement their own way of integrating NgRx with Redux DevTools, for example, with Ionic, as Zack Barbuto describes in his article about remote debugging. Also, thanks to our recent efforts on WebSockets for NativeScript (find the creation story on the blog) and the chain webpack configuration added in @nativescript/webpack 5+, you can debug NgRx in NativeScript with ease. In this article I’ll tell you about our implementation details and how you can start using it right away.

Table of Contents:

Intro
Connecting Redux DevTools with NgRx for NativeScript
Overriding the way NgRx fetches the Redux extension implementation
Nativescript-ngrx-devtools plugin: features review
How to use the Plugin, steps to reproduce for debugging
Caveats
Useful Links

Connecting Redux DevTools with NgRx for NativeScript

NgRx relies on the Redux DevTools Extension to be defined in the window and implement a specific (and relatively simple) interface. Redux Remote DevTools provides an option to connect to it remotely through SocketCluster, which uses WebSockets. Thankfully, we can now use the WebSockets plugin to polyfill them.

This approach is not new, and part of our implementation can be credited to Zalmoxis and his remote debugging method. Not all node or browser libraries support NativeScript, but we can make most of them work with it. Since NS isn’t either “node” or “browser” but a combination of multiple APIs common to both, libraries that support both platforms might be usable here. SocketCluster is one of those libraries that work perfectly with NativeScript as long as we use the browser implementation. As a result, we implemented a custom way of reading the browser field spec, which is also nicely described on npm and applied the required file substitutions individually for the required libraries. This means we can now use the web version of SocketCluster freely in our implementation without fear that it’ll break existing applications.

Taking inspiration from previously mentioned implementations of the extension interface, we built our own interface focusing on reliability and small footprint. This was done by converting it fully to RxJS, adding error handling, retrying failed connections, trying to connect to multiple default debugging IPs periodically, and making it all highly configurable. The result was a robust bridge between your application and the remote Redux DevTools so that you can focus less on the details and more on developing your application faster.

Overriding the Way NgRx Fetches the Redux Extension Implementation

Once we finished writing the Redux DevTools Extension interface, we needed to provide it to NgRx. Unfortunately, NgRx gets this information from the [‘REDUX_DEVTOOLS_EXTENSION’] window, which isn’t available in NativeScript. Polyfilling “window” is not the best approach either, as it could also lead to unintended side effects due to many libraries checking if a window exists to determine if they’re running in a browser environment or not. With a PR to NgRx, we were able to export the required symbol to override the way NgRx fetches the extension implementation.

As a side note, this change isn’t retroactive, but the plugin code has a workaround for cases when this symbol is not defined, so you can use it with older versions.

Nativescript-ngrx-devtools Plugin: Features Review

Below is the overview of key plugin features, so you get to know it better before the installation.

The beginning of work with the plugin:

Plugin replays the state after skipping actions:

The increment with delay:

Dispatching a custom action:

How to Use the Plugin

To start using the plugin, first ensure to install both: it and our WebSockets Polyfill:

npm i @valor/nativescript-ngrx-devtools
@valor/nativescript-websockets

In your polyfills.ts, ensure that websockets is properly polyfilled after nativescript’s globals:

/**
 * NativeScript Polyfills
 */
// Install @nativescript/core polyfills (XHR, setTimeout, requestAnimationFrame)
import '@nativescript/core/globals';
import '@valor/nativescript-websockets'; // add this line!

You can then import the modules of your application and start using it:

@NgModule({
 imports: [
   NativeScriptModule,
   StoreModule.forRoot(
     {
       counter: reducer,
     },
     {
       initialState: {
         counter: initialState,
       },
     }
   ),
   ...(__DEV__ ? [ // ensure this code is tree shaken in prod
         StoreDevtoolsModule.instrument(), 
         NativeScriptNgRxDevtoolsModule.forRoot()
      ] : []),

 ],
 declarations: [AppComponent],
 bootstrap: [AppComponent],
 schemas: [NO_ERRORS_SCHEMA],
})
export class AppModule {}

By default the plugin will attempt to connect to many IP addresses that NativeScript automatically detects from NS_DEV_HOST_IPS on port 8000, but those can be configured in the options object in NativeScriptNgRxDevtoolsModule.forRoot(options).

After configuring our remote devtools, you can just start debugging!

Steps to Reproduce for Debugging:

npm i -g @redux-devtools/cli‍

Then
‍
redux-devtools — open‍
Open ‘Settings’ in the redux-devtools UI and ensure ‘connect local’ is checked and you’re going to use port 8000 which is default, then save those settings.
Run a NativeScript app and start debugging.

Caveats

Redux DevTools already has a couple of caveats on the web, like having it crash by storing certain kinds of non-serializable objects. This also applies to NativeScript, and the fact that ignoring those caveats can also crash your app makes them even worse. Here’s an example from one of the projects we’re working on now. When testing the plugin on a large mobile app that has modals with high-definition images, we noticed that the app would crash due to a memory lack. The issue was that the action that was sent to the DevTools, contained a reference to the modal itself, so it was never garbage collected, and every time it opened, the memory would increase. Connecting to the DevTools also made the app take a performance hit as it was trying to serialize massive objects.

The solution, in this case, is to use actionSanitizer and stateSanitizer to make sure your state and actions contain only serializable data.

How it works with the plugin:

Find more on this topic from the Use sanitizers to avoid Redux Devtools crash article by Migzar Navarro and the NgRx official guide. Also worth mentioning that it’s critical to ensure you’re using webpack flags, not to bundle the DevTools in production. As they have a memory overhead you don’t want in production apps.

That’s all I wanted to tell in this article. Hope, it was useful, and you’ll enjoy using the plugin!

Useful Links

nativescript-websockets plugin
nativescript-ngrx-devtools plugin
package-alias-plugin.js
Remote Debugging @ngrx/store with Ionic article by Zack Barbuto
Remote debugging method by Zalmoxis
Configuring npm — package-json documentation
The browser field when packaging modules for client side use spec

Performance Testing via Artillery.io - user guide

Valor-software-tech — Wed, 09 Mar 2022 12:33:50 +0000

Valor's Head of QA Dmitry has shared his experience using Artillery.io including tips and tricks for beginners. The following story is on his behalf, and the original material was published on the company's blog.

Intro

Today, I’m going to tell you all about setting up and using Artillery.io on your projects. We have a lot of popular testing tools like JMeter, Gatling, LoadNinja, etc. So you might be wondering why I’ve chosen Artillery. Well, I’m going to show its advantages and share handy usage tips later in the article.
‍
‌Artillery.io is a modern performance testing software that is powerful yet quite simple to navigate. It suits different types of performance testing, on local machines and as part of CI. What’s even better? – Artillery provides a free ‘Dev’ option if you want to test the waters before diving in. So, let's make some exploration!

Why Artillery.io?

Artillery offers many services that make performance and load testing faster and more reliable. Now let me outline a few reasons why I choose to use it over the better-known software.

Node.js tool
Java-based tools can be complicated and time-consuming to work with. Artillery.io is a Node.js tool with a basic СLI, which is a far simpler way to run performance tests.
Broad support of protocols, frameworks, and libraries
Out of the box, Artillery.io will support:

HTTP
Socket.IO
WebSocket
However, you can use Artillery.io to test any stack, thanks to the plugin interface. Here are a few examples:
Apache Kafka
Amazon Kinesis
HLS (HTTP Live Streaming)‌
YAML format
Unlike popular competitors’ testing tools, Artillery.io writes tests in YAML format which makes them readable and easy to understand. Artillery also supports a JSON format for testing.

Accessible scenarios
With Artillery's scenarios and phases, you can build more flexible tests and cover multiple use cases in parallel. Also, it takes you just a few steps and conditions to set up tests for complex user behaviours. Finally, it's easy to reuse scenarios for comparison and future testing.
Easy integration
Artillery.io seamlessly integrates with CI (for example, check the integration guide for GitHub Actions), making the process very organized. It also works with Docker, so you can run your Artillery tests inside a Docker container.
Detailed reports
After running tests, you can create a JSON report through the --output flag. Also, you can generate an HTML report out of JSON to save it as a file or export it to your browser. Find details on reporting in the Scenario section below.
Artillery Docs
Artillery provides numerous documents to browse for instructions and other useful info. This helps you get the performance testing software up and running much smoother than with other similar tools. Also, you can look up support from other developers on community forums.

How does Artillery.io work?

I’m going to walk you through some basic commands to get started with Artillery.io using ngx-bootstrap in my examples. Ngx-bootstrap, together with other community libraries, were created by Valor Software, the company where I’m working. And as we have hundreds of thousands of engineers using our products monthly, we need scalable performance testing to make sure everything runs smoothly. So, let’s get started!

First, you need to install the latest version of the software.

Install
To install the latest version, enter:
npm install -g artillery@latest

Fast test
To run a fast test, enter:
artillery quick --count 15 -n 30 https://valor-software.com/ngx-bootstrap/

With this command, the test will run 15 virtual users with each of them making 30 HTTP GET requests to the URL address that you specified.‌

This command also supports other flags to configure your fast tests:

Below is a list of possible configurations of the run command:

Config
For standard test scenarios, you should create a ‘my.yml’ file with config.

The my.yml file should contain ‘config:’ paired with the target URL. To set up environments for your tests, you can write environments into the command after the target URL has been entered.

Phases in the config
Artillery.io allows you to enter multiple sequential load options for the application. The testing phase consists of several aspects:

duration: the time of one phase;
arrivalRate: the number of users added each second;
rampTo: up to how many users per second the load will grow by;
name: a name of the phases.

If you only have one target URL, the different phases of the performance testing are placed right after it. If there are multiple environments, then you should add phases to each environment variable.

Plugins
In the Artillery npm utility, you can find lots of plugins that can help you in your performance testing. Install artillery-plugin-expect to compare the expected result with the actually received result.

Then, after the phases inside the config, enter:
plugins: expect: {}

Now, with the config completed, we can finally write some tests!

Scenario
All tests should be written in the scenarios section and should contain:

GET, POST, PUT, DELETE, and some other commands;
a URL for every endpoint;
the body text in JSON format;
all checks you want to run.

To run tests, you should enter:
artillery run my.yml

To run a test and then generate a report in a .txt file, run:
artillery run -o first.txt my.yml

After generating a .txt report, to generate a second report in HTML, run the command:
artillery report first.txt

Here's the report example:

Authentication
With Artillery.io, you can use basic authentication or get authorized by tokens uploading CSV with your credentials. Just pick an option that suits your project best.

Check their official documentation to find information on authentication and many other aspects of Artillery.io.

Let's first revise how you can get authorized by tokens. To upload a CSV file with credentials, you should add the following lines into the config file:

payload – to use the payload functionality;
path – to write a path for the CSV file that Artillery needs to use;
fields – names of fields that you need to use.

See an example with a CSV file:

The second way to get authorized is through environment variables. And we have several options for this. The first one is to execute an export command in your console as below:

And after it's done, you can use your variable inside your yml file:

Another option is to write a new script with an environment variable in your package.json file to execute your tests without typing the export variable in the terminal each time. It will look like this:

Then all you need to do is run this script in the terminal:
npm run artillery:run

Finally, you can upload CSV to pass parameters for your test requests: GET, POST, PUT, etc.
Check an example with POST:

Final thoughts
Artillery.io is an accessible and comprehensive tool that I use and can surely recommend for performance testing.

With a free Artillery Core version, you can run tests from a local or virtual machine. And by switching to Artillery Pro, you're getting a self-hosted AWS performance testing platform.

Other features of Artillery Pro include:

runs millions of tests per second across 13 geographical regions;
works with existing security systems;
no repeat charges or paid maintenance;
VPC internal test services.

I hope this article has given you some clarity on Artillery’s software, and helped you make a choice regarding the performance testing tool you want to work with. ‌‍

In case you’re looking for help in software testing, or your project needs an advanced quality assurance pipeline – drop us a line!

Useful Links

How to deploy Firebase Preview Channels on Travis CI

Valor-software-tech — Thu, 22 Jul 2021 14:53:00 +0000

Nikita Glukhi, Software Engineer at Valor Software, kindly provided this story and the solution.
Firebase has released the long-awaited Preview channel functionality, which allows for the testing of updates. All Firebase (not Firestore!) users can benefit from this hosting feature. And you may be asking what about Travis CI or other hosting users? Can they use preview channels as well?
At the time of this article’s publication, GitHub Actions does not yet natively provide automated procedures for Travis CI from GitHub. Below is a solution to use preview channels by Firebase with your existing Travis CI deployment environment.

Check updates with no risk for users’ experience

Let’s face the truth, to check the behavior of your polished and tested updates on production, you had to actually push them to production. Then, in case something fails, — get back to a previous version. Application users might have noticed inappropriate system behavior, which is a pity. To get rid of this kind of working situation, we can now use preview channels. Apply this new Firebase feature to automatically deploy updates and see how they behave, with no risk for real users’ experience. Also, you can comfortably leave comments for your updates, and amend them with your team. The best thing is that this temporary storage will remove itself after a preview channel link expires. No storage place taken!

Prerequisites:

You need to know Travis CI and have experience with the config file.
You need to know how to write Bash scripts and know the right stage to run the Bash script for preview channels.

Steps to reproduce:

Create a new local repository.
Create a new GitHub repository.
Run the ‘git remote add’ command to connect your local repository to the GitHub repository.
Set up Firebase project.
Set up Travis CI for GitHub repository.

Set up configuration variables — add environment variables in Travis CI. The variables that you need to set up are the two access tokens to work with Firebase and GitHub:
• To get FIREBASE_TOKEN, use the command: firebase login:ci
If the command doesn’t work, that’s probably because you don’t have firebase-tools
installed. For installation, run the following command: npm i -g firebase-tools, or curl -sL https://firebase.tools | bash
Then — run a firebase login command, then — firebase login:ci. The latter command gives you a Firebase access token that you want to use as a value for this step (To get FIREBASE_TOKEN…).
• Get GITHUB_TOKEN using this link: Creating a personal access token
Then, apply this value for the GITHUB_TOKEN variable.

In your local repository, run the ‘firebase init hosting’ command, choose your Firebase project from the list of already existed projects, and configure firebase.json file.
Create .travis.yml file in your local repository.
Create a Bash script — https://devdocs.io/bash/.
Add job to the .travis.yml file that should call the script that we’ve created as step 8. The job you need to insert into the .travis.yml file:

stages:
 - name: "Deploy to Firebase preview channel"
   if: branch = master AND type = pull_request
jobs:
 include:
 - stage: "Deploy to Firebase preview channel"
   skip_cleanup: true
   provider: firebase
   project: fir-project-dc47e
   before_script:
     - sudo apt-get install jq
     - npm install firebase-tools -g
     - npm run build:prod
   script: bash deploy-to-firebase-preview-channels.sh

Here fir-project-dc47e — an ID of your Firebase project

Push changes to GitHub and create a pull request. Now, back to solving our Travis CI issue and enabling its usage with the Preview channel Firebase functionality. Find the solution I came up with in the repository: Travis CI and Firebase preview channels solution. Or a brief version on gist: .travis.yml: preview channels deployment. I’ll separate the script into pieces and describe every step below. To deploy successfully, please, follow my guidelines step by step. I start with a deployment to a preview channel:

#!/usr/bin/env bash
DEPLOY_TO_PREVIEW_CHANNEL_RESULT=$(firebase hosting:channel:deploy pr-$TRAVIS_PULL_REQUEST --expires 30d --token $FIREBASE_TOKEN --json)

After running the deploy command, I get a response with an object containing data, and I have the following as a result:

{
 "status": "success",
 "result": {
   "fir-project-dc47e": {
     "site": "fir-project-dc47e",
     "url": "https://fir-project-dc47e--pr-1-t36vykr3.web.app",
     "expireTime": "2021-01-08T09:27:24.847798020Z"
   }
 }
}

Here fir-project-dc47e — an ID of your Firebase project
I add this object to the DEPLOY_TO_PREVIEW_CHANNEL_RESULT variable. This object has a .result parameter containing all the data needed for future operations.
Next, I select data from the .result parameter and add it to a separate variable that corresponds to the parameter name. This variable will contain an object with a key of ngx-bootstrap-demo.

RESULT=`echo ${DEPLOY_TO_PREVIEW_CHANNEL_RESULT} | jq -r '.result'`

The following goes to RESULT_DATA:

{
     "site": "fir-project-dc47e",
     "url": "https://fir-project-dc47e--pr-1-t36vykr3.web.app",
     "expireTime": "2021-01-08T09:27:24.847798020Z"
   }

Now, I extract a website name from the RESULT_DATA variable. The result will go to the SITE variable:

SITE=`echo ${RESULT_DATA} | jq -r '."site"'`

I extract a preview channel URL from RESULT_DATA variable, and the result goes to the URL variable:

URL=`echo ${RESULT_DATA} | jq -r '."url"'`

Then — extracting data with the expiration time from the RESULT_DATA variable. And, I write it down to the EXPIRE_TIME_UTC variable. UTC format is a default one, so I bring it to the needed format which is GMT, in my case.

EXPIRE_TIME_UTC=`echo ${RESULT_DATA} | jq -r .expireTime`
EXPIRE_TIME=$(TZ='GMT' date -d $EXPIRE_TIME_UTC +%c)

The NEW_COMMENT variable creates a text with a project name, link to a preview channel, and its life duration. I’ll add this text of the comment to a pull request later (TRAVIS_PULL_REQUEST/comments).
Then, I extract all the comments from the pull request I want to work on, using the request to GitHub API. The result goes to the COMMENTS variable. The Objects array will have a description for each comment.

COMMENTS=$(curl -H "Authorization: token $GITHUB_TOKEN" -X GET "https://api.github.com/repos/$TRAVIS_REPO_SLUG/issues/$TRAVIS_PULL_REQUEST/comments")

I declare variables for test cycles. Using the SUBSTRING variable, I search for a comment that might have been added before to replace it with the latest one.
COMMENT_ID equals -1 by default. In the future, I’ll assign a comment ID that I find to it. In case of no overlaps appeared, the value stays as default.

SUBSTRING="Project: fir-project-dc47e"
COMMENT_ID=-1

In this cycle, I sort out the COMMENTS array, and extract the body of each comment — its text, and search for a substring in this body. If an overlap is detected, I take the comment ID and assign it to the COMMENT_ID variable. If no overlaps are detected, then nothing is assigned, the loop just runs as before.

for row in $(echo "${COMMENTS}" | jq -r '.[] | @base64'); do
echo ${row}
  _jq() {
     echo ${row} | base64 --decode | jq -r ${1}
  }
  BODY=$(_jq '.body')  if [[ ${BODY} == *"$SUBSTRING"* ]]; then
    COMMENT_ID=$(_jq '.id')
  fi
done

Finally, I run a COMMENT_ID test, if it equals 0 or is more than 0, it means a comment like this exists, and I need to refresh it. Then, I refer to GitHub API (GITHUB_TOKEN). If there’s no comment — the command creates a new comment in a pull request (GitHub API, as well).

if [[ ${COMMENT_ID} -ge 0 ]];
 then
   curl -H "Authorization: token $GITHUB_TOKEN" -X PATCH -d "{\"body\": \"$NEW_COMMENT\"}" "https://api.github.com/repos/${TRAVIS_REPO_SLUG}/issues/comments/${COMMENT_ID}"
 else
   curl -H "Authorization: token $GITHUB_TOKEN" -X POST -d "{\"body\": \"$NEW_COMMENT\"}" "https://api.github.com/repos/${TRAVIS_REPO_SLUG}/issues/${TRAVIS_PULL_REQUEST}/comments"
fi

As a result, I get the link with the comment to a preview channel. And, the comment we get from the previous operation comes from the person which token we use.

Any questions?

Feel free to contact me if you have any questions or troubles with deploying the script: nikita.glukhi@valor-software.com.

Useful links:

Issue Comments for a repository — extract all the comments for a repository (as well as for a preview channel, but there’s no example in the doc)
Create an issue comment
Update an issue comment — refresh an existing comment