Stories by Valor Software on Medium

Nx, Next.js, and Module Federation

Valor Software — Thu, 21 Jul 2022 16:14:04 GMT

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 was originally published on 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 front-end. 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 micro frontends 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 micro frontend 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 headaches for the team, but that’s where the very powerful Module Federation comes in.

Thanks to it, only one team would be 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:

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:

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:

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 executes 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 nextjs-mf or nextjs-ssr plugin which currently requires a paid license!

To install the tool, we need to login to PrivJs using npm, to do so, run the following command:

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 (
    
      Welcome to Store!

       alert('Hello, Module Federation!')}>Add to Cart
    

  );
}

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(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:

import { useState } from 'react';

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

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 (
    
      Welcome to Custom Hook!


      
        Item Count: {itemsCount}
      

      
      
    

  );
}

// 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:

npx nx build checkout --prod

Output directory (checkout)

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

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  - 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:

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.

Originally published at https://valor-software.com.

Debugging NgRx in NativeScript with Redux DevTools

Valor Software — Wed, 08 Jun 2022 10:03:51 GMT

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.

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:

1. Run

npm i -g @redux-devtools/cli‍

2. Then
‍
redux-devtools — open‍

3. 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.

4. 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

Implementing WebSockets plugin for NativeScript using React Native

Valor Software — Mon, 04 Apr 2022 15:57:36 GMT

Eduardo, Angular Engineer at Valor Software, put his effort into the creation of the plugin as well as writing the story about it below.
This material was originally published on the company’s blog.

JS empowerment with native platform APIs

As friends of the NativeScript community and preferred partners, we’re constantly trying to improve the NativeScript framework, community, and developer experience.

Sometimes it’s good to reiterate NativeScript’s goal: to empower JavaScript with native platform APIs. This has been the core focus for a while, and contrary to a common perspective among developers, NativeScript itself is actually not a competitor to other frameworks. Rather it is designed fundamentally to celebrate platforms while enhancing the entire JavaScript community (including other approaches, like React Native or Capacitor). As an example, @nativescript/capacitor allows you to use the full NativeScript capabilities within Capacitor itself.

@nativescript/core is a JavaScript library that takes full advantage of what NativeScript offers (it’s merely just a glimpse of what is possible with NativeScript as a whole), and all the other flavors like @nativescript/angular, nativescript-vue, and react-nativescript are compliments to each framework itself.

WebSocket plugin for NativeScript

WebSockets are frequently required for applications, be it for standard WebSocket communication, MQTT, debugging through Redux Remote Devtools, using socket.io, and sometimes even used internally on NativeScript itself.

When researching the best solutions for a WebSocket polyfill, there were no implementations better and more battle-tested than React Native’s. With that in mind, we decided to use its approach with NativeScript. Something we later discovered to be surprisingly easy and painless due to the overall quality of the original implementation. There were only three functions that were not needed (logs and assertion helpers from the original implementation), but we reimplemented them to maintain a similar behavior. In the end, it proves that React Native and NativeScript are really complementary and quite interoperable.

Visit npm to use the WebSocket plugin for NativeScript, and scroll down to proceed with the Implementation part!

Implementation

Check the original React Native implementation from where we started. Except for a few functions, like RCTAssert, RCTAssertParam, and RCTLog, everything else just worked straight out of the box. Since NativeScript allows you to use platform APIs as they were designed (most often synchronously) and without the need for a bridge, we also could drop all related bridge code from the React Native implementation and adjust a few data handling items (eg. converting from NSData to ArrayBuffer).

Here are the steps we followed:

Created a public workspace for NativeScript plugins based on the NativeScript plugin workspace docs and generated the plugin through Nx.
Created a native-src with the Xcode project and built scripts, using the React Native approach.
Ran `ns typings ios` from within the “apps/demo” folder to generate the typings for the RCTSRWebSocket class.
Started writing the WebSocket polyfill straight from JavaScript, which involved creating the Native delegate and calling a callback when these events happened.

Made small adjustments related to data types and converted them to JavaScript types when needed.

And the remaining implementations were just a case of translating Objective-C to TypeScript:

One critical detail to remember about JavaScript while handling any platform API is that it’s single-threaded. Blocking calls will block the main thread, which is the reason we needed a native implementation on iOS. The iOS native implementation is responsible for receiving the calls, doing work on other threads, and then returning back to the main thread.

On the Android side, React Native uses OkHttp for its WebSockets, which already handles all the threading details, so we needed no native code at all! All we did here was translate the Java implementation to JavaScript. However, we could have used the .java “as-is” as well, which is where NativeScript is endlessly versatile (you have the choice), so we just decided to use TypeScript here.

Another interesting detail with NativeScript is the sheer reduction in code to manage — originally this code was over 400 lines: WebSocket module. And we were able to transform this into under 150 lines of easy to read JavaScript code. Below you can see a comparison between the original code for WebSocket module in Java and in NativeScript:

A couple of conversions were needed for binary data. In React Native, binary data is converted to a base64 string in JavaScript and converted back to binary on send:

In NativeScript, we are able to manipulate native types directly, so we can do a simple conversion:

The same adjustments made to convert NSData to ArrayBuffer were needed for Android, but since Android doesn’t have a helper for it, we converted from ByteString:

And that’s it! We now have a nice API for WebSockets for both iOS and Android platforms with a well defined interface:

Then it was just a matter of wiring up a simple WebSocket polyfill.

Not to compete, but evolve and excel

In conclusion, we want to underline that it is part of our mission as a company and engineers individually to contribute to open-source technologies and make them even better. This way, we can provide developers from around the world with more flexible and responsible options to build software products and overcome their daily challenges. Also, NativeScript is in no way competing with other JS frameworks and on the contrary can be applied in combination with other technologies, for example inside Capacitor by Ionic.

Finally, we admire the quality with which WebSockets polyfill was implemented in React Native. The code structure with minimum dependencies allowed us to use it with NativeScript quite effortlessly.

Useful links

- WebSockets plugin for NativeScript on npm

- Connecting WebSocket through API

- React Native documentation about WebSocket support

- Docs on native API access

- Adding ObjectiveC/Swift code to NativeScript

- iOS marshalling

Diving into seeking issue with MP3 files

Valor Software — Wed, 23 Mar 2022 19:47:34 GMT

The following story is kindly provided by Eduardo, an Angular developer at Valor Software.

Playing stops before the end of the track

While working on a 10 million-plus user meditation app, I ran into a very weird issue. While the Quality Assurance team was trying to play a track, it would stop playing with around 13 seconds remaining and report as completed. After some testing, it seems the issue was only happening when there was seeking involved. Playing the whole track always ended at 0s remaining, pausing and playing had no impact either.

Seeking within MP3

Looking into the file format, I found it is an MP3. There are many ways to seek within an audio file. One way is to build an index of timestamps and byte offsets, like checkpoints in the track. Option two is what MP3 does: nothing. MP3 has bitrate, so you seek it by multiplying bitrate with time. Want to seek 6.3 seconds in a 100 kbps file? — Jump to the 630kb position (small b here means bits, not bytes). Should be somewhat accurate, but a 10s+ difference seems a bit too much. That is until you analyze the files:

$ mpck ./track_with_issue.mp3
SUMMARY: track_with_issue.mp3
    version                       MPEG v1.0
    layer                         3
    average bitrate               279491 bps (VBR)
    samplerate                    44100 Hz
    frames                        31503
    time                          13:42.935
    unidentified                  0 b (0%)
    errors                        none
    result                        Ok

$ mpck ./other_track.mp3
SUMMARY: ./other_track.mp3
    version                       MPEG v1.0
    layer                         3
    bitrate                       160000 bps
    samplerate                    44100 Hz
    frames                        131786
    time                          57:22.573
    unidentified                  0 b (0%)
    errors                        none
    result                        Ok

Notice the first track has an Average Bitrate. Welcome to the marvelous world of VBR, also known as Variable Bit Rate. MP3 encoded in VBR means you don’t know where exactly to seek to because the bitrate isn’t constant, so you “guess” based on the average bit rate. Imagine you have 10 seconds of 100 kbps and 10 seconds of 200 kbps bitrate in a single file. You have 100kbps from 0 to 1000kb and 200kbps from 1001 kb to 3000 kb. The average bitrate is 150 kbps, but if you seek to 10 seconds using the previous formula, you’d seek to 1500 kb, which is already in the 200 kbps part, jumping to about 12.5 seconds of the track. Also, note that if you inverted the parts, you’d be at 7.5s.

Disclaimer.
‍Please, keep in mind that calculations have been simplified to make them easier to understand and are not 100% accurate.‍

Solution time!

So what could be done? — Well, the first obvious solution would be to just re-encode it in MP3 with CBR (constant bit rate). The most elegant solution, though, is to drop MP3 completely and start using better audio formats like Vorbis/Opus (.ogg), which have proper support for seeking.

Thanks for attention! Hope to be back with the next discovery soon :)

TagTide library: make your HTML editor-friendly and more

Valor Software — Wed, 09 Mar 2022 15:47:43 GMT

This material is created and kindly provided by Vyacheslav, a full-stack software engineer of Valor Software. And he’s telling the story below :)

Intro

A couple of months ago, our customer approached me with an interesting task that appeared not complicated at first glance. I needed to create a simple web app with a Grammarly-like view based on a WYSIWYG HTML editor. This app should count different text units like paragraphs, sentences, words, and characters. The best thing is that despite the specifics of text source: websites, Google Docs, MS Office, email clients, your content will be carefully analyzed for units and displayed in a form convenient for perception.

No prizes for guessing what kind of issue I faced in this case :) External content from most of the resources contains redundant HTML tags, which influences the correctness of calculations. Moreover, messed code makes testing an annoying process. So, eventually, I came up with the solution for cleaning HTML from unnecessary tags and polishing it for further work with text.

The principles of HTML code prettifying

Let’s think about basic steps to get “editor-friendly” HTML code. I’m going to describe the idea with a demonstrative example. Imagine we have a perfect code that defines paragraphs.

The code could be the following:

Shakespeare produced most of his known works between 1589 and 1613.

His early plays were primarily comedies and histories and are regarded as some of the best work produced in these genres. He then wrote mainly tragedies until 1608, among them Hamlet, Romeo and Juliet, Othello, King Lear, and Macbeth, all considered to be among the finest works in the English language.

The example above contains a couple of paragraphs. The second paragraph has two sentences, and the first one — just one.

Let’s look at the hypothetical messy equivalent of the same content:

Shakespeare produced most of his known works between 1589 and

1613.

His early plays were primarily comedies and histories and are regarded as some of the best work produced in these genres.

He then wrote mainly tragedies until 1608, among them Hamlet, Romeo and Juliet, Othello, King Lear, and Macbeth, all considered to be among the finest works in the English language.

What issues this messiness brings:

1. Redundant root div that should be ignored.

2. Since a div inside another div is correct, but a paragraph inside another paragraph is a mistake, it’s challenging to split the text into paragraphs.

3. Inline styles uglify whole text perception, but they don’t even influence calculation quality. We should get rid of them for aesthetic reasons.

Steps to editor-friendly text

Our main goal is to transform the messy text into perfect paragraphs. Let’s call this kind of text “editor-friendly”. As far as the task contains various logic, we need to split the flow into separate activities. Let’s dig into that!

The first reasonable thing is that we need to ignore root div.

Shakespeare produced most of his known works between 1589 and 1613.
 His early plays were primarily comedies and histories and are regarded as some of the best work produced in these genres.
 He then wrote mainly tragedies until 1608, among them Hamlet, Romeo and Juliet, Othello, King Lear, and Macbeth, all considered to be among the finest works in the English language.

Looks better. Secondly, we should flatten the second paragraph. It means we should leave only one level of divs (in our case — root):

Shakespeare produced most of his known works between 1589 and 1613.
 His early plays were primarily comedies and histories and are regarded as some of the best work produced in these genres. He then wrote mainly tragedies until 1608, among them Hamlet, Romeo and Juliet, Othello, King Lear, and Macbeth, all considered to be among the finest works in the English language.

Our text looks much better because the second paragraph looks good. But if we talk about editor-friendly HTML code, we should change divs to pure paragraphs:

Shakespeare produced most of his known works between 1589 and 1613.

Looks almost perfect! We have just minor stuff left. We need to remove all redundant tag attributes (“class” in our case):

Shakespeare produced most of his known works between 1589 and 1613.

That’s it. We have 100% editor-friendly HTML code that contains a couple of pure paragraphs!

In conclusion, I want to summarize all provided steps that you can use as separate pattern:

1. Start from a certain point in the original code. You can ignore redundant tags that aren’t important anymore.

2. Flatten the code by removing redundant inner tags. The main goal of this step is preparation for paragraph splitting.

3. Change div tags to paragraphs.

4. Remove redundant attributes.

Technical approaches

At the start of the project, I intended to resolve the principles above via sets of pure regular expressions. As you can guess, this attempt failed. Regular expressions are not friendly with deep-nested lexemes. In this case, by lexemes, I mean nested HTML tags and their attributes. Having thought a little, I decided to use the AST-based approach because I shouldn’t reinvent the wheel in this case. I chose the HTML-parse-stringify library because this solution is minimalistic yet contains all the expected functionality regarding HTML AST processing.

My solution — the TagTide library

So, please, welcome TagTide. The main idea of the solution is a set of patterns you can apply anytime when you need them. Also, I suggest you apply them in sequence, just like the steps above.

Let’s repeat the steps of the above text transformations using TagTide.

import { TagTide } from "tag-tide";

const original = `

Shakespeare produced most of his known works between 1589 and

1613.

His early plays were primarily comedies and histories and are regarded as some of the best work produced in these genres.

He then wrote mainly tragedies until 1608, among them Hamlet, Romeo and Juliet, Othello, King Lear, and Macbeth, all considered to be among the finest works in the English language.
`;

const tagTide = new TagTide(original).startAfter("id", /^content/);

const startedAfter = tagTide.result();

console.log(startedAfter, "\n");

tagTide.flatten();

const flattened = tagTide.result();

console.log(flattened, "\n");

tagTide.rootParagraphs();

const paragraphs = tagTide.result();

console.log(paragraphs, "\n");

tagTide.removeAttributes();

const pureHtml = tagTide.result();

console.log(pureHtml);

Also, TagTide allows you to get the expected result in the shortest way handling the request in sequence by different objects (I use a chain of responsibility pattern):

import { TagTide } from "tag-tide";

const original = `

Shakespeare produced most of his known works between 1589 and

1613.

His early plays were primarily comedies and histories and are regarded as some of the best work produced in these genres.

He then wrote mainly tragedies until 1608, among them Hamlet, Romeo and Juliet, Othello, King Lear, and Macbeth, all considered to be among the finest works in the English language.
`;

const pureHtml = new TagTide(original).startAfter("id", /^content/).flatten().rootParagraphs().removeAttributes().result();

console.log(pureHtml);

Use cases

There is a couple of fundamental approaches how to change your HTML code using TagTide:

1. Direct changes via `traverse`;

2. Changes via the set of patterns.

This part contains different examples illustrating the approaches above.

Change some content in 2nd nesting level

import { El, TagTide } from "tag-tide";

const original = "level 1 level 2 level 3
";

const prettified = new TagTide(original)

.traverse((el: El, level: number) => {

if (level === 2 && el.content) {

el.content = `modified ${el.content}`;

})

.result();

console.log(prettified);

Output:

level 1 modified level 2 level 3

Aggregate numeric values from different nesting levels

import { El, TagTide } from "tag-tide";

const original = "1 2 3
";

let total = 0;

new TagTide(original).traverse((el: El) => {

if (el.content) {

total += +el.content.trim();

});

console.log(total);

Output:

`6`

Strip some tags

import { TagTide } from "tag-tide";

const original = "level 1 level 2 level 3
";

const prettified = new TagTide(original)

.result(['a', 'span', 'i', 'br']);

console.log(prettified);

Output:

level 1 level 2 level 3

Start after or Start from

This pattern allows us to ignore some parent structures:

import { TagTide } from "tag-tide";

const source = `content
`;

const result = new TagTide(source)

.startAfter("class", /^container-\d/)

.result();

console.log(result);

Output:

content

The following code illustrates another approach to set starter-tag. Also, a related tag can be included:

import { TagTide } from "tag-tide";

const source = `content
`;

const result = new TagTide(source)

.startFrom("class", /^container-\d/)

.result();

console.log(result);

Output:

content

Important notes:

1. In the “Start from” case, the result will include the associated (search) tag.

2. If no matching tag is found, these patterns don’t affect the result.

Flatten

This pattern will be useful if we need to remove nested tags:

import { TagTide } from "tag-tide";

const original =

"1 2 3
 middle 4 5
";

const prettified = new TagTide(original).flatten().result();

console.log(prettified);

Output:

1 2 3
 middle 4 5

Also, you can omit any tags that you want except for those you need to keep (ex.
, ,etc.):

import { TagTide } from "tag-tide";

const original =

"1 2 3
 middle 4 5
";

const prettified = new TagTide(original).flatten(['a']).result();

console.log(prettified);

Output:

1 2 3
 middle 4 5

Remove attributes

This pattern allows removing all or some attributes through the whole content.

In the following example, I’ve removed all attributes:

import { TagTide } from "tag-tide";

const original =

"1 2 3
 middle 4 5
";

const prettified = new TagTide(original).flatten().removeAttributes().result();

console.log(prettified);

Output:

1 2 3
 middle 4 5

In the following example, all attributes have been removed except:

* `id` attribute in all `span` tags

all `style` attributes

import { TagTide } from "tag-tide";

const original =

"1 2 3
 middle 4 5
";

const prettified = new TagTide(original).removeAttributes({'span': ['id'], '*': ['style']}).result();

console.log(prettified);

Output:

1 2 3
 middle 4 5

Root paragraphs

We need to replace the `divs` in the first level of HTML with `paragraphs`. If the `plain text` appears at the `first level` instead of another tag, it should be enclosed in a `paragraph`.

The following example shows how this approach works:

import { TagTide } from "tag-tide";

const original = "start
 middle finish
";

const prettified = new TagTide(original).rootParagraphs().result();

console.log(prettified);

Output:

start

middle

finish

An example of Google Docs content cleanup

The icing on the cake is the case with code that I took from an actual Google Docs document. Not to overload this article, I placed this example of code containing HTML on GitHub.

If you checked the link, I suppose you might be surprised by the volume of HTML in the document. Now let’s imagine you need to work with the text inside. Can you see the text there, by the way? — I guess not really because of lots of trash tags and attributes. The most exciting thing in this story is that using the TagTide script, you can transform code from my example into the following HTML:

Test test test

12 34

Aaa
Bbb
Ccc

The end

And you can repeat the same with the code taken from email clients, MS Word documents, and other sources!

In conclusion, I want to thank:

- Waqas Younas for long and fruitful cooperation

- Henrik Joreteg for html-parse-stringify

And in case you’re interested in other solutions for text editing and processing, check my Multi-Highlighting for DraftJS article. There I share how I added an option to highlight paragraphs, phrases, and words in DraftJS with my solution written in TypeScript.

Useful links

‍HTML-parse-stringify library for HTML AST processing
The TagTide library on GitHub
TagTide on npm
‍Multi-Highlighting for DraftJS — my other solution for highlighting text units in DraftJS editor

TagTide library: make your HTML editor-friendly and more was originally published in TagTide library: make your HTML editor-friendly and more on Medium, where people are continuing the conversation by highlighting and responding to this story.

Performance Testing via Artillery.io

Valor Software — Tue, 15 Feb 2022 21:51:59 GMT

This material was created by Dmitry Zhemchugov, Head of QA at Valor Software. And he’s the one telling the story :)
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?
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.
1. 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.
2. Broad language support
Out of the box, Artillery.io will support:
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)‌
3. 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.
4. 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.
5. 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.
6. 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.
7. 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:
Fast test
To run a fast test, enter:
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:
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:
To run a test and then generate a report in a .txt file, run:
After generating a .txt report, to generate a second report in HTML, run the command:
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:
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
- Installation through npm utility guide
- Artillery docs
- Artillery plugins on npm

ARC — a new weapon against accessibility bugs

Valor Software — Fri, 01 Oct 2021 11:11:22 GMT

ARC — a new weapon against accessibility bugs
Hello, my name is Maxym, I am QA Automation Engineer at Valor Software, and today I’ll guide you through ARC — a platform for accessibility testing. I’ll help you with setting it up and with creating a couple of scenarios. Also, I’ll make a short comparison between the web version of ARC and ARC Toolkit, a Chrome extension for quick accessibility checks.
Why do we need accessibility testing?
Accessibility testing as part of usability testing helps adjust our app to the needs of as many groups of people as possible. For example, it helps us make sure that users with special conditions like vision impairments, hearing disabilities, color blindness, and others can interact with the software smoothly.
The ARC Platform traits
In this article, I decided to share my experience of using ARC, a solution for accessibility testing that I find pretty handy and affordable (it even has a free extension). I’ll lead you through the setup of the platform because the process itself turned out to be tricky for a person new to ARC. Also, we’ll take a look at the report and specify the areas that we don’t want to miss. Finally, I’ll briefly cover the Toolkit and how this extension can contribute to your QA pipeline.
How it works
ARC crawls your website and scans pages while making the accessibility analysis. A nice thing about it is that you can run the check on two engines: the default ARC engine or AXE (in the latter case, you use ARC as a service for check and still stick to your trusted AXE testing platform). You can switch between both anytime.
ARC checks for accessibility problems and features according to WCAG accessibility standards and supports versions 2.0 and 2.1. The default scan runs on the ARC engine with the 2.0, but you’re free to switch versions yourself.
The best part is that you choose the engine and the WCAG version for every page you want to check. As a result of the evaluation, you get a report with the overall number of failures and suggestions for the first-priority fixes.
Getting the installation done
First, you need to create an account on the ARC portal.
Then, when you have an account — you create a workspace. For that:
1. Select “Workspaces” in the left menu.
2. Click the “Add a new workspace” button on the right.
3. Fill in the form and click “Submit”.
4. Open the workspace, select the “Monitoring” tab and click on “Add a new dashboard”.
5. Select “Domain”.
To learn more about User Flow, you can check the Support documentation (available after registration). But in short, the principle is the same as in end-to-end testing: you can upload your Selenium test or create a new one on the ARC platform. For a more precise explanation, check the ARC Knowledge Base.
6. Fill in the form, click “next” and then — “Complete”.
Congratulations, you’ve created a workspace and a dashboard for the page!
When the dashboard is ready, the scanning of the page will start automatically, and when it’s finished, you’ll get the report. It will pop up right on the monitor, or you can select the “Reports” tab on the left side of the menu and find your report there.
Also, it’s up to you how often you want to run the checks and whether you want them to run automatically. In the latter case, you just pick the run frequency, like daily, weekly, biweekly, monthly. Or you choose none of those and make accessibility checks upon request.
What to look for in the ARC report
After ARC completes its scanning, you get a relatively precise report on the failures and weak sides of the page. Also, you’ll see step-by-step guidance on how to fix the accessibility issues. In this part, I’ll outline the most important categories in the report that you should check in the first place.
1) WCAG priorities: here, ARC will highlight the most critical errors you need to prioritise and fix.
2) Top Assertions: ARC will sort failed assertions by quantity.
3) Explanation of detected fails with guidelines and recommendations for fixes.
For viewing the detailed explanation, you click on one of the failed assertions from the list (on the left side of the previous screen).
The ARC Toolkit — extension for a quick check
Another tool from the ARC family that I found useful is the ARC Toolkit. You simply install it as a Chrome browser extension and evaluate any page you browse through. If the page you want to check is not live yet, you can run the check on your localhost build. A special thing about the tool is that you can check particular sections of the screen instead of getting a whole page evaluation.
Installing and applying the Toolkit
1. Install the extension from the Chrome webstore.
2. Open the page you want to test for accessibility issues.
3. Then go to the Chrome dev tools, select the “ARC Toolkit” tab at the end of the list, and click on the “Run tests” big blue button.
4. After scanning the page, you will see a complete report with warnings, passed and failed assertions.
Basically, you get quite the same amount of information as with the ARC platform check: explanations of errors, recommendations for fixes, and guidelines for developers.
Scan sections, not pages
As I said earlier, unlike the on-site version, the extension can scan sections you need and not full pages. Here are the steps for running this check:
1. Open DOM tree and select the component/section you need to test.
2. Then click on the ARC Toolkit tab and select “Filter result for selected node only” from the checkbox. After, you’ll see the selected tag displayed in the “Limited scope”.
3. Run the tests :-)
How do the Toolkit and platform versions differ?
First of all, the Toolkit is free, and that’s a great advantage. You can start getting to know ARC using the Toolkit, and if it suits you — proceed with the paid version.
As for functional differences, despite the opportunity for particular page sections check, the Toolkit has a couple of flaws in comparison with the platform:
Using the Toolkit extension, you can not change the engine (it’s ARC only) and a WCAG version (the 2.1 version is the only one available).
You can not automate testing using the extension.
Pros and cons of ARC for accessibility testing
Here are the key things I like about using ARC:
You get informative reports and suggestions for fixing issues.
You can switch between different engines and WCAG versions for a more precise check.
You can integrate the ARC check into your automated testing pipeline.
What ARC can’t do:
It does not allow for screen reader testing.
As an option, you can use a separate tool for this purpose. In the case of my project, I went with the JAWS screen reader.
It can’t check keyboard focus, keyboard navigation, etc.
Currently, I haven’t found a better solution than testing these things manually :)
Prices
ARC Toolkit is completely free! As for the site version of ARC — they have 3 plans.
Let’s make accessibility the new norm!
ARC platform and its tools for accessibility testing may not be a magic pill that will cover all the aspects in terms of accessibility on your website. But, in my opinion, this solution works and helps you move towards greater usability with simple and clear steps.
Hopefully, you’ll give it a go and try to reproduce the setup flow I described above to make accessibility testing part of your QA routine. With ARC, you can make your site more friendly to people with special conditions and needs, and it is already a huge change! So, create an account and just do it! :)
Good luck!
Useful links
- WCAG accessibility standards
- ARC portal
- ARC Toolkit for Chrome
Available after you get started with the platform:
the ARC Knowledge Base
the ARC Support documentation

Setting up your project on GCP fast using Terraform and Kubernetes

Valor Software — Mon, 30 Aug 2021 15:25:18 GMT

Hi! My name is Angelina, and I’m a DevOps Engineer at Valor Software. With the help of this article, we’ll set up your GCP environment to work in tandem with Terraform. I’ll guide you through the setup of a basic cluster. For this, I picked the services that I use daily within my DevOps routine, since they are optimal for your typical project setup. Let me explain myself here! By typical I mean common projects that are natural (habitual) for your company or industry. In this case, I bet you’d appreciate a chance to build the environment once and clone it for future projects. That’s exactly the way you can go with the services I offer below. So, once you learn the basics for the project setup in this stack, you’ll be able to run new ones in the cloud in no time.
Automated setup with Terraform
When we need to set up a cloud infrastructure for the project, we want to make it quickly. That’s when automation tools come to help. Terraform is one of the instruments that serve for automated setup, and it is compatible with more than 70 providers, which is beyond handy. Besides, Terraform is pretty straightforward to get along with thanks to its declarative language. You don’t need to get used to a completely different CLI, like in cases when you switch to another cloud provider.
Why I suggest picking Terraform from the great variety of services is because it’s perfect for creating reusable infrastructures. You can also clone the existing infrastructure and apply it to your next project, with small alterations if needed. This benefit of reusability, together with the security that Terraform provides, makes it a first-choice technology for solving my daily tasks. BTW, it’s also the right place for keeping electronic keys and hidden or encrypted variables.
Another good point is that Terraform allows for managing several cloud infrastructures from different providers in parallel with minimal time and effort spent.
In this article, I’ll lead you through setting up infrastructure on Google Cloud using Terraform, so buckle up!
Kubernetes on Google Cloud Platform
Being one of the native Google products, Kubernetes is integrated into GCP quite as is, with no alterations. So you can conveniently set it up and manage it through the GCP CLI or with the help of external instruments like Terraform.
Before you begin
Create a Google Cloud project
Create a service account key and download it in JSON format
Terraform and GCP setup step-by-step
Create a new directory for the project and create a main.tf file for the Terraform config, and populate it with the following content:
provider "google" {
credentials = file("CREDENTIALS_FILE.json")
project = "your-project"
region = "us-west1"
}
Before we jump to the next step of creating a configuration file, we should remember to keep data (e.g. keys, project names) in separate files. This way we ensure project security and give ourselves a chance to reuse the configuration in the future. So, locate the project name, region, and credentials file in a separate file with variables.
First, create a variables.tf file and declare variables for it:
variable "credentials" {
type = string
}
variable "project" {
type = string
}
variable "region" {
type = string
}
Add the variables’ values to secrets.tfvars:
credentials = "CREDENTIALS_FILE.json"
project = "your-project"
region = "us-west1"
Then format your main.tf file like so:
provider "google" {
credentials = file(var.credentials)
project = var.project
region = var.region
}
Now, when your variables are safe, you’ll be able to pick the needed files with variables instead of repeatedly typing in new data in the main file.
With the `terraform init` command, you’re pulling up modules that you will need to proceed with further steps.
terraform init
If you see this message, it’s a success! Hurray!‍
Terraform has been initialised!
For the next step, you add variables to the variables.tf file:
variable "cluster_name" {
type = string
}
variable "cluster_zone" {
type = string
}
variable "app_name" {
type = string
}
Before creating a cluster, you should first add variables describing this particular cluster to the secrets.tfvars file:
cluster_name = “cluster-1”
cluster_zone = “us-west1-a”
app_name = “test”
Now add the cluster configuration to your main.tf file:
resource "google_container_cluster" "cluster-1" {
name = var.cluster_name
location = var.cluster_zone
initial_node_count = 3
node_config {
labels = {
app = var.app_name
}
tags = ["app", var.app_name]
}

timeouts {
create = "30m"
update = "40m"
}
}
In the configuration, you define the cluster’s name, its location, and the number of nodes and their labels. The default namespace is the place where you create a cluster.
To operate with the cluster and its components conveniently, you need to create an output.tf file, where you’ll add variables that will be displayed after running the `terraform apply` command. You can use them later by calling them during configuration.
output "cluster" { value = google_container_cluster.cluster-1.name}
Now add a new resource which is deployment:
resource "kubernetes_deployment" "example" {
metadata {
name = "terraform-example"
labels = {
app = var.app_name
}
}
spec {
replicas = 3
selector {
match_labels = {
app = var.app_name
}
}
template {
metadata {
labels = {
app = var.app_name
}
}
spec {
container {
image = "nginx:1.7.8"
name = "example"
resources {
limits = {
cpu = "0.5"
memory = "512Mi"
}
requests = {
cpu = "250m"
memory = "50Mi"
}
}
liveness_probe {
http_get {
path = "/"
port = 80
http_header {
name = "X-Custom-Header"
value = "Awesome"
}
}
initial_delay_seconds = 3
period_seconds = 3
}
}
}
}
}
}
In the deployment configuration, you specify the number of replicas, tags, labels, an image that we’re going to use, as well as internal resources. Finally, you have it all ready for the first launch and go with this command:
terraform plan -var-file=secrets.tfvars
In this way, you check if the configuration is created properly and if you’re satisfied with the range of resources.
When you’re quite sure that everything is correct, it’s time for the `terraform apply` command:
terraform apply -var-file=secrets.tfvars
And don’t forget to specify the file with variables! At this stage, you’ll have to confirm your actions by running a `yes` command. Terraform will build your new GKE cluster on GCP. After the cluster is created, you’ll see the output list.
For your convenience, in the future, you can split the config file into a few separate files. Place the provider block in the providers.tf file, and a “google_container_cluster” block — in the cluster.tf file.
Good job!
You’re almost done with your journey, the cluster is up and running, and you can be (ugh) proud of yourself!
For your future projects, you’ll be able to add more metrics and parameters when creating a resource. This will help you adjust your configuration for solving every particular task.
Useful links
Create a Google Cloud project
Create a service account key using the Google Cloud Console

How to deploy Firebase Preview Channels on Travis CI

Valor Software — Wed, 14 Jul 2021 12:47:37 GMT

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'`
For the next step, I extract fir-project-dc47e object from the RESULT variable:
RESULT_DATA=`echo ${RESULT} | jq -r '."fir-project-dc47e"'`
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 — create a new comment
Update an issue comment — refresh an existing comment
How to deploy Firebase Preview Channels on Travis CI was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scully Helped us Reach a 99 Lighthouse Score for a B2C Platform

Valor Software — Fri, 25 Jun 2021 14:16:22 GMT

Ruslan Ponuzhdayev, the software engineer of Valor Software, shared the story and greatly contributed to the solution described.
You may have heard of JAMstack. It recently entered top charts of technology choice for the web because of its ease of use, performance, and flexibility. Scully, a static site generator, brings JAMstack to the next level of effectiveness because of its Angular nature. Valor Software decided to adopt Scully to make the client’s platform fast and really convenient to use.
We sped up the overall page load and increased the platform lighthouse score to 99–100. Also, connecting Google eCommerce Marketing helped us see several areas for improvement on the website and in mobile apps to streamline the user journey. Learn from our experience how you can achieve a boost in website performance and visibility for your project using Scully and Google Analytics. Also, I’m going to help you overcome possible difficulties with integrations since we’ve already been there :)
Who the contributors are
Alexandr Pavlovskiy and Nikita Glukhi made it possible to bring all the described to life. Many thanks for being great team players and for their great contribution to the project.
Also, Dima Shekhovtsov deserves special thanks for the idea, direction, and technical guidance!
Project background
Well, our team’s job on this project was to reconsider the B2C platform for a game company. They had an outdated landing, as well as mobile apps that users didn’t really want to use. We were on a global mission to understand the current project situation, and then — bring value.
The client had no insights in terms of the website load, performance, storage allocation, etc. And you can easily guess what we found once we peeked under the hood (it was a pile of legacy code there). At this point, we understood that something new, quick, and easy to manage needs to be built instead. That’s how Scully came into play.
What is Scully and how to deploy‍
JAMstack stands for JavaScript, APIs, and Markup. In this kind of architecture, JavaScript runs entirely on the client-side and handles any dynamic programming. Reusable APIs cover all the server-side processes, and Markup is a markup (a site generator or Webpack), and it needs to be pre-built.
Scully generates static sites for Angular, those with no backend code, so no API call is needed to get the data from the server. Instead, we put all the content on our pages as data and text and make it available to end-users. This Scully Tutorial tells you all you need to know for smooth deployment.
Now Lighthouse score reaches 100
We use Lighthouse, an open-source tool for checking and improving the quality of web pages in this project. You can run it through any webpage for performance, accessibility, SEO, and other audits. On completion, you get a report with suggestions for improvements, and all that is left is bringing those to life :-)
The Lighthouse score represents the results from performance metrics that the tool gathered based on real website performance data. We considered the score to evaluate the website's general performance: whether and how Scully changed the picture. And I can tell that once we switched to Scully, the platform’s Lighthouse score grew from 56 to 99–100. This indicator includes performance, accessibility, SEO, and application of best practices, as you can see from the screen below.
Better Google indexation — how to spot the company in the top
If we remember the basics of the Google search logic, then the crawling stage comes first, to discover publicly available web pages and connected links, and bring this data back to the Google server. Then indexing, when Google tries to understand what the website is about in terms of content, images, video, etc., to categorize the object and put it “on the right shelf” in a huge Google index storage. Finally, we have serving and ranking, when in response to a user’s query Google goes through its index, searching for the most appropriate and quality answer.
Angular applications are rendered at runtime, so it takes Google bots longer to recognize the content since they have to execute JS code first. And Scully helps us pre-render each route’s HTML content. It generates a static version of each website page and eases the mission for bots to see the content. That’s exactly what helped us improve the platform indexing and visibility.
Learn more about boosting SEO with the help of Scully from this Academind article about SEO optimization in Angular apps.
Making the overall CSS footprint smaller with Tailwind
To remove CSS that we don’t need when building for production, we used Tailwind CSS. This CSS framework in the first place lets you easily style your website or app. And what’s more important in our case, it helped us to get rid of unused styles and optimize builds’ size.
As creators claim, when removing unused styles with Tailwind, you never end up with more than 10kb of compressed CSS. Learn more about the framework and its worth from the Optimizing for Production material by Tailwind.
User growth and stronger involvement
Firstly, our release of an Alpha version of the platform tuned by Scully drew users to the product. By product, I mean in-app traits for gamers like a range of different cosmetics, including skins and pets. Scully brought us more visitors and buyers among those who already played the game and knew about the platform.
Another part of the audience came because of better SEO optimization. Optimized content made the platform visible and helped new users find the website. You can see the situation before and after from the screen below (please, don’t mind the red area, it shows the moment of deployment when we couldn’t track the users’ activity).
As a result, from the moment we released the new platform version, sales grew twice.
Integration of Google eCommerce Marketing
The eCommerce part of Google Analytics is what you definitely want to apply to gather insights on user behavior and preferences. You can also understand who makes up your core audience if that’s what you lack, and then — build more efficient marketing campaigns. eCommerce gives you access to your audience’s gender, age, geographical location. The only thing you should take care of to obtain needed data is tags. You’ve got to manage them right when setting up analytics. The following links will help you tune your tags for enhanced eCommerce:
dataLayer.push with examples
A Guide to Google Analytics User ID in Google Tag Manager
Set Up Ecommerce Tracking with Google Tag Manager: Full Guidegle-tag-manager/
Enhanced eCommerce Guide for Google Tag Manager‍
We integrated Google eCommerce tracking and provided our clients with the data they needed for planning future website and mobile apps upgrades. One of the most important things that we started to track is the checkout process — from the moment when the product falls into the basket through filling in the form for online payment to the actual purchase. Clients could realize what may stop a user from a purchase, what stands in the way of accomplishing the checkout. Now they have a data-driven basis for targeting bigger goals in the future.
Bridging Google Analytics’ tags and your Scully platform
Earlier we added a complete JavaScript tracking-code snippet into the HTML to our platform (just like described in this PPCexpo material). But when we switched to Scully and went on connecting Google Analytics to the Scully website, a conflict between Google Tag Manager and HTTPS packages arose. So, we created a plugin to pre-build this connection for Scully to add the piece of code for Google Analytics without any modifications:
import { registerPlugin, getMyConfig } from '@scullyio/scully';
export const GoogleAnalytics = 'googleAnalytics';
export const googleAnalyticsPlugin = async (html: string): Promise => {
const googleAnalyticsConfig = getMyConfig(googleAnalyticsPlugin);
if (!googleAnalyticsConfig || !googleAnalyticsConfig['globalSiteTag']) {
throw new Error('googleAnalytics plugin missing Global Site Tag');
}
const siteTag: string = googleAnalyticsConfig['globalSiteTag']; // your gtmTagId
const googleAnalyticsScript = `
// your GA script code here
`;
return html.replace(/<\/head/i, `${googleAnalyticsScript}};
const validator = async () => [];
registerPlugin('postProcessByHtml', GoogleAnalytics, googleAnalyticsPlugin, validator);
Use this instruction for implementing Google Tag Manager on your website. That’s where you get the following piece of code from:
And this article tells how to get your Google Tag Manager ID.
Here’s where you should place the plugin
The Scully config file is generated automatically when we connect Scully to our Angular app. It is located in the root folder with package.json. Of course, we get a default Scully config, and then we should customize it for our project. This Guide to custom Scully plugins gives good advice for customizing plugins to your needs.
Summary
This switch to JAMstack and Scully gave us a tremendous amount of benefits, even those both we and the client didn’t expect to get. For example, it was a surprise that we’ll have better Google indexing.
From my point of view, the main gain for this project (just like for most of them) is transparency. With such a clear structure and interaction between frontend and backend, you know exactly what’s happening on your Scully website. And when you know, you can react, and actually handle complexities that arise.
Sure, there’s still much work to do, but we have bright perspectives. We plan to deepen tracking of eCommerce indicators, since this will give the client more ground for new business turns. Also, we’ll be working on mobile apps to increase users’ engagement even more!
Here I shared our first experience and thus impressions from the technology. Hopefully, you’ll find the story useful. Please, don’t hesitate to share your feedback, give advice, or contact Valor Software to give your business a boost!‍
Useful links
‍
‍1. Scully Tutorial
2. Optimizing for Production material by Tailwind
3. Academind article about SEO optimization in Angular apps
4. Enhanced eCommerce Guide for Google Tag Manager
5. Guide to custom Scully plugins

Stories by Valor Software on Medium

Nx, Next.js, and Module Federation

The author

Micro Frontends

Nx and monorepos

Pros

Cons

Next.js

Nx + Next.js

Module Federation

Next.js + Module Federation

About the project

Starting the project

Generating new pages

Generating new applications

Running in the development environment

Generating new components

Installing nextjs-mf

Welcome to Store!

Creating hooks

Welcome to Custom Hook!

Deploying projects on Vercel

Private dependencies with Vercel

Debugging NgRx in NativeScript with Redux DevTools

Intro

Table of Contents:

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

Caveats

Useful Links

Implementing WebSockets plugin for NativeScript using React Native

JS empowerment with native platform APIs

WebSocket plugin for NativeScript

Implementation

Not to compete, but evolve and excel

Useful links

Diving into seeking issue with MP3 files

Playing stops before the end of the track

Seeking within MP3

Solution time!

TagTide library: make your HTML editor-friendly and more

Intro

Table of contents:

The principles of HTML code prettifying

What issues this messiness brings:

Steps to editor-friendly text

Technical approaches

My solution — the TagTide library

Use cases

Change some content in 2nd nesting level

Aggregate numeric values from different nesting levels

Strip some tags

Start after or Start from

Flatten

Remove attributes

Root paragraphs

An example of Google Docs content cleanup

In conclusion, I want to thank:

Useful links

Performance Testing via Artillery.io

Why Artillery?

1. Node.js tool

2. Broad language support

3. YAML format

4. Accessible scenarios

5. Easy integration

6. Detailed reports

7. Artillery Docs

How does Artillery.io work?

Install

Fast test

Config

Phases in the config

Plugins

Scenario

Authentication

Final thoughts

Useful Links