DEV Community: BEZYL MOPHAT OTIENO

An Introduction to Serverless Functions Using Node.js.

BEZYL MOPHAT OTIENO — Sat, 29 Jul 2023 20:02:50 +0000

Introduction:
Serverless computing is a revolutionary cloud computing model that allows developers to focus solely on writing code without the need to manage servers. In this blog, we will explore the world of serverless functions using Node.js, one of the most popular programming languages for serverless development. We'll discover how serverless functions work, their advantages, and how to build and deploy them using Node.js and the Serverless Framework.

What is Serverless Computing?
Serverless computing, also known as Function-as-a-Service (FaaS), is a cloud computing paradigm where developers deploy individual functions as event-driven services. These functions are executed in stateless containers that are triggered by specific events, such as HTTP requests, database changes, or file uploads. Unlike traditional server-based architectures, serverless functions automatically scale based on demand, leading to cost optimization and improved performance.

Key Characteristics of Serverless Functions:

Event-Driven Execution:Serverless functions are triggered by events from various sources, such as HTTP requests, timers, or messaging queues. Each function is designed to respond to specific events.

No Server Management: With serverless computing, developers don't need to worry about server provisioning, scaling, or maintenance. The cloud provider takes care of managing the underlying infrastructure.

Stateless: Serverless functions are stateless, meaning they don't maintain any state between executions. Any required state must be stored externally in databases or other services.

Pay-Per-Use Billing: In serverless computing, you are billed based on the actual execution time and resources consumed by your functions. This pay-as-you-go model allows for cost-efficient use of resources.

Getting Started with Node.js and the Serverless Framework:

I'll walk you through the step-by-step procedure to set up Firebase Cloud Functions, including setting up Firebase, initializing the project with Firestore, Functions, and Emulators, and writing and testing a simple function.

Step 1: Install Firebase CLI

If you haven't installed the Firebase CLI, open your terminal and run the following command to install it globally on your system:

npm install -g firebase-tools

Step 2: Log in to Firebase
After installing the Firebase CLI, log in to your Firebase account using the following command:

firebase login

A browser window will open, and you'll be asked to log in with your Google account. After successful login, return to the terminal.

Step 3: Initialize Firebase Project
Now, navigate to the directory where you want to create your Firebase project, or create a new directory, and run the following command to initialize Firebase:

firebase init

You will be presented with a series of prompts. Use the arrow keys to select the following options:

Use the arrow keys to navigate: Firestore, Functions, and Emulators.
Use an existing project: Select the Firebase project you want to use (or create a new one).

Step 4: Configure Firestore and Functions
Next, configure Firestore and Functions by selecting the appropriate options based on your preferences and project requirements in our case select Firestore , Functions and Emulators . on the following prompts choose all defaults . For Firestore, you might choose to set security rules (default or custom) during the initialization.
We will be using typescript as the language and npm as a dependency management tool in our example. Choose typescript and npm in the configurations .

Step 5 :Setting up the Firestore Emulator and the Functions Emulator for testing your Firebase Cloud Functions locally. Here's how you can proceed:
Use the arrow keys to navigate and select the Firebase emulators you want to set up for local testing. In your case, choose the Firestore Emulator and the Functions Emulator. Press the spacebar to select them. The selected emulators will have a checkmark (✓) next to them.
Once you have selected the emulators you want to use, press Enter to confirm your choices and then select default ports for the emulators and finish up with the download .
Step 6: Install firebase-backend Module
In the functions directory, install the firebase-backend module using npm:

npm install firebase-backend

Let's start out by going through a high level overview of how the backend will be set up. This overview will go over the types of functions we use as well as the actual code structure.
Types of Functions
The backend is built around the strengths that firebase poses in their serverless cloud functions setup. Focussing on those strengths we can break the system into two types of functions (could also be called a micro-service if you choose to).

Reactive and RESTul
Reactive: This is a function that will run in reaction to data or state updating on the backend. An example of this will be when a file is uploaded to cloud storage or the most common when a document / entry in the database has been updated.

RESTful: This is the function that will run when the user makes an http request to the uri the function is assigned to. Nothing special about these ones. Just 1 note that's very important. This will not be used for single CRUD operations like adding a user, deleting a user, updating a user. And it's built with that in mind. This means you won't be able to define a single api endpoint for user that behaves differently based on the HTTP verb used. This is by design and won't be changed. All CRUD should be performed directly on your Firebase DB of choice. That's how this is supposed to be used.

Code structure
We have an enforced code structure that will help with the organization of the backend as well as the overall maintenance as it grows.
There's 3 major things to go over:

Each function will be in its own dedicated file: This is to get rid of the "natural" tendency, when starting with firebase cloud functions, to keep adding functions into the same index file forcing it to grow bigger as your backend requirements grow. The file name will be the exact name of the endpoint to keep things easy to manage. This is not a requirement but I've found it to be quite helpful.
Functions will be placed in a folder titled either restful or reactive
The backend will be split into different resource groups to ensure a structured backend in production
Organize your firebase functions folder into api domain folders (groups) and function type (reactive, restful).
src

  {group_name_folder}
    reactive
      - onSomeTrigger.function.ts
      - onSomeOtherTrigger.function.ts
    restful
      - someEndpointName.endpoint.ts
      - someOtherEndpointName.endpoint.ts
  - index.ts
package.json

Configuration
Then you can open the index.ts file in your source folder and update it to

import { FunctionParser } from 'firebase-backend';

exports = new FunctionParser({ rootPath: __dirname, exports, verbose: true })
  .exports;

These are the two magical lines of code that allows us to dynamically add and export functions as the backend grows without ever changing the index file . And that's also all we need to set it up. Now we can start creating functions .

Restful Functions (Endpoints)
Create
Let's say we wanted to make an endpoint where a client application could add a payment method for a user.
The API would be called users
The function would be called addPaymentMethod
The file would be called src/users/restful/addPaymentMethod.endpoint.ts
The endpoint name will be exactly the name of your file
The endpoint.ts file extension identifies the function as an HTTP endpoint

// src/users/restful/addPaymentMethod.endpoint.ts

import { Request, Response } from 'express';
import { Post } from 'firebase-backend'; // Get, Post, Put, Update, Delete available

// Use the `Post` class which is extended from the `Endpoint` class.
export default new Post((request: Request, response: Response) => {
  // Read the values out of the body
  const cardNumber = request.body['card_number'];
  const cardHolder = request.body['card_holder'];

  // Do your thing with the values
  let paymentToken = `${cardNumber}_${cardHolder}`;

  // Send your response. 201 to indicate the creation of a new resource
  return response.status(201).send({
    token: paymentToken,
  });
});

Testing
To test this out we'll run the following command in the functions folder.
npm run serve

This will build the TypeScript code and then serve the functions locally through the emulator. If this is successful you should see the following in the console. You should see the functions API has deployed (locally) a function at the following url
http://localhost:5001/boxtout-fireship/us-central1/users-api
All the endpoints in the users resource group will be deployed under the /user-api function. This means that we can make a post request to the endpoint with the expected data and check if we get back a result. I'm going to use PostMan to test this out. So we'll put in the above url and add /addpaymentmethod at the end of it. Select post as the HTTP request type and then pass in a body.

Reactive Functions
Create
Let's say we wanted to make a function that would run when the firestore db had a user record updated.
The API would be called users
The function would be called onUserCreated
The file would be called src/users/reactive/onUserCreated.function.ts
The endpoint name will be exactly the name of your file
The function.ts file extension identifies the function as reactive

// src/users/reactive/onUserCreated.function.ts
import * as functions from 'firebase-functions';

export default functions.firestore
  .document('users/{userId}')
  .onCreate((userSnapshot, context) => {
    const data = userSnapshot.data();
    console.log(`User Created | send an email to ${data.email}`);
  });

Testing
Run npm run build in the functions folder. Then run firebase emulators:start.
You should now have a function deployed at users-onUserCreated as well as at users-api. All the api endpoints go under the one api function, but the reactive functions are added as their own functions. Let's test this out.
At the bottom of your logs you'll see a link to firestore http://localhost:4000/firestore . Open that in your browser. You'll see an empty page. Click on start collection, make the collection id users . Add a field called email and put the value dane@filledstacks.com and save the document. When this is saved you should see the logs printing out the following message

i  functions: Beginning execution of "users-onUserCreated"
>  User id created TybqxAwnC4X5DWLgtXOp
>  {"severity":"WARNING","message":"Function returned undefined, expected Promise or value"}
i  functions: Finished "users-onUserCreated" in ~1s
>  User Created | send an email to dane@filledstacks.com

And that's it! You've created a reactive function as well as a http endpoint. Going further when you want to expand you backend you simply create a new file in the dedicated folder depending on the function type and it'll be added automatically .

We can finally deploy the functions to the cloud run :
npm run deploy

javascript

Component Poisoning in Next.js

BEZYL MOPHAT OTIENO — Thu, 27 Jul 2023 11:58:26 +0000

Component poisoning in Next.js refers to the situation where server-side code unintentionally executes on the client-side. It typically occurs when JavaScript modules shared between server and client components contain server-only code. This can lead to errors and unexpected behavior in the application.
To understand component poisoning, let's consider an example. We have a Next.js application with a home page that includes a client-side component called Client1. This component is responsible for rendering specific UI elements on the client-side.

// pages/index.js
‘Use client’

import React from 'react';
import { Client1 } from '../utils/clientComponents';

const HomePage = () => {
return (

Welcome to the Home Page

);
};

export default HomePage;

In the above code, the HomePage component imports and uses the Client1 component from a separate file called clientComponents.js. Initially, everything seems to work fine.
However, if we have additional code inside the same clientComponents.js file that contains server-side logic, such as making API calls, it can lead to component poisoning.
// utils/clientComponents.js
‘Use client’
import React from 'react';

export const Client1 = () => {
return (

Client 1

{/* Component JSX */}

);
};

export const Client2 = () => {
return (

Client 2

{/* Component JSX */}

);
};

const fetchData = async () => {
try {
const response = await fetch('https://api.example.com/data');
const data = await response.json();
console.log(data); // Do something with the data
} catch (error) {
console.error('Error fetching data:', error);
}
};

export const Server = async () => {
await fetchData();

return (

Server

{/* Component JSX */}

);
};

In the above code, the Server component is added in the same file. It contains server-side code (fetchData) responsible for making API calls. This mixing of server-side and client-side code within the same file can lead to component poisoning.
When the home page is visited, the entire file is read, causing the server-side component (Server) to execute. Since server-side components cannot run on the client-side, an error is generated.
To resolve this issue, we need to separate the server-side component from the client components. Additionally, we can utilize the "server-only" library to provide more descriptive errors for easier debugging.
After resolving the component poisoning issue:

// pages/index.js
‘Use client’

import React from 'react';
import { Client1 } from '../utils/clientComponents';

const HomePage = () => {
return (

Welcome to the Home Page

);
};

export default HomePage;

In the above code, the HomePage component continues to import and use the Client1 component as before. However, we have resolved the component poisoning issue by separating the server component.

// utils/clientComponents.js

import React from 'react';
import serverOnly from 'server-only';

export const Client1 = () => {
return (

Client 1

{/* Component JSX */}

);
};

export const Client2 = () => {
return (

Client 2

{/* Component JSX */}

);
};

In the above code, we only have the client-side components (Client1 and Client2) defined in clientComponents.js. The server-side component (Server) has been removed from this file.
By separating the server component and using the "server-only" library, we prevent server-side code from being executed on the client-side. The "server-only" library helps in providing comprehensive error messages when server-side components are mistakenly imported on the client-side, aiding in easier debugging.
By following best practices and separating server and client code appropriately, we can avoid component poisoning and ensure the smooth execution of our Next.js applications.
Bezyl Mophat - Enthusiastic Next.js Developer.

Unveiling the Power of Stored Procedures and Functions in MSSQL: A Journey through the Enchanting Realm of Database Magic

BEZYL MOPHAT OTIENO — Wed, 26 Jul 2023 15:42:49 +0000

Welcome, data enthusiasts! Today, we embark on an exciting adventure in the world of Microsoft SQL Server (MSSQL). Let's dive into two powerful tools: Stored Procedures and Functions!

Stored Procedures: Your Versatile Spellbook!

Think of stored procedures as a magical spellbook, containing precompiled T-SQL incantations that you can summon at will. These reusable blocks of SQL sorcery bring a world of modularity and code reusability to your fingertips! No need to repeat code - just call on the stored procedure, and voilà!

With stored procedures, you can weave intricate business logic and bend data to your will with ease. They handle complex tasks like a seasoned sorcerer, and their mastery over transactions and errors makes batch processing a breeze!

Functions: Graceful Enchantments for Data Transformation!

Meet the elegant and versatile functions! These enchanting charms are like mini-spells designed for specific data transformations and calculations. Need to convert values or perform intricate computations? Functions are your loyal companions! They elegantly return single values, making your queries a breeze to read and understand.

While they might not wield the same transactional powers as stored procedures, their in-line usage within queries makes them graceful allies in your SQL adventures!

🧙‍♂️ The Magic Showdown: Stored Procedures vs. Functions!

Stored procedures and functions may seem similar, but their specialties set them apart.

Stored procedures rule when it comes to handling complex business logic and data manipulation. They're your go-to magicians for performing batch operations and ensuring data security.

Functions, on the other hand, excel at data transformations and calculations. They seamlessly integrate into queries, turning your data into enchanting results with ease!

🌟 The Right Tool for the Right Task:

When you face formidable foes and need to tackle complex data quests, call upon the might of stored procedures! Their modularity and transaction-handling prowess will serve you well.

For graceful data transformations and calculations, trust the charm of functions! Their in-line magic will keep your queries clear and your results spellbinding!

Conclusion: Unleash the Magic of MSSQL!

Fellow data adventurers, you now possess the secrets of stored procedures and functions! Whether you wield the power of stored procedures or embrace the elegance of functions, remember to use them wisely and make the most of Microsoft SQL Server's enchanting capabilities. Happy sorcery! 🧙‍♀️. Check out more from : https://lnkd.in/gSYr5RzY .