DEV Community: Zaki Mohammed

ISRO React App — Working on Component — Part 2

Zaki Mohammed — Thu, 03 Aug 2023 18:37:59 +0000

ISRO React App — Working on Component — Part 2

The time has brought us to talk about the components of ISRO React App. In this article we will continue to talk about the remnants of the app. How the services been created, what are the components present to show the listing of ISRO API data.

If you haven’t read the previous article regarding the initial setup of the app, then this is very good time to check it out before beginning with this one. The part 1 has the details about initial setup of ISRO React App you can check it out from here ISRO React App — Initial Setup — Part 1. Let us construct components and services for the amazing ISRO-API.

We will head in this direction:

Creating Axios Services
Configuring Routes
Designing List Component
Designing Search Component

Creating Axios Services

Without further ado, let us create services those will make actual calls to the ISRO-API for the data. We will create methods for each of the GET endpoints.

For this we have created a services folder, inside of it a “core.service.ts” will hold up the Axios configuration code and a generic GET method to get the API response.

// services/core.service.ts

import axios from 'axios';
import { urlIsro } from '../constants/core.constant';

const axiosInstance = axios.create({
  baseURL: urlIsro.base,
});

const get = async <T>(url: string): Promise<T> => {
  const response = await axiosInstance.get(url);
  if (response.status === 200) {
    return response.data as T;
  } else {
    throw new Error(`[${response.status}]: ${response.statusText}`);
  }
};

const service = {
  get,
};

export default service;

Here, the axiosInstance configures the baseURL of the ISRO-API. Later, a generic get method takes URL and return supplied typed response. Consider this file to have your wrapper methods for the API calls in future for POST, PUT, DELETE sort of operations.

On the basis of this we have app.service.ts file that holds up the ISRO-API endpoint calls.

// services/app.service.ts

import { urlIsro, urlRestCountries } from '../constants/core.constant';
import { Country } from '../models/Country';
import { CentreDto, CustomerSatelliteDto, LauncherDto, SpacecraftDto } from '../models/Dto';
import core from './core.service';

const getSpacecrafts = async () => {
  return await core.get(urlIsro.spacecrafts);
};

const getLaunchers = async () => {
  return await core.get(urlIsro.launchers);
};

const getCustomerSatellites = async () => {
  return await core.get(urlIsro.customerSatellites);
};

const getCentres = async () => {
  return await core.get(urlIsro.centres);
};

const getCountries = async () => {
  return await core.get(`${urlRestCountries.base}${urlRestCountries.all}`);
};

const service = {
  getSpacecrafts,
  getLaunchers,
  getCustomerSatellites,
  getCentres,
  getCountries,
};

export default service;

Here, we are using the core service get method to make the calls based on the endpoints. Note that we have also created a constant file to hold up the app level constants values. We are exposing these method to be consumed by the components.

Configuring Routes

Now, create bunch of routed components, club them into a folder name “pages”.

pages
|-- About.tsx
|-- Centre.tsx
|-- CustomerSatellite.tsx
|-- Home.tsx
|-- Launcher.tsx
|-- Spacecraft.tsx

<Routes>
  <Route path='/' element={<Home />} />
  <Route path='/spacecrafts' element={<Spacecraft />} />
  <Route path='/launchers' element={<Launcher />} />
  <Route path='/customer-satellites' element={<CustomerSatellite />} />
  <Route path='/centers' element={<Centre />} />
  <Route path='/about' element={<About />} />
  <Route path='*' element={<Navigate to={'/'} />} />
</Routes>

Here, we are configuring the routes with corresponding components.

This app is hosted at Netlify so for making React Router to work without 404 on direct path hits, we need to add a file named “_redirects” to public folder. The content of this fill will be like this:

/* /index.html 200

Designing List Component

The components Spacecraft, Launcher, CustomerSatellite and Centre does more or less the same thing with only UI differences. We will take one of such components (Spacecraft) and understand how its implemented, rest components are following the same pattern.

The Spacecraft components shows the data from the spacecraft endpoint of the ISRO-API. Let us break down the Spacecraft component.

The initial setup of Spacecraft components looks like this:

// pages/Spacecraft.ts

import Container from '../components/Container';
import PageTitle from '../components/PageTitle';

const Spacecraft = () => {
  return (
    <Container>
      <PageTitle title="Spacecraft" icon={'rocket'} />
    </Container>
  );
};

export default Spacecraft;

Here, we have created a Container component for wrapping within TailwindCSS container classes. There is a PageTitle component too that shows the page title and icon related to the page.

Let us add the dispatch and selector hooks:

// pages/Spacecraft.ts

...
import { useAppDispatch, useAppSelector } from '../hooks';
import {
  selectSpacecraftsFiltered,
  selectSearchValue,
} from '../reducers/SpacecraftReducers';

const Spacecraft = () => {
  const filtered = useAppSelector(selectSpacecraftsFiltered);
  const searchValue = useAppSelector(selectSearchValue);
  const dispatch = useAppDispatch();

  ...

  return (...);
};

export default Spacecraft;

Here, we have added the hooks for selector and dispatch those we have created in the part 1 (previous article). Using these hooks we are creating the selectors namely filtered and searchValue constants and dispatch a method using which we will invoke the actions.

Let us call the ISRO-API to get the data on the page load, for this we will be needing useEffect() hook:

// pages/Spacecraft.ts

...
import { useEffect } from 'react';
import appService from '../services/app.service';

const Spacecraft = () => {
  ...

  useEffect(() => {
    const getAll = async () => {
      try {
        const data = await appService.getSpacecrafts();
        console.log(data);
      } catch (error) {
        console.log('Error Occurred', error);
      }
    };

    getAll();
  }, []);

  return (...);
};

export default Spacecraft;

Here, we are making an network call to ISRO-API spacecraft endpoint. The data will be logged to console.

Let us dispatch the actions now based on the sequence of operations:

// pages/Spacecraft.ts

...
import { useEffect } from 'react';
import appService from '../services/app.service';
import { setLoading } from '../reducers/AppReducers';
import {
  getAll as getSpacecrafts,
} from '../reducers/SpacecraftReducers';

const Spacecraft = () => {
  ...

  useEffect(() => {
    const getAll = async () => {
      try {
        dispatch(setLoading(true));
        const data = await appService.getSpacecrafts();
        dispatch(getSpacecrafts(data.spacecrafts));
      } catch (error) {
        console.log('Error Occurred', error);
      } finally {
        dispatch(setLoading(false));
      }
    };

    if (filtered === null) {
      getAll();
    }
  }, []);

  return (...);
};

export default Spacecraft;

Here, we have dispatched the corresponding actions like setLoading and getSpacecrafts as per the need. Also, notice that we are calling getAll() method within useEffect() hook only when the filtered is null, otherwise the data is already present and not need to call the API.

Let us now work on the listing of the spacecraft data in a tabular format:

// pages/Spacecraft.ts

...
import Container from '../components/Container';
import PageTitle from '../components/PageTitle';
import NoRecords from '../components/NoRecords';
import Icon from '../components/Icon';

const Spacecraft = () => {
  ...

  return (
    <Container>
      <PageTitle title="Spacecraft" icon={'rocket'} />

      {filtered && (
        <div className="overflow-x-auto">
          <table className="table table-zebra">
            <thead>
              <tr>
                <th className="w-1">#</th>
                <th>Name</th>
              </tr>
            </thead>
            <tbody>
              {filtered.map(item => (
                <tr key={item.id}>
                  <td>{item.id}</td>
                  <td>
                    <div className="flex items-center space-x-3">
                      <div className="text-4xl">
                        <Icon icon="rocket" classes="w-10" />
                      </div>
                      <div>
                        <div className="font-bold">{item.name}</div>
                        <div className="text-sm opacity-50">Spacecraft</div>
                      </div>
                    </div>
                  </td>
                </tr>
              ))}
            </tbody>
          </table>
        </div>
      )}

      <NoRecords filtered={filtered} />

    </Container>
  );
};

export default Spacecraft;

Here, we created a responsive table using TailwindCSS and DaisyUI. Nothing fancy here, just using our Icon component to create the rocket icon. At the very end we have our NoRecords component that shows no entry if data is not found after doing a search. Notice that we are using the “filtered” selector constant for iterating the rows.

Let us put the last piece of the puzzle, the Search component.

Designing Search Component

We have created a Search component that will do the searching within the given list irrespective of where its been used. It will work on the supplied data. First we will see its application and usage in our list component of Spacecraft.

// pages/Spacecraft.ts

...
import Container from '../components/Container';
import PageTitle from '../components/PageTitle';
import {
  clearSearch,
  search,
  selectSearchValue,
} from '../reducers/SpacecraftReducers';
import Search from '../components/Search';

const Spacecraft = () => {
  ...
  const searchValue = useAppSelector(selectSearchValue);

  return (
    <Container>
      <PageTitle title="Spacecraft" icon={'rocket'} />

      <Search
        placeholder="Search spacecrafts..."
        value={searchValue}
        search={search}
        clearSearch={clearSearch}
      />

      ...

    </Container>
  );
};

export default Spacecraft;

Here, we have added the Search component that takes 4 inputs, first the placeholder text that will be displayed to the user. Second the search value, this value is provided by one of the selectors named selectSearchValue; the reason to provide the selector’s value is to keep it updated through store and not from local value, so when user traverse back and forth between pages the search value will still be persisted providing great user experience. We then providing the search and clearSearch actions to the Search component; so it will dispatch these actions when user does some UI operations (like entering search text or clicking on clear button).

Now, let us look into the inside of Search component:

// components/Search.tsx

import { ChangeEvent } from 'react';
import { useAppDispatch } from '../hooks';
import { SearchModel } from '../models/Search';
import iconCancel from './../assets/icons/cancel.png';

const Search = ({ placeholder, value, search, clearSearch }: SearchModel) => {
  const dispatch = useAppDispatch();

  const onSearch = (event: ChangeEvent<HTMLInputElement>) => {
    const value = event.target.value?.toLowerCase();
    if (!value) {
      dispatch(clearSearch());
      return;
    }

    dispatch(search(value));
  };

  const onClearSearch = () => {
    dispatch(clearSearch());
  };

  return (
    <>
      <div className="flex mb-5">
        <input
          type="text"
          placeholder={placeholder}
          className="input input-bordered w-full"
          onChange={onSearch}
          value={value || ''}
        />
        <button className="btn btn-light ms-3" onClick={onClearSearch}>
          <img src={iconCancel} alt="" className="w-4 inline m-0" />
        </button>
      </div>
    </>
  );
};

export default Search;

Here, we are getting these 4 props and using them appropriately.

placeholder: Used inside the input’s placeholder attribute.

value: Assigned to the value attribute of the input control (if the value is not truthy then its kept empty).

search: The search action method is invoked within the onSearch event handler method only if the search text is provided.

clearSearch: The clearSearch action method is invoked when user clicks on the clear button or user clears out the search text from the input control.

Rest of the UI components are simple and self-explanatory like Icon, Container, PageTitle, etc. those are built using TailwindCSS and DaisyUI. Another worth to mention item is the usage of another API for the country flags that is REST Countries. This API is used in the Customer Satellite page where the ISRO deployed the satellites of different countries into the space. To show the flags of these countries we are using the REST Countries API.

Git Repository

Check out the git repository for this project or download the code.

Application

Download Code

Git Repository

Summary

The ISRO React App will surely help the developer out there to understand concepts like React TypeScript, Redux Toolkit, Axios, Routing etc. The amazing ISRO-API is simple and self-explanatory, which actually allow us to consume it and build simple apps and working on our UI skills. Again, giving a shout out to the ISRO-API team to bringing such an amazing API to the world.

Hope this article helps.

Originally published at https://codeomelet.com.

ISRO React App — Initial Setup — Part 1

Zaki Mohammed — Wed, 02 Aug 2023 13:54:41 +0000

ISRO React App — Initial Setup — Part 1

Hats off to amazing ISRO team to their ongoing space missions. There is an amazing ISRO API available to use for the folks who admire ISRO and their contributions. In this article we will talk about the app created using React that consumes the ISRO API endpoints. The React ISRO App is also based on Vite, Typescript, Redux, TailwindCSS, DaisyUI and some other cool techs. The app will help to explore the ISRO API along with the React UI ecosystem.

Through this app, we extend our heartfelt gratitude to the brilliant minds at ISRO for their invaluable contributions, elevating India’s presence in space research. The ISRO API has 4 endpoints namely Spacecraft, Launcher, Customer Satellite and Centre. These endpoints can be found here ISRO-API along with the GitHub Repository. All of these APIs are GET returning data in the form of array.

Thanks to the devs (@isroadmin, @Pramod-Devireddy and many more) behind the ISRO-API, those have contributed to have such an API for the devs out there. This will surely help to learn and grow new skills and techs.

Respecting the time taken to develop this app, this topic will be divided in to 2 parts. The first part will talk about the initial project setup and dependency installation while the part 2 will talk about the app development and component creation. Let us get started with the application development.

We will head in this direction:

Project Structure
Create Project
Add Dependencies
Create Models
Redux Toolkit Setup

Project Structure

Just to showcase the final project structure before we begin with developing from scratch.

src
|-- assets
| |-- react.svg
|-- components
| |-- Container.tsx
| |-- Footer.tsx
| |-- Header.tsx
| |-- Navbar.tsx
| |-- NoRecords.tsx
| |-- PageTitle.tsx
| |-- Search.tsx
| |-- Spinner.tsx
|-- constants
| |-- core.constant.ts
|-- models
| |-- Centre.ts
| |-- Container.ts
| |-- Country.ts
| |-- CustomerSatellite.ts
| |-- Dto.ts
| |-- Launcher.ts
| |-- Search.ts
| |-- Spacecraft.ts
| |-- States.ts
|-- pages
| |-- About.tsx
| |-- Centre.tsx
| |-- CustomerSatellite.tsx
| |-- Home.tsx
| |-- Launcher.tsx
| |-- Spacecraft.tsx
|-- reducers
| |-- AppReducers.ts
| |-- CentreReducers.ts
| |-- CustomerSatelliteReducers.ts
| |-- LauncherReducers.ts
| |-- SpacecraftReducers.ts
|-- services
| |-- app.service.ts
| |-- core.service.ts
|-- App.tsx
|-- hooks.ts
|-- index.css
|-- main.tsx
|-- store.ts
|-- vite-env.d.ts

Create Project

Now, let us get started with creating project.

Make sure you have Node.js installed and Vite available globally. Checkout about Vite, also checkout this tutorial about Vite For TypeScript.

npm create vite@latest

> Give your project a name: react-isro-app
> Select React + TypeScript option

cd react-isro-app
npm i
npm run dev

Add Dependencies

The ISRO app is built using many different packages and dependencies, let us explore few of the important ones.

TailwindCSS

Working with TailwindCSS for the very first time seems little bit scary, but don’t worry I have also overcome my fears by facing them and any one can simply do the same. Nothing fancy here, pretty usual steps to add TailwindCSS to your React + Vite app, you can check the steps out in more detail from here.

Install TailwindCSS:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

Open “tailwind.config.js” and update with below code:

/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Then add these dependencies to your “index.css” file:

@tailwind base;
@tailwind components;
@tailwind utilities;

Daisy UI

I loved the DaisyUI components, they are beautiful and mesmerizing. Checkout them from here.

Install daisyUI:

npm i -D daisyui@latest

Then add daisyUI to your “tailwind.config.js” files:

module.exports = {
  //...
  plugins: [require("daisyui")],
  daisyui: {
    themes: ["light", "dark", "cupcake"],
  },
}

TailwindCSS Typography

There is a sperate plugin for Typography in TailwindCSS that you have to install separately. Checkout TailwindCSS Typography from here.

Install “@tailwindcss/typography”:

npm install -D @tailwindcss/typography

Then add daisyUI to your “tailwind.config.js” files:

module.exports = {
  //...
  plugins: [require('@tailwindcss/typography'), require("daisyui")],
  //...
}

RTK

When some says Redux then think about rituals and ceremonies you have to perform. Checkout Redux Toolkit from here.

Install Redux Toolkit:

npm i @reduxjs/toolkit
npm i react-redux

npm i @types/react-redux -D

Make sure you install the “@types/react-redux” as dev dependencies to get the TypeScript support.

Create Models

Models, entities, data structures set the basis for any apps. If these are created in a correct fashion, then your app guarantees to grow and scale easily. Let us focus on creating the necessary models.

Create ISRO-API models:

export interface Spacecraft {
  id: number;
  name: string;
}

export interface Launcher {
  id: string;
}

export interface CustomerSatellite {
  id: string;
  country: string;
  launch_date: string;
  mass: string;
  launcher: string;
  flag: string;
}

export interface Centre {
  id: number;
  name: string;
  Place: string;
  State: string;
}

Create corresponding DTOs:

// models/dto.ts

import { Centre } from './Centre';
import { CustomerSatellite } from './CustomerSatellite';
import { Launcher } from './Launcher';
import { Spacecraft } from './Spacecraft';

export interface LauncherDto {
  launchers: Launcher[];
}

export interface CentreDto {
  centres: Centre[];
}

export interface CustomerSatelliteDto {
  customer_satellites: CustomerSatellite[];
}

export interface SpacecraftDto {
  spacecrafts: Spacecraft[];
}

Here, you can see a pattern in the properties. The first property will hold the data obtained from ISRO-API, the “filtered” property will hold the filtered data based on the search input. Last property is the search value that holds the value of the search text box. Let us do the RTK setup for overall project.

Redux Toolkit Setup

For setting up RTK one has to follow these steps:

Configure Store
Register Store
Initialize States, Reducers and Selectors
Register Reducer

Configure Store

Create a file named “store.ts” and First configure the store:

// store.ts

import { configureStore } from '@reduxjs/toolkit';

export const store = configureStore({
  reducer: {
  },
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Here, reducer is empty for now.

Register Store

// main.tsx

import React from 'react'
import { Provider } from 'react-redux';
import ReactDOM from 'react-dom/client'
import App from './App.tsx'
import './index.css'
import { store } from './store.ts'

ReactDOM.createRoot(document.getElementById('root')!).render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>,
)

The “Provider” comes from “react-redux”.

Initialize States, Reducers and Selectors

Let us do the hard work now, initializing states, reducers and selectors. For this create a folder named “reducers”. We will see this setup for one state called “spacecraft”.

// reducers/SpacecraftReducers.ts

const initialState: SpacecraftState = {
  spacecrafts: null,
  filtered: null,
  searchValue: null,
};

These are the initial values of the spacecraft state.

// reducers/SpacecraftReducers.ts

export const spacecraftSlice = createSlice({
  name: 'spacecraft',
  initialState,
  reducers: {
    getAll: (state, action: PayloadAction<Spacecraft[]>) => {
      state.spacecrafts = action.payload;
      state.filtered = action.payload;
      state.searchValue = null;
    },
    clearSearch: state => {
      state.filtered = state.spacecrafts;
      state.searchValue = null;
    },
    search: (state, action: PayloadAction<string>) => {
      state.searchValue = action.payload;
      state.filtered = state.spacecrafts
        ? state.spacecrafts?.filter(i => i.name.toLowerCase().includes(action.payload))
        : null;
    },
  },
});

Here, we are creating the reducer slices, this will include the definitions of name of the state slice, initial state values, and reducers methods. There are 3 reducers namely getAll, clearSearch and search. The getAll is invoked post obtaining the value from the ISRO-API call and responsible to set all the state values. The clearSearch is to reset the filtered list and search value. The search is called when user performs a search operation resulting in updated filtered array.

// reducers/SpacecraftReducers.ts

export const { getAll, clearSearch, search } = spacecraftSlice.actions;

Export the action methods getAll, clearSearch and search.

// reducers/SpacecraftReducers.ts

export const selectSpacecrafts = (state: RootState) => state.spacecraft.spacecrafts;
export const selectSpacecraftsFiltered = (state: RootState) => state.spacecraft.filtered;
export const selectSearchValue = (state: RootState) => state.spacecraft.searchValue;

Create the selectors for all the 3 states.

// reducers/SpacecraftReducers.ts

export default spacecraftSlice.reducer;

Then, export the reducer as the default export for the file.

Register Reducers

Finally, you can now register this reducer to your store in the “store.ts” file:

// store.ts

import { configureStore } from '@reduxjs/toolkit';
import spacecraftReducers from './reducers/SpacecraftReducers';

export const store = configureStore({
  reducer: {
    spacecraft: spacecraftReducers,
  },
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Here, we are creating a property named spacecraft and assigning it to spacecraftReducers.

Similar to this we will create the other reducers in the same fashion. The final store.ts file will look like this:

// store.ts

import { configureStore } from '@reduxjs/toolkit';
import appReducer from './reducers/AppReducers';
import spacecraftReducers from './reducers/SpacecraftReducers';
import launcherReducers from './reducers/LauncherReducers';
import customerSatelliteReducers from './reducers/CustomerSatelliteReducers';
import centreReducers from './reducers/CentreReducers';

export const store = configureStore({
  reducer: {
    app: appReducer,
    spacecraft: spacecraftReducers,
    launcher: launcherReducers,
    customerSatellite: customerSatelliteReducers,
    centre: centreReducers,
  },
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

This does mark completion of the initial setup of our amazing isro-react-app. We will now move on to work on the app components in the next article.

Git Repository

Check out the git repository for this project or download the code.

Application

Download Code

Git Repository

Summary

Creating spaceship, researching about cosmos actually involves rocket science (like literally — very difficult). The team ISRO is doing wonderful job in the exploration and research area. It was fun and great learning while working on this app and consuming the ISRO-API. Thanks to folks those are behind creating the ISRO-API available for the devs like us to learn and grow. This app will surely help to understand React, Redux, TypeScript concepts and provide a starting point for learning further.

Hope this article helps.

Originally published at https://codeomelet.com.

Angular Performance Improvement

Zaki Mohammed — Fri, 28 Jul 2023 15:34:14 +0000

Gaining performance is not an easy job; a lot of hair loss cases has been reported in order to achieve tiniest bit of improvement in term of app speed.

In this series our focus will be to save those losing hairs by doing what best we can do to speeden up the app. This includes post related to Brotli, Gzip, Caching, API data caching, etc.

Gzip Dockerized Angular App With Nginx — Ngdocker | CodeOmelet

Leveling up by taking performance improvement measures for our super friendly NgDocker app. In this article, we will explore how we can enable Gzip to improve performance at a hulking scale.

2. Nginx Cache Config For Dockerized Angular App — Ngdocker | CodeOmelet

App running so fast, even the cops are chasing! Not breaking any law here just configuring Nginx caching for our Dockerized Angular app. In this article we will address the need for speed for our super silly NgDocker app by setting up the Nginx cache configurations for static files.

3. Cache Angular Http Request Using @Ngneat/Cashew | CodeOmelet

The time of not wasting time on caching HTTP request data has come. Presenting @ngneat/cashew package to do the needfully; it takes our stress of manually creating service variables to hold up the HTTP requests data again and again. In this article we will explore @ngneat/cashew dope package for caching HTTP requests.

4. Brotli Dockerized Angular App With Nginx — Ngdocker | CodeOmelet

Patience is the key to success; not heard or followed by any of the web app visitors. We want everything to be loaded within blink of an eye. This is the place where Brotli shines. In this article, we will explore how we can enable Brotli in the NgDocker app to improve performance at a marvelous scale.

Originally published at https://codeomelet.com.

Brotli Dockerized Angular App with Nginx — NgDocker

Zaki Mohammed — Thu, 20 Jul 2023 10:25:26 +0000

Brotli Dockerized Angular App with Nginx — NgDocker

If you love breads/rolls then you will surely love Brotli (Brotli: it’s a Swiss German word for a bread roll). Brotli is level up compression algorithm, faster than Gzip, widely available, developed by Google under MIT license. So, no valid reason available for not using it. There are some useful articles where we can understand the back story of Brotli compression and why it’s better than Gzip.

You can check these links:

In this article our focus will be to check how we can enable Brotli Compression with Angular, Docker, Nginx kind of setup. We will take the same app from this article Gzip Dockerized Angular App with Nginx — NgDocker and instead of Gzip we will enable Brotli.

We will head in this direction:

Setup Angular App
Create a Dockerfile with Brotli
Enable Brotli in Nginx Configuration
Run Docker Container
Celebrate the Impact of Brotli
Brotli vs Gzip vs No Encoding

Setup Angular App

Similar to NgDocker mark 2, we will do the daily chores of Angular app and as per the need of the hour we are considering v16 of Angular; just for fun we are using Cirrus UI:

ng new ng-docker-mark-4

npm i cirrus-ui

Below shows the skeleton of the project:

ng-docker-mark-4
|-- nginx
| |-- nginx.conf
|-- src
| |-- app
| | |-- core
| | | |-- components
| | | | |-- footer
| | | | |-- header
| | | |-- pages
| | | | |-- home
| | | |-- services
| | | |-- core.service.ts
| | | |-- products.service.ts
| | |-- modules
| | | |-- posts
| | | |-- users
| | |-- app-routing.module.ts
| | |-- app.component.html
| | |-- app.component.ts
| | |-- app.module.ts
|-- angular.json
|-- Dockerfile
|-- package.json

This application respect minimalism and have less number of routes and components. For the sake of understanding how compression affects the lazy loaded modules we have added 2 feature standalone modules Posts and Users. Thanks to Angular v15 these are standalone components routed in a lazy loaded fashion. The data is coming from our beloved JSON Placeholder API.

Below shows the business logic for Posts component, the Users component is also created in the similar manner:

posts.component.html

<div class="section">
  <div class="content">
    <div class="row mb-3" *ngFor="let post of posts$ | async">
      <div class="col-sm-4">
        <img
          class="img-stretch u-round-md"
          [src]="getImage(post)"
          alt="img-stretch"
          height="400"
          (error)="getDefaultImage($event)" />
      </div>
      <div class="col-lg-6 col-md-8">
        <h3>{{ post.title | titlecase }}</h3>
        <p>{{ post.body }}</p>
        <div>
          <span class="icon">
            <i class="far fa-wrapper fa-clock" aria-hidden="true"></i>
          </span>
          {{randomDate | date: 'fullDate'}}
        </div>
      </div>
    </div>
  </div>
</div>

posts.component.ts

posts$?: Observable;

constructor(private coreService: CoreService) {
  this.posts$ = coreService.getPosts();
}

Below shows the post service, the user service is also created in similar manner:

products.service.ts

private url: string = environment.apiUrl;

constructor(private http: HttpClient) {}

get(name: string) {
  const url = `${this.url}${name}`;
  return this.http.get(url);
}

Below shows the routes of the application:

app-routing.module.ts

const routes: Routes = [
  { path: '', component: HomeComponent },
  { path: 'posts', loadComponent: () => import('./modules/posts/posts.component').then(x => x.PostsComponent) },
  { path: 'users', loadComponent: () => import('./modules/users/users.component').then(x => x.UsersComponent) },
  { path: '**', component: HomeComponent },
];

Create Dockerfile with Brotli

After fighting a constant battle with ChatGPT to get the correct answer, I came to final solution that actually works to enable Brotli compression with Dockerized Angular app; thanks to StackOverflow user stwissel ( StackOverflow Question).

Our Dockerfile must be looking like below:

# Build container
FROM node:18-alpine AS builder
WORKDIR /app

# Make sure we got brotli
RUN apk update
RUN apk add --upgrade brotli

# NPM install and build
ADD package.json .
RUN npm install
ADD . .
RUN npm run build:prod

RUN cd /app/dist && find . -type f -exec brotli {} \;

# Actual runtime container
FROM alpine
RUN apk add brotli nginx nginx-mod-http-brotli

# Minimal config
COPY nginx/nginx.conf /etc/nginx/http.d/default.conf

# Actual data
COPY --from=builder /app/dist/ng-docker-mark-4 /usr/share/nginx/html
CMD ["nginx", "-g", "daemon off;"]
EXPOSE 80

Here, most of the thing seems pretty normal and related to default Angular-Docker setup. We will highlight the important steps those are needed for Brotli.

# Make sure we got brotli
RUN apk update
RUN apk add --upgrade brotli

Here, the first line updates the package index inside the container. The second line installs or upgrades the “brotli” compression library inside the container.

RUN cd /app/dist && find . -type f -exec brotli {} \;

Here, the statement “cd /app/dist” changes the working directory to “/app/dist” and the statement “find . -type f -exec brotli {} \;” finds all files in the current directory and its subdirectories (“.”), then applies the “brotli” compression command to each file (“{}”).

# Actual runtime container
FROM alpine
RUN apk add brotli nginx nginx-mod-http-brotli

Here, the first line specifies the base image for the runtime container. In this case, it uses the “alpine” image, which is a lightweight Linux distribution. The second line installs the “brotli” library, “nginx” web server, and the “nginx-mod-http-brotli” module inside the container.

Enable Brotli in Nginx Configuration

The time has come to enable Brotli in Nginx configuration file which we have seen in the previous article for re-writing the route for SPA:

server {
    brotli on;
    brotli_static on;
    brotli_comp_level 6;
    brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    ...
}

That’s it, no need to check or look anywhere else, this much is required for super speeding up your app performance! Also, these settings are self explanatory, the first 2 lines enables the Brotli and Brotli for static files, followed by setting the compression level to 6 that ranges from 0 to 11 (default is 6), then we are mentioning the types for which the Brotli will be enabled (note: no need to compress already compressed images like JPG).

Run Docker Container

For this we require to have Docker Desktop, otherwise we are unworthy to proceed.

Build Docker Image

# build image
docker build -t ng-docker:mark-4 .

Run Docker Container

# run container
docker run -p 3300:80 --name ng-docker-mark-4-container ng-docker:mark-4

Here, you can change to your favorite port, we are going with “3300” for a change. Once, executed then open http://localhost:3300/ to run the application.

Celebrate the Impact of Brotli

Its time for the celebration! Due to drastic improvement in the performance. Here, we will compare the time to load files with and without Brotli through below screen shots:

No Content Encoding (before)

Gzip Enabled (before)

Brotli Enabled (after)

Here, we can clearly see the before and after effect on the file size, the biggest file (main.js) early which was around 265KB turns out to be of 97.7KB of size after enabling the Gzip and then finally it becomes 72.5KB once Brotli is enabled. The snowball effect can clearly be seen in other files too. The “Content-Encoding” header usually doesn’t appear in the browser’s Network tab of Developer Tools, we can add it by simply right clicking on the table of Network tab and go to “Headers” option and then add the “Content-Encoding”.

Similar effect can also be observed with lazy-loaded modules:

Lazy Loaded Module — No Content Encoding (before)

Lazy Loaded Module — Brotli Enabled (after)

Brotli vs Gzip vs No Encoding

It’s time to compare everything with everything. Not holding back any punches and comparing 3 scenarios for the base JavaScript file here that is “main.js”.

Below tables shows the original file size of “main.js” without any content encoding and after encoding using Gzip and Brotli:

File Size (main.js):

None = 265 KB

Gzip (gzip) = 97.7 KB

Brotli (br) = 72.5 KB

Below tables shows the percentage differences between no encoding to Gzip to Brotli for “main.js”:

None => Gzip => = 92.2526% difference

None => Brotli => = 114.074% difference

Gzip => Brotli => = 29.6122% difference

The Brotli compression from None to Brotli is insane around 114% while from None to Gzip is around 92%. The difference between Brotli and Gzip is around 30%.

So, in a toe-to-toe comparison Brotli is clearly winner here. NOTE: We are only comparing based on JavaScript file.

In this article The Difference Between Brotli And Gzip Compression Algorithms To Speed Up Your Site, it is mentioned that the benchmark difference between Gzip and Brotli is as follows:

14% smaller JavaScript files
21% smaller HTML files
17% smaller CSS files

Git Repository

Check out the git repository for this project or download the code.

Download Code

Git Repository

Summary

Add Brotli to your to-do list of performance improvement of your frontend app, you surely will see significance performance improvement in your static files (JS/CSS). CodeOmelet is having Brotli enabled and I have enabled Brotli in many of other Angular/React applications. Brotli is one of the small contributions to your app with such a great impact.

Hope this article helps.

Originally published at https://codeomelet.com.

NgFate — A tool for deciding the fate of an Angular app

Zaki Mohammed — Thu, 06 Jul 2023 19:12:46 +0000

NgFate — A tool for deciding the fate of an Angular app

A tool for salvation and exploration of your beloved Angular app. It is what’s inside that matters; NgFate will provide your app’s inside, app structure, component routes, dependencies and relations. Made by CodeOmelet with love and a bunch of sleepless nights using dotnet csharp. In this article, we will walk you through, what, why and how of NgFate so that you can deep dive inside your Angular app.

When our Angular app grows it brings a lot of modules and components to manage and keep track of. One of the problems which I personally face when I start working on any new Angular app is getting the hold on the structure of the application. It is challenging to understand a project who’s who quickly and it takes a good amount of time. To address this problem once it for all, I thought why not we just create a tool that shows a hierarchy and relation between the modules and components. This tool will tell whether the component is routed or not, where it’s been referred and used, how many components are there in a module etc.

For this I have taken an oath to create a tool that will put a full stop to this suffering and help me and other fellow developers to get a relief. Introducing NgFate tool, built using .NET 6 and C#, providing you bunch of options to view your project structure and hierarchy (JSON, HTML, CLI, etc.).

In this article we will go through below points to explore NgFate:

Download and dotnet Run
Run Application
Limitations
Algorithm and Data Structure
Future Scope

1. Download and dotnet Run

The tool is published to GitHub repository NgFate. Below shows the download and dotnet run steps:

Download the app from the latest Releases section.
Unzip the project in the directory of your choice.
Open terminal.
Go to “publish” folder in the terminal.
C:\Users\zshaikh>cd C:\Users\zshaikh\Downloads\publish
Run the app by using the executable:
C:\Users\zshaikh>ng-fate.exe
Run the app by using the dotnet command:
C:\Users\zshaikh>dotnet ng-fate.dll

2. Run Application

The tool requires bunch of input from you in order to generate the report of your app.

Example:

An example of such input values are shown below:

Project Path: C:\Zaki\Study\Angular\service-desk\service-desk-app
Project Prefix (comma separated): app,jam,van
Select Output Type (1 — JSON, 2 — HTML, 3 — CLI, 4 — ALL): 4
Output Folder Path: C:\Zaki\Study\Angular\service-desk\des

Input Details:

Below gives detailing to these inputs:

Project Path: Path to your Angular project.
Project Prefix (comma separated): Multiple comma separated values can be provided as app prefix (e.g app,jam,van).
Select Output Type (1 — JSON, 2 — HTML, 3 — CLI, 4 — ALL):
1. If you want a .json file as an output select first option.
2. If you want a .html file as an output select second option.
3. If you want output in the terminal it self select third option.
4. If you want all of the above select fourth option.
Output Folder Path: Path to your directory where you want all the output files to be generated.

Below shows recording of the above performed steps:

codeomelet.com/Media/Images/posts/ng-fate-download-run-output.webm

3. Limitations

Currently the NgFate is rookie and have to evolve a lot. For starter the tool is looking for some ideal structuring of the Angular project as per the Angular official document.

Check and verify if your app is adhering to these limitations:

NgFate doesn’t support standalone components yet.
The module and component naming must follow Angular guide.
Each module and component files must ends with the convention *.module.ts and *.component.ts.
Properly formatted declarations of components within @NgModule decorator (either in single line or new line).
Properly formatted routes configurations (path and component properties).
Prefix must be provided while providing the input to NgFate (it is case sensitive).

4. Algorithm and Data Structure

The NgFate is working on below base algorithm right now:

get all ‘.module.ts’ files
get all ‘declarations’ array data from NgModules
decompose fileName based on camelCasing of name
get file path by search fileName in the directory
read ‘*-routing.module.ts’ file and search name of component if existed
get the path name while searching for component in routing file
search for ‘header.component.html’ file in entire project and get the .html parent files
decompose fileName from name

To support the above algorithm below data structure is at core of the tool:

[
  // 1. get all '.module.ts' files
  {
    name: 'AppModule',
    fileName: 'app.module.ts',
    components: [
      // 2. get all 'declarations' array data from NgModules
      {
        name: 'LoginComponent',
        fileName: 'login.component.ts', // 3. decompose fileName based on camelCasing of name
        filePath: 'src/app/pages/login.component.ts', // 4. get file path by search fileName in the directory
        routed: true, // 5. read '*-routing.module.ts' file and search name of component if existed
        routePath: 'login', // 6. get the path name while searching for component in routing file
        parents: [],
      },
      {
        name: 'HeaderComponent',
        fileName: 'header.component.ts',
        filePath: 'src/app/components/header.component.ts',
        routed: false, // 5. read '*-routing.module.ts' file and search name of component if existed
        routePath: null,
        parents: [
          // 7. search for 'header.component.html' file in entire project and get the .html parent files
          {
            name: 'MainComponent',
            fileName: 'main.component.ts', // 8. decompose fileName from name
            filePath: 'src/app/components/main.component.ts', // 4. get file path by search fileName in the directory
          },
        ],
      },
    ],
  },
];

5. Future Scope

For the interstellar travel of NgFate below are some key features considered as a future scope for the tool:

Diagrams:
1. Dependency graph in .html report.
2. Routing graph in .html report.
Pipes and directives considerations.
Version Support: Adhering to the latest releases of Angular.
AI support for speeding up performance.
Fault tolerance and better logging.

Git Repository

Check out the git repository for this project or download the code.

Application

Download Code

Git Repository

Summary

This is just an inception of NgFate, many more releases yet to come to make it with stand with lot of exceptional scenarios; those are highlighted in the future scope. The project is available on GitHub and maintained by CodeOmelet. Looking forward to having more developers to jam in and make this tool more and more mature. Hope this tool help others and bring joy to their life and families.

Hope this article helps.

Originally published at https://codeomelet.com.

Cache Angular HTTP request using @ngneat/cashew

Zaki Mohammed — Thu, 25 May 2023 16:21:50 +0000

In any Angular project we create HTTP services to make API calls GET, POST, etc. to operate on server data. Now, in order to preserve the loaded data, we usually create service variables to hold up the data until user make a reload or login again into the system. For this we have to maintain this variable with our bare hand which kind of repetitive task for each newly created service. Storing the response data like forever is not what we usually get paid for. Here, comes super chill @ngneat/cashew package!

We will head in this direction:

Setup Angular App
Add @ngneat/cashew
Add to HTTP service
Use LocalStorage

Setup Angular App

Let us first do the daily chores of any Angular app and as per the need of the hour we are considering v16 of Angular; just for fun we are using Cirrus UI:

ng new ng-cashew-app

npm i cirrus-ui

Below shows the skeleton of the project:

ng-cashew-app
|-- src
| |-- app
| | |-- core
| | | |-- components
| | | | |-- footer
| | | | |-- header
| | | |-- pages
| | | | |-- home
| | | |-- services
| | | |-- core.service.ts
| | |-- modules
| | | |-- posts
| | | |-- users
| | |-- app-routing.module.ts
| | |-- app.component.html
| | |-- app.component.ts
| | |-- app.module.ts
|-- angular.json
|-- package.json

This application respect minimalism and have less number of routes and components. For the sake of understanding how compression affects the lazy loaded modules we have added 2 feature standalone modules Posts and Users. Thanks to Angular v16 these are standalone components routed in a lazy loaded fashion. The data is coming from our beloved JSON Placeholder API.

Below shows the business logic for Posts component, the Users component is also created in the similar manner:

posts.component.html

<div class="section">
  <div class="content">
    <div class="row mb-3" *ngFor="let post of posts$ | async">
      <div class="col-sm-4">
        <img
          class="img-stretch u-round-md"
          [src]="getImage(post)"
          alt="img-stretch"
          height="400"
          (error)="getDefaultImage($event)" />
      </div>
      <div class="col-lg-6 col-md-8">
        <h3>{{ post.title | titlecase }}</h3>
        <p>{{ post.body }}</p>
        <div>
          <span class="icon">
            <i class="far fa-wrapper fa-clock" aria-hidden="true"></i>
          </span>
          {{randomDate | date: 'fullDate'}}
        </div>
      </div>
    </div>
  </div>
</div>

posts.component.ts

posts$?: Observable;

constructor(private coreService: CoreService) {
  this.posts$ = coreService.getPosts();
}

core.service.ts

private url: string = environment.apiUrl;
private postUrl: string = 'posts';
private userUrl: string = 'users';

constructor(private http: HttpClient) {}

getPosts() {
  const url = `${this.url}${this.postUrl}?userId=1`;
  return this.http.get(url);
}

getUsers() {
  const url = `${this.url}${this.userUrl}`;
  return this.http.get(url);
}

app-routing.module.ts

const routes: Routes = [
  { path: '', component: HomeComponent },
  { path: 'posts', loadComponent: () => import('./modules/posts/posts.component').then(x => x.PostsComponent) },
  { path: 'users', loadComponent: () => import('./modules/users/users.component').then(x => x.UsersComponent) },
  { path: '**', component: HomeComponent },
];

Done with the chores!

Add @ngneat/cashew

Now, let us install @ngneat/cashew package:

npm i @ngneat/cashew

Adding cashew to app module:

app.module.ts

...
import { HttpCacheInterceptorModule } from '@ngneat/cashew';

@NgModule({
  declarations: [...],
  imports: [
    ...
    HttpCacheInterceptorModule.forRoot(), 
  ],
  providers: [],
  bootstrap: [...],
})
export class AppModule {}

Add to HTTP service

Time to add the cashew config to the HTTP options:

core.service.ts

import { withCache } from '@ngneat/cashew';
...

private options = {
  context: withCache()
};

getPosts() {
  const url = `${this.url}${this.postUrl}?userId=1`;
  return this.http.get(url, this.options);
}

getUsers() {
  const url = `${this.url}${this.userUrl}`;
  return this.http.get(url, this.options);
}

Here, the options object holds the context property which is coming from the withCache() method of cashew package. We have added this object as second parameter in the HTTP’s get method for post and users endpoints.

Just simply adding withCache() method gives your service methods wings of cache. If you check the network tab you will only find a single call being made to the endpoint, and if you revisit the pages after navigating to some other route, you won’t find any calls to the server.

Use LocalStorage

Another question your senior dev in your team will ask is, what about if I refresh the page, will it persist the data in cache? You simply need to assure them that, we need to configure @ngneat/cashew to use localStorage instead of run time memory. This is as simple as eating an omelet (omelet reference!).

We need to add “useHttpCacheLocalStorage” to the providers of app module:

app.module.ts

...
import { HttpCacheInterceptorModule, useHttpCacheLocalStorage } from '@ngneat/cashew';

@NgModule({
  declarations: [...],
  imports: [...],
  providers: [useHttpCacheLocalStorage],
  bootstrap: [...],
})
export class AppModule {}

Last thing is adding version and key to the “withCache” method’s object:

core.service.ts

...

private options = {
  context: withCache({
      version: 'v1',
      key: 'omelet'
    })
};

...

Done! Thats it, now we can see the localStorage for this change. Just go to either “posts” or “users” route and check the “Application” tab of developer too and go to “Local Storage”. You will see something like this in your local storage.

Additionally, we can set the “ttl” (in milliseconds) for this, by default it is for 1 hour. The version is a trick to start using a new local storage as a cache to disband the old cache.

private options = {
  context: withCache({
      version: 'v1',
      key: 'omelet',
      ttl: 3000
    })
};

Git Repository

Check out the git repository for this project or download the code.

Application

Download Code

Git Repository

Summary

Caching is developer’s love and if it can happen in frontend too with this much of little effort, it’s a salvation! You can clearly feel that how a fan boy I am for this package. This actually given us good grades in our performance audits. You can simply consider @ngneat/cashew as a plug and plaything. It also has some hackable areas, worth giving a try, providing full blown customization. Consider this a performance boosting thing for your next or current app.

Hope this article helps.

Originally published at https://codeomelet.com.

Nginx Cache Config for Dockerized Angular App — NgDocker

Zaki Mohammed — Wed, 17 May 2023 14:08:54 +0000

Nginx Cache Config for Dockerized Angular App — NgDocker

We are on a spiritual journey of performance improvement for a Dockereized Angular app. In continuation of the previous article Gzip Dockerized Angular App with Nginx — NgDocker where we have already enabled the Gzip and seen a significant performance boost for the static files; we will use the same app for this article too and add the cache control header to the static files by configuring this setting in Nginx config.

We will head in this direction:

Cache Control Header
Add Cache Control in Nginx Configuration
Investigating the Cache Control

Cache Control Header

The Cache Control is a response header, that can be set from the server side; it tells the browser whether the file needs to be cached or not. As per the MDN documentation for the Cache-Control, we need to add the cache control header to the respective files. Once this header is present the browser then simply caches the files till the expiry provided in the header. For this we need to provide the value “max-age=31449600” to the cache control header. Here, the max-age value is set in seconds; so “31449600” is approximately 365 days, roughly a year. Through the same cache control header, we can even tell the browser to not cache some of the file by setting the value for cache control to “no-cache”. We will be needing this control to decide whether to cache or not cache some of the files as per our app needs.

Add Cache Control in Nginx Configuration

The time has come to add the majestic cache configuration to the Nginx config file “nginx/nginx.conf”. Consider these settings can be used for any other SPA application too like React, Vue, etc. We will add different configuration for different static files:

Index File (index.html)
JavaScript and CSS Files (.js/.css)
Image Files (.jpg, .png, .svg, etc.)

1. Index File (index.html)

We never cache the index.html file otherwise it will never provide the updated application results when we deploy a new build. So for “index.html” it is must to not cache and always fetched from the server.

server {
    ...
    location ~ /index.html {
        add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
    }
    ...
}

This will ensure to disable the caching for index.html by the browser. Read more about these directives here: Cache-Control Directives.

2. JavaScript and CSS Files (.js/.css)

Cache JS/CSS for a year since every new build will have its own build UUID the JS/CSS files in a newer build will never be the same. So, till the time there is no new build deployed the JS/CSS files once fetched on client-side will never be fetched again until a new build is deployed.

server {
    ...
    location ~ .*\.css$|.*\.js$ {
        add_header Cache-Control 'max-age=31449600'; # one year
    }
    ...
}

3. Image Files (.jpg, .png, .svg, etc.)

The image files we are talking here are mostly from the “assets” folder. These images are mainly related to the UI and App, example: icons, background, avatar, etc. These images are static images for client-side, those can be cached for one month without any problem. This can differ application to application, set as per your app needs and requirement. For this article we are setting it up to one month.

server {
    ...
    location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
        expires 1M; # one month
    }
    ...
}

We can even use “expires” value too in Nginx for location directive.

Investigating the Cache

After building the Docker image and running the Docker container let us investigate if the things are aligning or not as per our expectations. We will use Firefox as it shows the transferred file source correctly as compared to Chrome; from where it has been served, from server or browser cache. For this we will first hard-reload (Ctrl + F5) the app and observe the Developer Tool’s Network tab; then we will reload (F5) the app and again observe the Network tab to see the source of the transferred file either server or cache.

Docker: Build and Run

docker build -t ng-docker:mark-3 
docker run -p 3300:80 --name ng-docker-mark-3-container-1 ng-docker:mark-3

Initial Load or Hard-Reload (Ctrl + F5)

Here, the “Transferred” column shows the size of the transferred file, indicating the file has been transferred from server and not coming from browser cache.

Reload (F5)

Here, the “Transferred” column shows the “cached”, indicating the file has been served from browser cache.

If we look it more closely, we can see that the cache control header is appearing as Response Header once we clicked on the file.

Index File

As expected the “index.html” file is appearing as “no-cache” header value.

JavaScript Files

As expected the “.js” files are appearing as “max-age” header value.

Checkout the entire nginx.conf file below.

nginx/nginx.conf

server {
    gzip on;
    gzip_static on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_proxied no-cache no-store private expired auth;
    gzip_min_length 1000;

    listen 80;

    root /usr/share/nginx/html;

    location ~ /index.html {
        add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0'; # no cache
    }

    location ~ .*\.css$|.*\.js$ {
        add_header Cache-Control 'max-age=31449600'; # one year
    }

    location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
        expires 1M; # one month
    }

    location / {
        index index.html index.htm;
        try_files $uri $uri/ /index.html;
    }

    error_page 500 502 503 504 /50x.html;

    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

Git Repository

Check out the git repository for this project or download the code.

Download Code

Git Repository

Summary

Caching is some default feature that is available by default with HTTP standard. We simply need to press some keys on the keyboard to get this properly configured for our SPA application. We can introduce as many flavors to it as we want to depend upon our app requirements. Nginx syntax is really simple and straight forward. So, without much hassle we can enable some pre-built functionality that will help the loading speed. Although this won’t be helping on your initial load but surely relives the subsequent requests. The performance improvement battle is never ending, stay tuned!

Hope this article helps.

Originally published at https://codeomelet.com.

Gzip Dockerized Angular App with Nginx — NgDocker

Zaki Mohammed — Sat, 08 Apr 2023 09:17:28 +0000

Gzip Dockerized Angular App with Nginx — NgDocker

Leveling up by taking performance improvement measures for our super friendly NgDocker app. In this article, we will explore how we can enable Gzip to improve performance at a hulking scale.

This article is sort of continuation of the previous article Dockerized Angular App with Nginx — NgDocker with some added features and modules. The idea is to enable the Gzip compression at Nginx configuration in order to make application loading blazingly fast. The Gzip compression is must for any SPA/API developed on server in order to reduce the data transmission up to 80%. It is important to understand how to enable and control the configurations related to Gzip to make any SPA based application stand out. For this we are creating an Angular application on the same base line of NgDocker app, this will be Mark 2 of NgDocker app.

We will head in this direction:

Setup Angular App
Enable Gzip in Nginx Configuration
Run Docker Container
Celebrate the Impact of Gzip
Analyzing the Bundle — Web Pack Bundle Analyzer

Setup Angular App

Let us first do the daily chores of any Angular app and as per the need of the hour we are considering v15 of Angular; just for fun we are using Cirrus UI:

ng new ng-docker-mark-2

npm i cirrus-ui

Below shows the skeleton of the project:

ng-docker-mark-2
|-- nginx
| |-- nginx.conf
|-- src
| |-- app
| | |-- core
| | | |-- components
| | | | |-- footer
| | | | |-- header
| | | |-- pages
| | | | |-- home
| | | |-- services
| | | |-- core.service.ts
| | | |-- products.service.ts
| | |-- modules
| | | |-- posts
| | | |-- users
| | |-- app-routing.module.ts
| | |-- app.component.html
| | |-- app.component.ts
| | |-- app.module.ts
|-- angular.json
|-- Dockerfile
|-- package.json

Below shows the business logic for Posts component, the Users component is also created in the similar manner:

posts.component.html

<div class="section">
  <div class="content">
    <div class="row mb-3" *ngFor="let post of posts$ | async">
      <div class="col-sm-4">
        <img
          class="img-stretch u-round-md"
          [src]="getImage(post)"
          alt="img-stretch"
          height="400"
          (error)="getDefaultImage($event)" />
      </div>
      <div class="col-lg-6 col-md-8">
        <h3>{{ post.title | titlecase }}</h3>
        <p>{{ post.body }}</p>
        <div>
          <span class="icon">
            <i class="far fa-wrapper fa-clock" aria-hidden="true"></i>
          </span>
          {{randomDate | date: 'fullDate'}}
        </div>
      </div>
    </div>
  </div>
</div>

posts.component.ts

posts$?: Observable;

constructor(private coreService: CoreService) {
  this.posts$ = coreService.getPosts();
}

Below shows the post service, the user service is also created in similar manner:

products.service.ts

private url: string = environment.apiUrl;

constructor(private http: HttpClient) {}

get(name: string) {
  const url = `${this.url}${name}`;
  return this.http.get(url);
}

Below shows the routes of the application:

app-routing.module.ts

const routes: Routes = [
  { path: '', component: HomeComponent },
  { path: 'posts', loadComponent: () => import('./modules/posts/posts.component').then(x => x.PostsComponent) },
  { path: 'users', loadComponent: () => import('./modules/users/users.component').then(x => x.UsersComponent) },
  { path: '**', component: HomeComponent },
];

Enable Gzip in Nginx Configuration

The time has come to enable Gzip in Nginx configuration file which we have seen in the previous article for re-writing the route for SPA:

server {
    gzip on;
    gzip_static on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_proxied no-cache no-store private expired auth;
    gzip_min_length 1000;
    ...
}

That’s it, no need to check or look anywhere else, this much is required for speeding up your app performance! Also, these settings are self explanatory, the first 2 lines enables the Gzip and Gzip for static files, followed by mentioning of types for which the Gzip will be enabled (note: no need to compress already compressed images like JPG), then we are keeping the gzip_proxied to the default setting and then finally setting the min length for Gzip consideration, right now we have gone with 1000 means 1KB, files below 1KB won’t be compressed then, we can make it 256 too optionally to consider even smaller than 1KB file.

Run Docker Container

For this we require to have Docker Desktop, otherwise we are unworthy to proceed.

Build Docker Image

# build image
docker build -t ng-docker:mark-2 .

Run Docker Container

# run container
docker run -p 3300:80 --name ng-docker-mark-2-container-1 ng-docker:mark-2

Here, you can change to your favorite port, we are going with “3300” for a change. Once, executed then open http://localhost:3300/ to run the application.

Celebrate the Impact of Gzip

Its time for the celebration! Due to drastic improvement in the performance. Here, we will compare the time to load files with and without Gzip through below screen shots:

Gzip Disabled (before)

Gzip Enabled (after)

Here, we can clearly see the before and after effect on the file size, the biggest file (main.js) early which was around 256KB turns out to be of 95.5KB of size after enabling the Gzip. The snowball effect can clearly be seen in other files too. The “Content-Encoding” header usually doesn’t appear in the browser’s Network tab of Developer Tools, we can add it by simply right clicking on the table of Network tab and go to “Headers” option and then add the “Content-Encoding”.

Similar effect can also be observed with lazy-loaded modules:

Lazy Loaded Module — Gzip Disabled (before)

Lazy Loaded Module — Gzip Enabled (after)

Analyzing the Bundle — Web Pack Bundle Analyzer

We can analyze our modules and bundle size in a more better way with the help of Web Pack Bundle Analyzer. This package helps to provide a breakdown of the entire Angular project and the size of the bundle in Stats, Parsed and Gzipped state. The Stats is the default build without production, the Parsed is the production build with minified JS and CSS and finally the Gzipped state is the production build with Gzip enabled. This will give a very clear and early picture of your project, how much it has grown, which modules are heavier, how to keep main.js minimal as much as we can. With the decision making becomes very easy peasy.

We first have to install the Web Pack Bundle Analyzer, make sure to add it as Dev Dependency, since it just a tool to analyze the project bundle:

npm i webpack-bundle-analyzer -D

Add scripts to package.json file:

"scripts": {
  "build:prod-stats": "ng build --configuration production --stats-json",
  "analyze": "npm run build:prod-stats && webpack-bundle-analyzer dist/ng-docker-mark-2/stats.json",
}

Here, we are adding one new “build:prod-stats” production build command with “stats-json” flag, this will create “stats.json” file once the build is completed. This file is then used by the next command of Web Pack Bundle Analyzer. The script “analyze” clubbed the build stats and analyzer commands.

Run Web Pack Bundle Analyzer:

npm run analyze

This will open a web page to show the project bundle graph as follows:

Here, we can see the entire project and its module and the feature modules with their respective sizes. If you notice the left side bar it shows the 3 states that we have discussed earlier.

This will open a web page to show the project bundle graph as follows:

Here, we can see the 3 states, and finally the Gzipped version of the JS files. If we notice the sizes its not fully accurate what we finally got on the application while running it, like the main.js Parsed is 254KB and while the actual is 256KB and the Gzipped is 78.53KB while we got 95.5KB; so, its not pixel perfect but at least on a closer proximity.

Git Repository

Check out the git repository for this project or download the code.

Download Code

Git Repository

Summary

Performance is a pain in project development if not considered prior. Some of the performance are handled direct at the configuration levels rather than code and business logic; Gzip is one of the configuration level change that brings performance we crave for in our application. If you are having SPA which doesn’t have Gzip enabled then it’s a huge loss on performance, and people will judge us, as someone form Dark Age. The configuration for Gzip is dead simple and can be tested and verified easily (bye-bye QA).

Another, hidden gem which we have disclosed in this article is the Web Pack Bundle Analyzer. This dude helps us to monitor our project growth and bulky areas of project upfront and allow us to take prior actions before thing gets out of hand. So that being said, enable Gzip in your app and we will see more future articles on the same line, stay tuned!

Hope this article helps.

Originally published at https://codeomelet.com.

Dockerized Angular App with Nginx — NgDocker

Zaki Mohammed — Sun, 26 Mar 2023 18:49:17 +0000

Dockerized Angular App with Nginx — NgDocker

Meet super friendly NgDocker app, made with love and care using Angular and Cirrus UI, garnished with Docker and Nginx. In this article, we will explore how to make and bake a Dockerized Angular App with Nginx without much hassle.

If we already know about wonders Docker brings to the table then we are good to go ahead with the article, but if we have any doubt related to Docker (what, why and how) then the pre-requisite here is to know the background details of Docker. Here, we will talk about how to setup a minimalist Dockerized Angular application along with Nginx configurations. The idea is to keep it dead simple and explore what things are needed to make Angular App as Dockerized. Enough said lets get started with the code already!

We will head in this direction:

Setup Angular App
Add Production Build Command
Setup Docker and Nginx
Build Docker Image and Run Docker Container

Setup Angular App

Let us first do the daily chores of any Angular app and as per the need of the hour we are considering v15 of Angular; just for fun we are using Cirrus UI:

ng new ng-docker-mark-1

npm i cirrus-ui

As already mentioned we will do bare minimum with the Angular project:

app.component.html

<section class="section">
  <div class="hero fullscreen bg-gray-100">
    <div class="hero-body">
      <div class="content">
        <div class="row">
          <div class="col text-center">
            <h1>?? Hello <span class="text-red-700">Ng</span><span class="text-blue-500">Docker</span>!</h1>
            <h6 class="font-alt font-light">
              A webpage powered by
              <b>
                <i class="fab fa-angular text-red-700"></i> Angular + <i class="fab fa-docker text-blue-500"></i> Docker
                + <i class="fas fa-cloud text-pink-600"></i> Cirrus.
              </b>
            </h6>
            <div class="tag-container group-tags group-tags--rounded mt-2">
              <div class="tag tag--dark">Mark</div>
              <div class="tag tag--info">1.0.0</div>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</section>

Add Production Build Command

Adding the build command for production in “package.json” file

package.json

{
  "scripts": {
    "build:prod": "ng build --configuration production",
  },
}

Setup Docker and Nginx

Before we address the Docker whale in the project, we first create Nginx configuration file, later this configuration file will overrides the default Nginx configuration. Create a folder for this file named “nginx” and create a file named “nginx.conf” inside that folder.

nginx/nginx.conf

server {
    listen 80;

    root /usr/share/nginx/html;

    location / {
        index index.html index.htm;
        try_files $uri $uri/ /index.html;
    }

    error_page 500 502 503 504 /50x.html;

    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

Through this file we declare the re-write rule for the SPA application. The line “try_files $uri $uri/ /index.html;” makes the route to always be redirected to the “index.html”, since the SPA serves everything through the index page only. This file is very important to setup security headers, implement caching, enabling Gzip etc. Basically, this file is same as “web.config” file of ASP.NET project.

The time has come to create our own “Dockerfile” and surprisingly the name of the file is itself “Dockerfile”. Create this file on your root of Angular project directory.

Dockerfile

FROM node:latest as build-env
WORKDIR /app

ADD package.json .

RUN npm install

ADD . .

RUN npm run build:prod

FROM nginx:alpine

COPY --from=build-env /app/dist/ng-docker-mark-1 /usr/share/nginx/html
COPY nginx/nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 8080

Here, when I first seen this file, I got little nervous, like what kind of Egyptian literature is this. But seems pretty simple to digest and get along with, let me break it down. This can be simply broken down into 2 major steps:

Step 1: Installing Dependencies and Building Project

FROM node:latest as build-env

This tells that the image will be for Node project, since most of the SPA are NPM and Node dependent, this line acknowledges the same.

WORKDIR /app

Here, we are naming our working directory as “/app”.

ADD package.json .

Now, we are first adding only the “package.json” file to the “/app” directory using ADD command, this is to reduce the adding cost, and if the install command fails it fails early without adding the entire project.

RUN npm install

Now, we are installing the NPM packages based on the configured “package.json” file with the help of RUN command.

Once the package installation is succeeded and after doing yay! we then add all of the project files to the working directory “/app”.

RUN npm run build:prod

Post that we run the build prod command, the same command which we have added to “package.json” script.

Step 2: Setup Nginx and Nginx Configuration

COPY --from=build-env /app/dist/ng-docker-mark-1 /usr/share/nginx/html

Here, we copy the built Angular project to Nginx HTML directory. This makes the project ready to be accessed.

COPY nginx/nginx.conf /etc/nginx/conf.d/default.conf

Now, we will override the default Nginx configuration to the configuration that we have created in our Angular project “nginx/nginx.conf”.

EXPOSE 8080

Finally, exposing it to the default port 8080.

Build Docker Image and Run Docker Container

We can take further steps if we have installed Docker Desktop already, otherwise we are unworthy to proceed.

Build Docker Image

# build image
docker build -t ng-docker:mark-1 .

Once, executed then check in the image list:

# list images
docker image ls

Run Docker Container

# run container
docker run -p 3300:80 --name ng-docker-container-1 ng-docker:mark-1

Here, you can change to your favorite port, we are going with “3300” for a change. Once, executed then open http://localhost:3300/ to run the application.

Here, have some additional commands if failed in between; to stop and remove the existing container to create another one with same name.

# stop container
docker stop ng-docker-container-1

# remove container
docker rm ng-docker-container-1

Git Repository

Check out the git repository for this project or download the code.

Application

Download Code

Git Repository

Summary

Doing bare minimum from Angular front but exploring the Docker and Nginx was a good experience overall. Dockerized apps are trending for many obvious reasons and understanding them is what today’s demand. This majorly helps in deployment, setting up CI/CD, configuring different environments. After few initial hiccups one can gain control over Docker and Nginx configurations and provide necessary support to the actual Angular project. We will see more future articles on the same line, stay tuned!

Hope this article helps.

Originally published at https://codeomelet.com.

JEST Started with Unit Testing

Zaki Mohammed — Sun, 19 Mar 2023 19:37:27 +0000

Either you are in a deep love with unit testing or hating it to the core, but the bottom line is to do it anyway. So just like many things in our life, let us deal with it; in this article we will start exploring the realm of unit testing along with JEST.

If you ask me what I think about unit testing in general, then I would say it’s another kind of drug that is available in the market. Don’t get me wrong, nothing negative here; but at first you hate it and cry in the initial phases. You don’t, and never want to judge your own code; because your code is super awesome and will never going to break. As a developer we are no different, we share the same initial thought process in our early phases of our coding journey. But a mature developer knows he/she is human after all, and definitely going to make mistakes; but rather than denying it accept and learn from our mistakes. Unit testing comes from that learning and realization only. So, in order to make our code robust and reliable we need to make it go through some harsh and soft test cases that helps to prove worthiness of written code. Enough of prep talk! Now if we are all on boarded to explore some ABCD of unit testing will start with the super popular JEST unit testing framework.

JEST is a delightful JavaScript unit test framework, which is quite popular among the dev squad. In this article our goal will be to get started with JEST and understand the ecosystem and write a dumb unit test case that actually runs. So, if you are already familiar with JEST then this article might not be a right fit for you since you are already a meta! But surely it will make you feel nostalgic. Without further ado will get our hands dirty.

We will gonna use Node.js for running our JavaScript code and of course pre-requisite will be Node.js to be avail in your system.

Setup and Dependencies

Create a fresh directory and initialize using NPM initialize command:

mkdir jest-started
cd jest-started

npm init

After providing necessary detailing to your package.json file its time to add JEST dependencies:

npm i jest -D 
npm i @types/jest -D

Make sure to install them as dev-dependencies -D, since unit testing is something for dev and not for production. Otherwise, it will increase the bundle size of your project at the time of production.

Add Test Command

For starter we are just adding one command to at least run our test case in the script property of package.json file. Later, we will explore some more version of the below command:

package.json

"scripts": {
  "test": "jest"
},

Write Code

Let’s be very gentle and write super simple program that a school student can write and understand:

index.js

const sum = (num1, num2) => num1 + num2;

module.exports = {
  sum,
};

Write Unit Test Case

Its time to write a test case/spec for the sum function, for this create a file with same name “index.test.js” but ends with test.

index.test,js

const { sum } = require('./index');

// test suite
describe('Index', () => {
  // test spec
  it('should add two numbers', () => {
    // arrange
    const expected = 30;

    // act
    const received = sum(10, 20);

    // assert
    expect(received).toBe(expected);
  });
});

Here, we are writing a test suite using the describe() and a test spec using it() methods of JEST. Inside of the it() method, just like any other test case we are doing some arraignment of data, acting upon the code and finally doing an assert operation on our expectation using expect() method of JEST, followed by a matcher function toBe() to prove our expectation.

Congratulations! You have written your first JavaScript unit test case code without dropping a single sweat or blood. Keeping the code this much only let us now explore the surroundings.

Run Test Command

Now its time for the actual show down, run your unit test with the beautiful npm script:

npm test

> jest-started@1.0.0 test
> jest

 PASS ./index.test.js
  Index
    v should add two numbers (2 ms)

Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 0.511 s, estimated 1 s
Ran all test suites.

Here, it runs your test for your index.test.js file and provide you the passed/fail status. It shows the total passed test suits and specs. You can try to tweak the code by making the expected value to be different, this will show result as below:

npm test

> jest-started@1.0.0 test
> jest

 FAIL ./index.test.js
  Index
    × should add two numbers (3 ms)

  ? Index › should add two numbers

    expect(received).toBe(expected) // Object.is equality

    Expected: 40
    Received: 30

      12 |
      13 | // assert
    > 14 | expect(received).toBe(expected);
         | ^
      15 | });
      16 | });
      17 |

      at Object.toBe (index.test.js:14:22)

Test Suites: 1 failed, 1 total
Tests: 1 failed, 1 total
Snapshots: 0 total
Time: 0.68 s, estimated 1 s
Ran all test suites.

Here, clearly mentions what it was expected and what actually received along with the line number it failed.

Add More Test Commands

JEST has a couple of options that come along with the default JEST command. These options allow us to make a command that suites our project needs and requirements. Let us create some new custom commands inside package.json file using these options:

package.json

"scripts": {
  "test": "jest",
  "test-watch": "jest --watchAll",
  "test-verbose": "jest --verbose",
  "test-coverage": "jest --coverage",
  "test-fat": "jest --watchAll --verbose --coverage"
},

Here, we have added a command called “test-watch” with option named “ — watchAll”, this will make the jest runs in the background to continuously watch your folder for any change in your test/spec files and runs the result. This one is pretty handy if you are doing continuous changes. The second command provides detailing to individual test specs even if you have multiple test files, otherwise the default command just shows the pass/fail status of each file. The coverage command generates a coverage report the get displayed on the console and also creates an entire HTML report ( Istanbul Coverage) that helps to explore all of the test cases present inside a folder at project level. The last and final command is just for fun to have all of these options combined together. Explore more such CLI options.

Coverage Report

A coverage report provides you an overall picture of unit test case coverage project/folder wide. This helps to determine missed statements, lines, branches and functions. By default, 80% or above coverage is a green.

npm run test-coverage

> jest-started@1.0.0 test-coverage
> jest --coverage

 PASS ./index.test.js
  Index
    v should add two numbers (1 ms)

---------------|------------|----------------|---------------|------------|-------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
---------------|------------|----------------|---------------|------------|-------------------
All files | 100 | 100 | 100 | 100 |                   
 index.js | 100 | 100 | 100 | 100 |                   
---------------|------------|-----------------|---------------|------------|-------------------
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 0.84 s
Ran all test suites.

Here, the console report shows the files present in the folder, and percentage of the mentioned factors. At the end it shows total number of passed/failed test suites/cases. This even created the Istanbul report, generated at coverage\lcov-report\index.html folder; every time you runs the command it will re-generate the “coverage” folder.

Debug Unit Test

There are couple of tools available for the debugging; but here our focus is on VS Code only; there is this awesome VS Code extension named Jest available using which we can debug the written test cases. Once installed it automatically runs all the test cases, you can add breakpoints and press run/debug button on all or individual test cases to debug the test. Apart from this just to speed up the coding speed of unit test cases we can use Jest Snippets VS Code extension to have short hands for JEST related methods.

Git Repository

Check out the git repository for this project or download the code.

Download Code

Git Repository

Summary

Writing unit test is an art and here we have just started to explore this art form. Moving forward, will deep dive into this topic and explore good amount of unit test case scenarios. Talking about JEST, its super simple, straight forward and interesting framework that keeps things pretty handy to use and instead of feeling like struggling it helps to easy things out. We will learn more on JEST in upcoming articles. Wish me strength on this one!

Hope this article helps.

Originally published at https://codeomelet.com.

Workflow Core DSL for JSON and YAML

Zaki Mohammed — Mon, 13 Mar 2023 19:33:21 +0000

Workflow Core comes with many features one of which is its common DSL for JSON and YAML. In this article, we will explore JSON/YAML way of creating the process workflows.

If you are following along, we have already seen how to get started with Workflow Core with .NET Core (6.0); you can check Workflow Core Getting Started article. In continuation to that, we will understand how to use common DSL (JSON/YAML) provided by Workflow Core and re-create the same example with DSL instead of C# based workflow.

Check out the Workflow Core documentation and also explore the Git Repository, thanks to Daniel Gerlag.

Initial Workflow Core Setup

The initial setup of Workflow Core remains the same as explained in the previous article; except we need to add one more package for DSL:

dotnet add package WorkflowCore.DSL

The remaining steps will remain as is:

Create Steps
Create Workflow
Register and start the Workflow from the main program file

The folder structure too remains the same:

workflow-start
|-- Workflows
    |-- ProcessPayment
        |-- Steps
            |-- ApplyDiscount.cs
            |-- ApplyShipping.cs
            |-- Finalize.cs
            |-- Initialize.cs
        |-- ProcessPaymentWorkflow.cs
        |-- ProcessPaymentWorkflow.json
        |-- ProcessPaymentWorkflow.yml
|-- GlobalUsings.cs
|-- Program.cs
|-- workflow-start.csproj

Here, we have added JSON and YAML files for the workflow. But we need to revisit step 2 since our definition for the workflow will be written in DSL (JSON/YAML).

Define DSL for Workflow

Consider the below workflow that we have created in C# ..\Workflows\ProcessPayment\ProcessPaymentWorkflow.cs

Workflows/ProcessPayment/ProcessPaymentWorkflow.cs

public class ProcessPaymentWorkflow : IWorkflow
{
    public string Id => "ProcessPaymentWorkflow";

    public int Version => 1;

    public void Build(IWorkflowBuilder<object> builder)
    {
        builder
            .UseDefaultErrorBehavior(WorkflowErrorHandling.Suspend)
            .StartWith<Initialize>()
            .Then<ApplyDiscount>()
            .Then<ApplyShipping>()
            .Then<Finalize>();
    }
}

We will comply with this and create the same definition in YAML.

Id: ProcessPaymentWorkflow
Version: 1
Steps:
  - Id: Initialize
    StepType: Initialize, workflow-start-dsl
    NextStepId: ApplyDiscount
  - Id: ApplyDiscount
    StepType: ApplyDiscount, workflow-start-dsl
    NextStepId: ApplyShipping
  - Id: ApplyShipping
    StepType: ApplyShipping, workflow-start-dsl
    NextStepId: Finalize
  - Id: Finalize
    StepType: Finalize, workflow-start-dsl

Let us zoom in to individual step definition:

- Id: Initialize
    StepType: Initialize, workflow-start-dsl
    NextStepId: ApplyDiscount

It includes the Id of the step, this can be given anything within the YML definition file. Then we have StepType which needs to match the step class name as is along with the project assembly name (workflow-start-dsl). Then we have NextStepId which points to the next step within the YML definition file; this must match the Ids given to each step within the YML definition file.

The same goes for JSON files too, even you can use simple YML to JSON conversion if you want to have both of the versions, as shown below:

{
    "Id": "ProcessPaymentWorkflow",
    "Version": 1,
    "Steps": [
        {
            "Id": "Initialize",
            "StepType": "Initialize, workflow-start-dsl",
            "NextStepId": "ApplyDiscount"
        },
        {
            "Id": "ApplyDiscount",
            "StepType": "ApplyDiscount, workflow-start-dsl",
            "NextStepId": "ApplyShipping"
        },
        {
            "Id": "ApplyShipping",
            "StepType": "ApplyShipping, workflow-start-dsl",
            "NextStepId": "Finalize"
        },
        {
            "Id": "Finalize",
            "StepType": "Finalize, workflow-start-dsl"
        }
    ]
}

This is the same except for the ugly curly braces.

Load Definition

For setting up the workflow we have to do the below steps in Program.cs file:

Add the Workflow DSL service after the Workflow server in the ServiceCollection object.

var serviceProvider = new ServiceCollection()
    .AddLogging()
    .AddWorkflow()
    .AddWorkflowDSL()
    .BuildServiceProvider();

Create a load definition method to load the workflow definition from DSL file:

static void LoadDefinition(IServiceProvider serviceProvider)
{
    var type = Deserializers.Yaml;
    var file = File.ReadAllText($"Workflows/ProcessPayment/ProcessPaymentWorkflow.{(type == Deserializers.Yaml ? "yml" : "json")}");

    var loader = serviceProvider.GetService();
    if (loader == null)
        throw new Exception("Loader not initialized");

    loader.LoadDefinition(file, type);
}

Call the LoadDefinition method instead of calling the RegisterWorkflow method of the host object:

var host = serviceProvider.GetService();
if (host == null)
    throw new Exception("Host not initialized");

LoadDefinition(serviceProvider);

host.Start();

host.StartWorkflow("ProcessPaymentWorkflow");

Console.ReadLine();

host.Stop();

Now, when you run the project it will simply print these steps console text on you console window:

dotnet run
Initialize
ApplyDiscount
ApplyShipping
Finalize

We will continue to explore some of the other Workflow Core features in upcoming posts. Stay tuned!

Git Repository

Check out the git repository for this project or download the code.

Download Code

Git Repository

Summary

The Workflow Core’s common DSL provides a way to express your process workflow one step closer to the business understanding. Mainly YAML is considered a language of configuration and widely accepted by business analysts, automation, and DevOps professionals. This allows for defining workflows that can be easily used by both the hard-core developers and business bodies. One of the vital asks from any Workflow Core engine is to have a common language construct and Workflow Core provides it.

Hope this article helps.

Originally published at https://codeomelet.com.

The Art of Destructuring in JavaScript

Zaki Mohammed — Tue, 07 Mar 2023 18:49:45 +0000

Poses the power of destructuring and conquers the world of JavaScript. Like literally, since it’s been available to devs, it is the coolest thing ever after the dark theme. To be relevant in the JavaScript gang, one has to understand the art of destructuring in JavaScript; in this article, we will adapt to the destructuring swag.

Ask any beginner who has just started their coding journey, what kind of nightmare they have; out of many, one will be the concept of destructuring in JavaScript. But the same fella after understanding what it is will start bragging about it within their JavaScript circle. Happens to most of us, the point is why it’s been so popular nowadays and why we need to know it. The answer is the way it is handling some of the very tedious tasks we have to deal with objects and arrays in JavaScript. It offers lots of solutions and cases where it can help out in a way that a normal coding style would have cost us a lot.

Let us directly jump into coding and take notes from there on what and how it is doing. For this we will consider 2 scenarios shown as follows:

Destructuring Arrays
Destructuring Objects

Destructuring Arrays

Arrays are awesome until you have to use the indexes to access the elements. Working with array indexes uglify your code and make it difficult for others to read and understand quickly. For this destructuring plays a vital role; we will cover the following array-based scenarios:

Basic One
Skipping Values
Index Position Values
Default Values
Swapping Values
Returning Values From Function
Passing Values To Function
With Rest Parameter
With Spread Operator

Basic One

const wizard = ['Harry', 'Potter']

const [firstName, lastName] = wizard

console.log(firstName, lastName) // Harry Potter

The wizard array is holding the name of the wizard (first and last name). In order to take the first name and last name individually, we need to use array indexes 0 and 1 respectively. That would be an ugly way to talk, but here we are giving names to the variable instead of talking in terms of indexes.

Skipping Values

const wizard = ['Harry', 'James', 'Potter']

const [firstName, , lastName] = wizard

console.log(firstName, lastName) // Harry Potter

Here, we wanna skip the middle name which is appearing at the 1st index location; this can be done just by skipping the variable name after firstName and moving to the 2nd index location’s variable name which is lastName.

Index Position Values

const developer = ['Rajneesh', 'Mithilesh', 'Chaubey']

const { [1]: middleName } = developer

console.log(middleName) // Mithilesh

We can even pick values from the specific index location of an array as shown above. The square brackets contain the index followed by a colon and the name of the variable. Thanks to ma friend Rajneesh Chaubey for helping me to add this one (#respect).

Default Values

const address = ['Pittsburgh', 'Pennsylvania']

const [city, state, country = 'US'] = address

console.log(city, state, country) // Pittsburgh Pennsylvania US

Here, we are making the default value of the country variable to US, since our address array don’t have any country by default the country will be US.

Swapping Values

let a = 10, b = 20;

console.log(a, b); // 10 20

[a, b] = [b, a]

console.log(a, b) // 20 10

Swapping is fun with destructuring; what magically happens here is that the variable a and b are simply re-initialized with each other’s existing values.

Returning Values From Function

const getLocation = () => [18.97474, 72.82712]

const [lat, lng] = getLocation()

console.log(lat, lng) // 18.97474 72.82712

Nothing fancy here, a function is simply returning an array (latitude and longitude values), and then we are destructuring it for our own good.

Passing Values To Function

const setLocation = ([lat, lng]) => console.log('Stored:', lat, lng)

const location = [18.97474, 72.82712]

setLocation(location) // Stored: 18.97474 72.82712

Here, a function named setLocation is accepting an array, but instead of naming the array we are destructuring it and creating variables from it inside the parameter tray itself. This looks pretty hardcore!

With Rest Parameter

const languages = ['JavaScript', 'Node.js', 'C#', 'Java', 'C']

const [lang1, lang2, ...others] = languages

console.log(lang1, lang2, others)

This one is a throwback from Rest Parameter article which we had covered already. Here, we are having a language array from which we are grabbing the first 2 values while keeping the rest as is within an array named others. For the “others” arrays, we are using the rest parameter’s three dots within our destructuring operation.

With Spread Operator

const marks = [[54, 65, 93], [48, 58, 39], [85, 95, 73]]

const [[...marks1], marks2] = marks

console.log(marks[0] === marks1) // false
console.log(marks[1] === marks2) // true

Here, we are having a marks array that has different sub-array storing marks data. We are destructuring first 2 arrays and also creating new reference of the first array using spread operator. We can confirm a new reference is created using the compare operator as shown. So the marks[0] is not same as marks1 array while marks[1] is same as marks2 array. Refer Spread Operator article for spread operator.

Destructuring Objects

Objects are the coolest in JavaScript, often with some buffy projects we receive tons of properties associated with them; then things get messy and difficult to manage, and required us to create new objects out of the main object every now and then. If it happens once or twice we can bare, but in the real-life scenario, such occurrences are a lot many. For this destructuring plays a vital role; we will cover the following object-based scenarios:

Basic One
Property Alias
Default Values
Nested Objects
Nested-Nested Objects
Nested Arrays
Nested Destructed Arrays
Returning Objects From Function
Passing Objects To Function
With Rest Parameter
With Spread Operator

Basic One

const person = { id: 1, name: 'John Doe', age: 21 }

const { name } = person

console.log(name) // John Doe

Sweet! broken the person object and got only the name property out of it.

Property Alias

const person = { id: 1, name: 'John Doe', age: 21 }

const { name: personName } = person

console.log(personName) // John Doe

Same as previous with the only difference is that we can have a new alias name instead of the actual property for the variable; for example, we have given the “name” property an alias that is “personName”. This is useful in cases where we already have an existing variable name with the same property name.

Default Values

const person = { id: 1, name: 'John Doe', age: 21 }

const { name, age, salary = 0 } = person

console.log(name, age, salary) // John Doe 21 0

This feature allows us to provide a default value to the newly destructured variable. For example, we are giving a default value of zero to the salary variable, but since we don’t have a salary property within the object it will create one for us. But if it already existed then the object’s property value would be considered.

Nested Objects

const address = {
    id: 1,
    street: 'Kulas Light',
    city: 'Gwenborough',
    zipcode: '92998-3874',
    geo: {
        lat: -37.3159,
        lng: 81.1496
    }
}

const { city, geo: { lat, lng } } = address

console.log(city, lat, lng)

We are having a geo location object within our address object, but destructing allows us to further destructure the nested object as shown above.

Nested-Nested Objects

const employee = {
    id: 1,
    name: 'Allen Green',
    job: 'Clerk',
    department: {
        id: 1,
        name: 'Accounts',
        geo: {
            lat: -54.4241,
            lng: 32.8973
        }
    }
}

const { name, department: { geo: { lat, lng } } } = employee

console.log(name, lat, lng)

Complicating it even further, we can go on with it at any level of nesting without hesitating. Here, we are getting the latitude and longitude variables out of the nested object geo within the nested object department.

Nested Arrays

const post = {
    id: 1,
    title: 'Voluptate occaecat',
    body: 'Elit eu ullamco sit elit magna id incididunt culpa.',
    comments: [
        {
            id: 1,
            body: 'Incididunt elit magna ipsum adipisicing nisi eu.'
        },
        {
            id: 2,
            body: 'Et voluptate occaecat esse esse nisi eu ullamco duis nisi sint aliquip.'
        },
        {
            id: 3,
            body: 'Deserunt ullamco aliquip veniam quis duis sunt.'
        },
    ]
}

const { title, comments } = post

console.log(title, comments)

It works pretty normally with an array; here, “comments” is an array that can also be destructured out from the post object.

Nested Destructed Arrays

const post = {
    id: 1,
    title: 'Voluptate occaecat',
    body: 'Elit eu ullamco sit elit magna id incididunt culpa.',
    comments: [
        {
            id: 1,
            body: 'Incididunt elit magna ipsum adipisicing nisi eu.'
        },
        {
            id: 2,
            body: 'Et voluptate occaecat esse esse nisi eu ullamco duis nisi sint aliquip.'
        },
        {
            id: 3,
            body: 'Deserunt ullamco aliquip veniam quis duis sunt.'
        },
    ]
}

const { title, comments: [comment1, comment2] } = post

console.log(title, comment1.body, comment2.body)

Here, we are destructuring arrays while we are destructuring the object. We are creating 2 variables from the array “comments” comment1 and comment2 while we are destructuring the post object.

Returning Objects From Function

const getProduct = () => ({
    id: 1,
    name: 'Wildcraft Bag',
    price: 1200,
    color: 'Red'
})

const { id, price, color } = getProduct()

console.log(id, price, color)

Nothing to flex here, simply an object is returned from a function named getProduct() and we are destructuring it.

Passing Objects To Function

const setProduct = ({ id, name, price, color }) => console.log('Stored:', id, name, price, color)

const product = {
    id: 1,
    name: 'Woodland Shoes',
    price: 3000,
    color: 'Brown'
}

setProduct(product)

Now, this is different! Here, we are breaking out the object which is supplied to the setProduct() function within the function’s parameter tray. This one looks cool and most of the framework uses this way, like in React we can see this in the component’s props. The setProduct() function is accepting all the values of the product object except the id property (actually in real-world scenarios id is mostly auto-generated by the backend).

With Rest Parameter

const employee = {
    id: 1,
    name: 'Allen Green',
    job: 'Clerk',
    salary: 1200
}

const { id, name, ...others } = employee

console.log(id, name, others) // 1 Allen Green { job: 'Clerk', salary: 1200 }

The formula of rest parameter can also be applied to object destructuring. Here, we are taking out only id and name properties while leaving all the remaining properties to “others” objects. For further reading refer Rest Parameter.

With Spread Operator

const employee = {
    id: 1,
    name: 'Allen Green',
    job: 'Clerk',
    salary: 1200,
    department: {
        id: 1,
        name: 'Accounts'
    }
}

const { name, department: { ...department } } = employee

console.log(employee.department === department) // false

Here, we are using the spread operator to create department object but with a new reference while we are destructuring the employee object. It actually worked and we can compare the references, it will result as false. For further reading refer Spread Operator.

Git Repository

Check out the git repository for this project or download the code.

Download Code

Git Repository

Summary

If not the rest parameter or spread operator scared me initially, but destructuring had definitely. It is worth studying since day by day the dependency on JavaScript is increasing and we need to overcome ES6 hurdles. Most of the recent JS frameworks are using it within their coding syntax it is difficult to understand it along with the framework, so it is good to separate what are default JS features and what are framework-specific features.

Hope this article helps.

Originally published at https://codeomelet.com.