This might also be interesting for you: Adding Swagger to Node Server

Step 1: Setting Up NestJS Vercel hosting

First things first, getting the basic setup to deploy on Vercel. Vercel is awesome for serverless, but working with NestJS needed a few tweaks. The main thing is to set up a vercel.json configuration file, which tells Vercel exactly how to handle your app.

Here’s the configuration I ended up with:

{
  "version": 2,
  "builds": [
    {
      "src": "src/main.ts",
      "use": "@vercel/node"
    }
  ],
  "routes": [
    {
      "src": "/(.*)",
      "dest": "src/main.ts",
      "methods": [
        "GET",
        "POST",
        "PUT",
        "PATCH",
        "OPTIONS",
        "DELETE",
        "HEAD",
        "CONNECT",
        "TRACE"
      ]
    }
  ]
}

I deployed it to Vercel and got the following error:

This Serverless Function has crashed. Your connection is working correctly. 
Vercel is working correctly. 500: INTERNAL_SERVER_ERROR 
Code: FUNCTION_INVOCATION_FAILED ID: bom1::sgk4v-1711014022883-1e9ed54f4c37

Looking in the logs, I noticed the database connection was an issue and in addition got the following log message:

No exports found in module "/var/task/app-name/src/main.js".
Did you forget to export a function or a server?

Turned out I could ignore the second part of the error message and just focus on the database connection.

Step 2: Configuring the Database

For my app, I used a mysql database with multiple schemas. I tried several free offers, but they were not compatible with the multiple schemas approach. Therefore I ended up with hosting it on Google Cloud. I scaled it down to a price of 0.01$ per hour and used the 300$ newbie offer.

Allowing Vercel to connect required setting the IP to 0.0.0.0/0 in Google Cloud’s configuration, making the database accessible from any IP address. Important note: make sure you test locally before deploying to Vercel, or you’ll be dealing with errors like these:

Step 3: Dealing with CORS

CORS caused also some headaches. Make sure you allow OPTIONS for CORS preflight requests, as Vercel needed explicit permission for cross-origin requests. I ended up adding a lot of headers to make sure requests were allowed:

app.enableCors({
    origin: 'domain-name',
    credentials: true,
    methods: 'GET,HEAD,PUT,PATCH,POST,DELETE,OPTIONS',
    allowedHeaders: [
      'Origin',
      'X-Requested-With',
      'Content-Type',
      'Accept',
      'Authorization',
    ],
  });

Step 4: Switching to express-session and Redis for Session Management

One of the trickiest parts was getting sessions to work. I started with the cookie-session library, but Vercel completely ignore it. After digging into the docs and some trial and error, I switched to express-session, which is more popular and works nicer with Vercel’s serverless environment.

For some reason the import syntax has to be exactly like this:

import session = require('express-session');

I also had to configure the session middleware with trust proxy enabled, since Vercel proxies requests. Here’s what the final setup looked like:

const expressApp = app.getHttpAdapter().getInstance();
expressApp.set('trust proxy', true);

Also setting secure: true and sameSite: 'none' was essential to ensure cookies work across HTTPS and cross-origin requests!

Keep in mind, with Vercel, multiple serverless instances can handle requests simultaneously, which caused session conflicts. To fix this, I connected my session storage to a Redis instance. Luckily this was super easy.

Redis keeps session data consistent, avoiding conflicts across requests, especially under load. The code I ended up with:

const expressApp = app.getHttpAdapter().getInstance();
expressApp.set('trust proxy', true);

const redisClient = createClient({
    password: process.env.REDIS_PASSWORD,
    socket: {
      host: process.env.REDIS_HOST,
      port: parseInt(process.env.REDIS_PORT, 10),
    },
  });

  redisClient
    .connect()
    .catch((err) =>
      console.log('Could not establish a connection with Redis: ' + err),
    );

  redisClient.on('error', (err) => console.log('Redis error: ' + err));
  redisClient.on('connect', () =>
    console.log('Connected to Redis successfully'),
  );

  app.use(
    session({
      store: new RedisStore({ client: redisClient }),
      secret: process.env.COOKIE_SECRET,
      cookie: {
        secure: process.env.NODE_ENV !== 'development',
        sameSite: process.env.NODE_ENV === 'development' ? 'lax' : 'none',
        maxAge: 86400000,
      },
    }),
  );

Step 5: Add withCredentials in the Frontend

This step is just a side note: For session cookies to work between the frontend and backend, withCredentials need to be set to true on my frontend’s HTTP requests. This allows cookies to be included in cross-origin requests, which is important when the frontend and backend are hosted separately. I had to make sure Angular’s HTTP client had this setting enabled.

Step 6: Include font

To include font files in your NestJS project, you can use the compilerOptions in the nest-cli.json file to define assets for build output, like specifying "include": "**/*.ttf" and "outDir": "dist/src".

{
  "$schema": "https://json.schemastore.org/nest-cli",
  "collection": "@nestjs/schematics",
  "sourceRoot": "src",
  "compilerOptions": {
    "assets": [
      {
        "include": "**/*.ttf",
        "outDir": "dist/src"
      }
    ],
    "deleteOutDir": true
  }
}

After the build, ensure the fonts are correctly referenced in your code using path.resolve, e.g., path.resolve(__dirname, '../fonts/Roboto-Regular.ttf'). This approach ensures the font files are bundled with the build and accessible during runtime.

Final Thoughts to NestJS Vercel hosting

Deploying my NestJS app on Vercel was a true roller coaster. Sometimes, I felt like I was on the verge of getting everything working perfectly, only to be hit with new errors that sent me back to troubleshooting mode. There were moments of frustration—especially around the session handling and CORS issues. But each solution brought a new high, and every error fixed felt like a little victory.

Now, with everything finally working smoothly, I can say it feels awesome. Seeing my app live and functioning the way I envisioned is worth all the headaches. It’s a huge relief, but even more, it’s deeply satisfying to know I’ve overcome each hurdle and can look back on what I learned. I hope this guide can save others some of those low points and help them reach that “it just works” moment a little faster!

The post Lessons Learned: Hosting NestJS App on Vercel appeared first on Nerd Corner.

I often see blog articles where the HTML code is embedded in the Arduino file. You can do this for a mini demonstration, but it’s complete rubbish for everyday use. It is far too confusing and as soon as the project grows it is no longer usable.

The proper alternative is to set up a folder called “data” and store the web pages in this folder as html files. In addition, the styling is saved as a CSS file and functions can even be executed via a JavaScript file. So everything is 1:1 like on a normal web server!

This might also be interesting for you: WeMos D1 R2 first steps and Wifi integration

List of components

• Arduino IDE (development environment)
• WeMos D1 R2

The setup of the file system (officially SPIFFS) needs to be done once and is very easy:

(First you should have completed the basic setup from the first part!)

1. Download a copy of the file “ESP8266FS-0.2.0.zip” from GitHub and unzip it
2. Place the file esp8266fs.jar in the Arduino tool directory. The path looks like this: [home_dir]\Arduino\tools\ESP8266FS\tool\esp8266fs.jar (See picture) I had to create the path part tools\ESP8266FS\tool\ in the Arduino folder myself.
3. Restart the Arduino IDE.

That’s it already! You can now see the new item “ESP8266 Sketch Data Upload” in the Arduino IDE under Tools.

How can I use the new file system now?

1. Create an additional folder with the name “data” in your current WeMos project folder. As shown in the following image

2. Place the files you want to upload in the ‘data’ directory
3. In the Arduino IDE, select the WeMos in the ‘Tools’ menu and select a size for ‘Flash Size’
4. Close the dialogue box for the serial monitor!
5. Select the ‘ESP8266 Sketch Data Upload’ option from the ‘Tools’ menu.

As soon as the upload is complete, the message window of the Arduino IDE shows 100% upload.

WeMos example programme for switching the OnBoard LED on and off

Similar to the first part, the web server will control the OnBoard LED. The code from the first part also serves as the basis. The revised code looks like this:

#include <ESP8266WiFi.h>
#include <ESP8266WebServer.h>
#include <ESP8266mDNS.h>

ESP8266WebServer server(80);

void setup() {
  Serial.begin(115200); //Baudrate
  Serial.println("ESP starts");

  WiFi.begin("NerdCornerWiFi","NerdCornerPassword");


  Serial.print("Connecting...");

  while(WiFi.status()!=WL_CONNECTED){ //Loop which makes a point every 500ms until the connection process has finished

    delay(500);
    Serial.print(".");
  }
  Serial.println();

  Serial.print("Connected! IP-Address: ");
  Serial.println(WiFi.localIP()); //Displaying the IP Address

  if (MDNS.begin("nerd-corner")) {
    Serial.println("DNS started, available with: ");
    Serial.println("http://nerd-corner.local/");
  }

  server.serveStatic("/", SPIFFS, "/", "max-age=86400");
  SPIFFS.begin();

  server.onNotFound([](){ 
    server.send(404, "text/plain", "Landing page not found! Don't forget to name your landing page 'index.html'!");  
  });
 
  server.on("/led", HTTP_POST, []() {    
     
    const String ledState = server.arg("ledstate");
    if(ledState=="on"){
      switchLedOn();
    }
    else if(ledState=="off"){
      switchLedOff();
    }
    server.send(200, "text/json", "{\"result\":\"ok\"}");
  });

  server.begin();
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  server.handleClient();
  MDNS.update();

}

void switchLedOff(){ 
  digitalWrite(LED_BUILTIN, HIGH);   // turn the D1 LED off 
}

void switchLedOn(){ 
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED on 
}

I would like to point out a few special features. For example, we have added the following:

server.serveStatic("/", SPIFFS, "/", "max-age=86400"); 
SPIFFS.begin();

Without these two lines, access to the files in the “data” folder would not be possible. Please note that the name “index.html” is set as the default for the landing page. However, you can change this if you really want to.

server.on("/led", HTTP_POST, []() {    
     
    const String ledState = server.arg("ledstate");
    if(ledState=="on"){
      switchLedOn();
    }
    else if(ledState=="off"){
      switchLedOff();
      }
      server.send(200, "text/json", "{\"result\":\"ok\"}");
  });

The “/led” endpoint receives the commands from the web server. If the command is “on”, the LED is switched on and if “off”, the LED is switched off.

Wemos website for switching the WeMos OnBoard LED on and off

The example website has a very simple structure. It primarily consists of 2 buttons for switching the LED on and off.

The folder structure of the website is very clearly organised. There is a main page with the name “index.html”. This name is common worldwide for the main pages and is also automatically recognised by WeMos. There is also a “CSS” folder for styling and a “JS” folder for functions.

We link the styles in the header area of the website. There is a standard bootstrap, which automatically makes everything a bit nicer, and a custom styles file with my own customisations. The functions of the website are also linked in the header area. I use the jQuery standard to send requests from the website to the WeMos. My own custom functions are in the “index.js”.

Please note that the jQuery file must be included BEFORE your own file, otherwise no jQuery commands can be used in your own code! The custom functions are then used by the buttons. The HTML code of the page looks as follows:

<!DOCTYPE html>
<html lang="en"></html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1, shrink-to-fit=no"
    />
    <script type="text/javascript" src="js/jquery-3.5.1.min.js"></script>
    <script type="text/javascript" src="./js/index.js"></script>
    <link rel="stylesheet" href="css/bootstrap.min.css" />
    <link rel="stylesheet" href="css/custom-style.css" />
    <title>D1 Webserver</title>
  </head>
  <body>
    <h1>D1 Webserver with filesystem</h1>
    <p>
      This is an example for a WeMos Webserver with a filesystem. You can easily
      create webpages with html, css and js!
    </p>

    <h3>Example to turn on and off the built in LED</h3>
    <button class="button-style" onclick="changeLEDState('on')">Turn on</button>
    <button class="button-style" onclick="changeLEDState('off')">
      Turn off
    </button>

    <h3>Example to demo a JS function</h3>
    <button class="button-style" onclick="showAlert()">Show alert</button>
  </body>
</html>

Special attention is paid to the JavaScript function “changeLEDState(value)”

function changeLEDState(value) {
  $.post("/led", { ledstate: value });
}

Because jQuery is used for communication with the WeMos, a simple dollar sign with the corresponding request command is sufficient. A value is also sent with this POST request, which is either “on” or “off” to switch the LED on and off.

The web page can be downloaded as a zip file below.

Files to download

• Wemos example webserver to control OnBoard LED

The post WeMos D1 R2 – Host entire website with html, css & js appeared first on Nerd Corner.

Also, the focus should always be on clean code and it should be properly documented. Especially when a project gets bigger, proper documented work pays off. For example, to document REST endpoints it is recommended to use Swagger. The Swagger API documentation provides an overview of all endpoints and even the possibility to interact with them.

This might also be interesting for you: Angular Form with clickable SVG

List of components

• IDE (for example VS Code)
• Node.js

Documentation with swagger

Although Swagger is quite well known, I could not find a detailed implementation guide. Therefore I would like to explain 2 ways to implement Swagger in an existing node server. The first way is to add Swagger parameters directly to each endpoint. This is probably the faster variant, but can get messy depending on the number of endpoints. The second option is to create a “swagger.json” file that summarizes the parameters of the endpoints.

To use Swagger the following library and its type extension will be needed:

npm install --save  swagger-ui-express
npm install --save-dev @types/swagger-ui-express

Swagger creates documentation of the endpoints:

These can be opened and you can see an example request and an example response:

The “Try it out” button can be used to interact directly with the endpoint.

Swagger API documentation with params

This variant is more recommended for smaller projects. First, these two Swagger libraries must be integrated into the project:

npm install --save-dev @types/swagger-jsdoc 
npm install --save swagger-jsdoc

The libraries are configured in app.ts or for non Typescript users app.js. Due to the configuration set here, the documentation is located in “/api-docs”:

import express from "express";
import bodyParser from "body-parser";
import exampleRoutes from "./routes/example-route";
import swaggerJSDoc from "swagger-jsdoc";
import swaggerUi from "swagger-ui-express";

const app = express();

const options = {
  definition: {
    openapi: "3.0.1",
    info: {
      title: "REST API for Swagger Documentation",
      version: "1.0.0",
    },
    schemes: ["http", "https"],
    servers: [{ url: "http://localhost:3000/" }],
  },
  apis: [
    `${__dirname}/routes/example-route.ts`,
    "./dist/routes/example-route.js",
  ],
};

const swaggerSpec = swaggerJSDoc(options);

app.use("/api-docs", swaggerUi.serve, swaggerUi.setup(swaggerSpec));
app.use(bodyParser.json());
app.use(exampleRoutes);

app.listen(3000);

The endpoint is described with the parameters as follows:

import { Router } from "express";
import { exampleFunction } from "../controller/example";

const router = Router();

/**
 * @swagger
 * /example:
 *      post:
 *          summary: Send the text to the server
 *          tags:
 *              - ExampleEndpoints
 *          description: Send a message to the server and get a response added to the original text.
 *          requestBody:
 *              required: true
 *              content:
 *                  application/json:
 *                      schema:
 *                          type: object
 *                          properties:
 *                              responseText:
 *                                  type: string
 *                                  example: This is some example string! This is an endpoint
 *          responses:
 *              201:
 *                  description: Success
 *                  content:
 *                      application/json:
 *                          schema:
 *                              type: object
 *                              properties:
 *                                  text:
 *                                      type: string
 *                                      example: This is some example string!
 *              404:
 *                  description: Not found
 *              500:
 *                  description: Internal server error
 */
router.post("/example", exampleFunction);

export default router;

Swagger API documentation with swagger.json

To have a better overview and not to mix the documentation with the actual code, it is recommended to use one, or even more json files. When using TypeScript, the Swagger.json file must be placed in the rootDirectory:

Again, the configuration is first defined in app.ts or, for non-Typescript users, in app.js. The domain path “/api-docs” is also selected here for the documentation:

import express from "express";
import bodyParser from "body-parser";
import exampleRoutes from "./routes/example-route";
import swaggerUi from "swagger-ui-express";

import * as swaggerDocument from "./swagger.json";

const app = express();

app.use("/api-docs", swaggerUi.serve, swaggerUi.setup(swaggerDocument));

app.use(bodyParser.json());

app.use(exampleRoutes);

app.listen(3000);

Important note: To import JSON files into a Typescript project this must be allowed in tsconfig.json. Also, the JSON file must be located in the root directory.

{
  "compilerOptions": {
    "target": "es2016" /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */,
    "module": "commonjs" /* Specify what module code is generated. */,
    "rootDir": "./src" /* Specify the root folder within your source files. */,
    "moduleResolution": "node" /* Specify how TypeScript looks up a file from a given module specifier. */,
    "resolveJsonModule": true /* Enable importing .json files. */,
    "outDir": "./dist" /* Specify an output folder for all emitted files. */,
    "esModuleInterop": true /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables 'allowSyntheticDefaultImports' for type compatibility. */,
    "forceConsistentCasingInFileNames": true /* Ensure that casing is correct in imports. */,
    "strict": true /* Enable all strict type-checking options. */,
    "skipLibCheck": true /* Skip type checking all .d.ts files. */
  }
}

The previous Swagger documentation with parameters would thus look like this in swagger.json:

{
  "openapi": "3.0.1",
  "info": {
    "title": "REST API for Swagger Documentation",
    "version": "1.0.0"
  },
  "schemes": ["http"],
  "servers": [{ "url": "http://localhost:3000/" }],
  "paths": {
    "/example": {
      "post": {
        "tags": ["ExampleEndpoints"],
        "summary": "Send a text to the server",
        "description": "Send a message to the server and get a response added to the original text.",
        "requestBody": {
          "required": true,
          "content": {
            "application/json": {
              "schema": {
                "$ref": "#/components/schemas/ExampleSchemaHeader"
              }
            }
          }
        },
        "responses": {
          "201": {
            "description": "Success",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/ExampleSchemaBody"
                }
              }
            }
          },
          "404": { "description": "Not found" },
          "500": { "description": "Internal server error" }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "ExampleSchemaBody": {
        "properties": {
          "responseText": {
            "type": "string",
            "example": "This is some example string! This is an endpoint"
          }
        }
      },
      "ExampleSchemaHeader": {
        "required": ["text"],
        "properties": {
          "text": {
            "type": "string",
            "example": "This is some example string!"
          }
        }
      }
    }
  }
}

Download files

• Github example projcet for swagger params
• Github example project for swagger.json

The post Import Swagger in Node TypeScript Project appeared first on Nerd Corner.

Angular itself regularly checks the view model for changes. If the view model changes due to a state change, Angular re-renders the view because Angular automatically adjusts the UI when the model changes. These continuous observations make the whole application slower.

Moreover, with the traditional pull approach, complexity increases. Especially when multiple views need the same data. What happens when the data changes? How are views notified that new data is available? Callback functions could help, but as a result, the application quickly becomes confusing. They also have a negative impact on handling and maintenance, especially for larger applications. After all, the objects have to be initialized individually and the dependencies or the order of the methods have to be considered.

A push-based architecture can be used to avoid this problem. Angular offers a great way to implement this with RxJS and the facades design pattern! The implementation is explained using an Angular example in this blog article and is transferable for all platforms and frameworks (Angular, React, Vue.js, etc.).

List of components

• IDE (Visual Studio Code)
• Angular CLI

What is a facade actually?

The facade design pattern is a central interface that communicates with various interfaces of one or more lower-level subsystems. It can perform additional functions both before and after a client request.

The facade object provides a unified and usually simplified interface to one or more subsystems. As an intermediary, it ensures that communication or access to the individual components of a subsystem is simplified, thereby also minimizing direct dependence on these components. It delegates the client calls in such a way that clients need to know neither the classes nor their relations and dependencies.

This is especially helpful in large systems when a subsystem contains many technically oriented classes that are rarely used externally. Using a facade reduces complexity by combining multiple interfaces into one. In addition, the subsystem can be extended more easily due to the loose coupling.

The PUSH Architecture

For a push based architecture, advanced design patterns like Redux or NgRx can be used. However, a very elegant and performant push based solution can also be achieved using RxJS.

Using the long-living RxJS Observable streams, changes in the data can be pushed to all subscribers. To do so, the views subscribe to the desired data stream. If the data changes, the changes are pushed directly to all subscribers via the stream without blocking the UI thread.

In this way, direct data access is prevented and the data is read-only. The actual data source is accessed similar to an API used by the views. The facade described at the beginning serves as the central interface here. This consists of streams that provide data when the data changes and methods to request changes to the data or request specific user-defined streams.

The actual raw data is only available after it has been pushed through the stream(s). This shielding centralizes all logic and forces views to passively respond to incoming data. With the push based services, Angular View components become highly performant using both ChangeDetectionStrategy.OnPush, and the async pipe for the delivered stream data.

Therefore, the system is lazy loading. The UI framework does not need to check for state changes of the view model and instead lazily waits for a new state to be pushed.

Practical example

As an example for a push based architecture a simple application is used, which receives a random beer type via the HTTP request https://random-data-api.com/api/beer/random_beer?size=1. The type of beer is displayed in a view. An input field can be used to vary the number of beers to be shown. A facade as a central element automatically pushes the new beers to the view as soon as they are available.

As a basis for the design pattern serves the article by Thomas Burleson: https://thomasburlesonia.medium.com/push-based-architectures-with-rxjs-81b327d7c32d

The first step is to set up the state management:

export interface Beer {
  brand: string;
  name: string;
  style: string;
  hop: string;
  alcohol: string;
}

export interface BeerState {
  beerArray: Beer[];
  size: number;
}

Next, we initialize the values of the facade’s state management:

export interface BeerState {
  beerArray: Beer[];
  size: number;
}

let _state: BeerState = {
  beerArray: [],
  size: 4
};

The facade uses RxJS streams to push data directly to the views. These streams can also automatically execute a Rest API call when the states change:

combineLatest(this.size$)
      .pipe(
        //switchMap: Maps values to observable. Cancels the previous inner observable.
        switchMap(([size]) => {
          return this.findBeerArray(size);
        })
      )
      .subscribe((beerArray) => {
        this.updateState({ ..._state, beerArray });
      });

Streams are set up to be persistent and only become active when data changes:

export class BeerFacade {

  beerArray$ = this.state$.pipe(
    map((state) => state.beerArray),
    distinctUntilChanged()
  );

  size$ = this.state$.pipe(
    map((state) => state.size),
    distinctUntilChanged()
  );

  private updateState(state: BeerState) {
    this.store.next((_state = state));
  }
}

For better management, the streams are combined into a single one:

vm$: Observable<BeerState> = combineLatest(this.beerArray$, this.size$).pipe(
    map(([beerArray, size]) => {
      return { beerArray, size };
    })
  );

The HTTP request can be outsourced to a separate data service. However, since this is only a small sample program, the Rest API call is implemented and executed within the Facade:

/** RandomBeer REST call */
  private findBeerArray(size: number): Observable<Beer[]> {
    const url = `https://random-data-api.com/api/beer/random_beer?size=${size}`;
    return this.http.get<Beer[]>(url);
  }

The facade and view model stream can now be easily initialized and used. Incredibly less code is required:

export class AppComponent {
  vm$: Observable<BeerState> = this.facadeService.vm$;

  //facadeService is public for direct usage in html
  constructor(public facadeService: RandomBeerFacadeService) {} 
  title = 'RandomBeerApp';
}

The view model stream data is displayed with the following code snippet:

<div *ngIf="vm$ | async as vm">  
  <ul>
    <li id="random-beer-list" *ngFor="let u of vm.beerArray">
      Brand: {{ u.brand }}, Alcohol: {{ u.alcohol }}, Hop: {{ u.hop }}
    </li>
  </ul>
  <input id="input-rand-beer" type="number" (change)="facadeService.updateSize($event)" />
</div>

Angular’s Async Pipe ensures that the most current data is always displayed. Here is a detailed explanation of the async pipe.

Since the facade service is declared as public, the inputs are passed directly to the updateSize function of the facade:

updateSize(selectedSize: any) {
    const size = selectedSize.target.value;
    this.updateState({ ..._state, size });
  }

As a result, the application initially displays 4 random beers. Afterwards the number can be increased to 7 by the input field. This calls the updateSize() function, which updates the state of the size$ stream using updateState(). As a result, a new REST call is automatically executed and the result is pushed to the view model. With the help of the async pipe the latest data is displayed. In our case the 7 random beer types.

Finally, it makes sense to test the functionality of the individual facade components:

it('should get individual Observable "stream" of vm data', (done) => {
    testFacade.vm$.subscribe((vm) => {
      expect(vm.size).toEqual(initStateMock.size);
      done();
    });
  });

  it('should update state values', (done) => {
    const updatedStateMock: TestBeerState = {
      beerArray: [
        {
          brand: 'Pabst Blue Ribbon',
          name: 'Two Hearted Ale',
          style: 'Merican Ale',
          hop: 'Sorachi Ace',
          alcohol: '2,9%',
        },
        {
          brand: 'Bud Light',
          name: 'La fin Du Monde',
          style: 'Stout',
          hop: 'Bullion',
          alcohol: '2,7%',
        },
      ],
      size: 2,
    };
    testFacade['updateState'](updatedStateMock);
    testFacade.vm$.subscribe((vm) => {
      expect(vm).toEqual(updatedStateMock);
      done();
    });
  });

  it('should update the size value', (done) => {
    const newSize = 9;
    const mockEvent = {
      target: {
        value: newSize,
      },
    };
    testFacade['updateSize'](mockEvent);
    testFacade.vm$.subscribe((vm) => {
      expect(vm.size).toEqual(newSize);
      done();
    });
  });

  it('should perform a mocked http request', (done) => {
    const httpMock: HttpTestingController = TestBed.inject(
      HttpTestingController
    );

    const mockResponse = {
      brand: 'Pabst Blue Ribbon',
      name: 'Two Hearted Ale',
      style: 'Merican Ale',
      hop: 'Sorachi Ace',
      alcohol: '2,9%',
    };

    testFacade['findBeerArray'](1);
    testFacade.vm$.subscribe((tb) => {
      expect(tb.beerArray).toBeTruthy();
      expect(tb.beerArray[0].brand).toBe(mockResponse.brand);
      expect(tb.beerArray[0].name).toBe(mockResponse.name);
      expect(tb.beerArray[0].style).toBe(mockResponse.style);
      expect(tb.beerArray[0].hop).toBe(mockResponse.hop);
      expect(tb.beerArray[0].alcohol).toBe(mockResponse.alcohol);

      done();
    });

    const mockRequest = httpMock.expectOne(
      'https://random-data-api.com/api/beer/random_beer?size=1'
    );
    mockRequest.flush(mockResponse);
  });

The post How to build a PUSH based architecture in Angular – Facade Design Pattern appeared first on Nerd Corner.