Forem: Laëtitia Christelle Ouelle

Content Delivery Networks (CDNs)

Laëtitia Christelle Ouelle — Wed, 20 Sep 2023 13:43:03 +0000

Hello folk! Today we’re going to talk about CDN witch is a part of our global topic “Web Api Performance” and i hope that you guys are ready!

Let’s go 🚀 …

What is a CND ?

In web API performance, a CDN stands for “Content Delivery Network.” A CDN is a network of distributed servers strategically placed in multiple data centers around the world.

What is it used for ?

The primary purpose of a CDN is to deliver web content, including APIs, to users more efficiently by reducing latency and improving availability and scalability. CDN caches contents next to the final users so that it can send resources quickly to them.

Resources like

Static Content: HTML pages, Javascript files, css styles, images, videos.

Dynamic Content: While CDNs are primarily known for caching static content, some CDNs offer features for caching dynamic content as well. This includes dynamically generated web pages, API responses, and database-driven content.

Software Updates: CDNs are used to distribute software updates and patches. Companies often use CDNs to deliver software updates to their users, ensuring faster and more reliable downloads.

Streaming Media: Many CDNs support the delivery of streaming media content, such as video and audio streams. Content can be distributed globally to reduce latency for viewers.

Large Files: CDNs are also useful for distributing large files, such as software installation files, documents, and datasets. They can efficiently handle the transfer of large files to users, again reducing the load on your origin server.

CDNs vs Web Hosting

Sometimes when defining CDNs, they can be confused with web hosting. So we added this section to explain the difference and make it clear to you.

Web hosting is primarily used to store and serve website files, databases, and web applications from a centralized server, while CDN is to enhance the delivery speed, availability, and scalability of web content.

When it’s about content delivery, DNs distribute cached content globally, making use of edge servers to serve content from locations closer to end-users, while Web hosting serves content from a central server, which may not be optimized for global content delivery. Without a CDN, users farther from the hosting server may experience slower load times.

Finally a website can use a Content Delivery Network (CDN) to improve its performance, reliability, and content delivery. By using a CDN, a website can provide a better user experience by reducing latency, improving load times, and enhancing content delivery to users around the world.

But CDNs are independent services that work in conjunction with websites, but they don’t require a specific website to function.

*How do they work ?
*
Different CDNs use different process and technologies for driving user requests to the closest POPs..

— Let’s take a break! What is a PoP?

PoP stands for Point of Presence and is one of the multiple servers deployed by a CDN at multiple locations all over the world.

Now we continue with the explanation of how a CDN works 👇🏾

There is a lot of technologies that CDNs use but two common technologies are : DNS-Based Routing and AnyCast

DNS-Based Routing:

In DNS-Based Routing, each Point of Presence (PoP) has it’s own IP address so when the user request for a specific content to a CDN, this one (The CDN) returns the IP address of the PoP closest to the user.

AnyCast:

Things go differently with the anycast process, because in this case all PoPs have the same IP address and when a user request arrives on the anycast network, the network redirects the request to the nearest PoP to the requester .

Conclusion:

Using a Content Delivery Network (CDN) offers several key advantages:

Improved Performance: CDNs reduce latency by caching and delivering content from edge servers geographically closer to users, resulting in faster load times.

Scalability: CDNs efficiently handle traffic spikes, ensuring your website or application remains responsive even during high-demand periods.

Global Reach: CDNs have a worldwide presence, making your content accessible and fast for users across the globe.

Caching: They cache static and dynamic content, reducing the load on your origin server and minimizing server costs.

Security: CDNs often provide security features like DDoS protection and web application firewalls, enhancing your website’s protection.

Cost Efficiency: CDNs can lower bandwidth and server costs while improving performance and reliability.

In conclusion, CDNs enhance content delivery, performance and scalability for websites and applications, ensuring a faster, more reliable, and cost-effective user experience.

Follow me there :

linkedin.com/in/laetitia-christelle-ouelle-89373121b/

twitter.com/OuelleLaetitia

dev.to/ouelle

Happy coding ! 😏

Caching Strategies

Laëtitia Christelle Ouelle — Wed, 30 Aug 2023 14:49:04 +0000

Caching strategies are essential techniques employed to enhance the performance and responsiveness of web applications by mitigating the need for recurrently fetching identical data or resources. Two prevalent caching approaches encompass client-side caching and server-side caching:

Client-Side Caching: Client-side caching entails preserving responses or assets on the user’s device, typically within the web browser’s cache. This facilitates subsequent requests for the same resources to be instantly served from the cache, mitigating the necessity for renewed retrieval from the server. Here’s a deeper dive into client-side caching:

HTTP Cache-Control: Client-side caching is governed by HTTP headers like Cache-Control and Expires, which specify the duration of resource caching and the criteria for considering it fresh.

Advantages:

Decreased Latency: Cached resources load expeditiously as they are fetched locally.
Lightened Server Load: Caching alleviates the server by curtailing requests for identical resources.
Enhanced User Experience: Speedier load times contribute to a smoother user experience.

Instances of Client-Side Caching:

Browser Cache: Web browsers automatically cache resources like images, stylesheets, and scripts, and caching behavior can be regulated using HTTP headers.
Service Workers: Progressive web apps (PWAs) leverage service workers to cache assets and provide offline capabilities.

Server-Side Caching: Server-side caching involves the retention of often-requested data or entire responses on the server or an intermediary server (e.g., a proxy or CDN). This approach curtails the time and resources necessary for generating responses, substantially enhancing application performance. Here’s an exploration of server-side caching:

Caching Mechanisms: Various mechanisms are employed for server-side caching, including in-memory caching, distributed caching, reverse proxy caching, and content delivery networks (CDNs).

Cache Invalidation: To ensure the continued accuracy of cached data, strategies for cache invalidation are imperative. Data should be refreshed or invalidated when it becomes outdated or when alterations occur in the source data.

Advantages:

Expedited Response Times: Cached responses are dispensed swiftly, diminishing user wait times for data to load.
Lighter Server Burden: Caching reduces the application server’s load by curtailing the necessity to regenerate identical responses.
Scalability: Caching facilitates the more efficient scalability of applications by disseminating the load across cached responses.

Instances of Server-Side Caching:

In-Memory Caches: Tools such as Redis and Memcached are commonly employed to cache frequently accessed data in memory.
Reverse Proxy Caches: Servers like Nginx and Varnish can be configured as reverse proxies with integrated caching capabilities.
Content Delivery Networks (CDNs): CDNs cache static assets, such as images and scripts, across numerous global locations for accelerated delivery to end-users.

Caching represents a potent strategy for optimizing web applications and APIs, curbing latency, and heightening overall performance. Nonetheless, effective cache management is requisite to ensure that cached data remains current and precise, balancing the interplay between performance enhancement and data accuracy.

Follow me there :

linkedin.com/in/laetitia-christelle-ouelle-89373121b/

twitter.com/OuelleLaetitia

dev.to/ouelle

Happy coding ! 😏

Server-Side Performance:

Laëtitia Christelle Ouelle — Sat, 26 Aug 2023 12:21:48 +0000

We mainly discuss about some kind of “good practices” to build a reliable, scalable and performant API. But this may prove to be insufficient when it comes to APIS that have intensives tasks.

It does not mean that applying methods i gave in the previous series of articles around “Web API performance” are now out to date because they might be insufficient. But it’s also a good thing to combine and apply methods based on what your API needs to perform.

So we’re going to talk about server-side performance.

Server-side performance refers to the efficiency and responsiveness of a server in processing requests and delivering responses in a web application or service. It is a critical aspect of web development, as a well-optimized server can significantly impact the overall user experience.

I thought it best to articulate the Server-side performance topic around 3 concepts that I find important: Load Balancing, Scaling and Concurrency & Threading

Load Balancing : This concept may be new to you, but it is substantial.

— Definition:

Load balancing is a networking technique or process used to distribute incoming network traffic or computing workload across multiple servers, resources, or devices.

The primary purpose of load balancing is to ensure that no single resource becomes overwhelmed with traffic or workload, thereby optimizing the performance, reliability, and availability of a network or application.

In order to prevent the server or an instance from being overloaded with requests, load balancers distribute incoming requests so that each of them is correctly executed in time.

Here’s how it works: A load balancer performs its role based on a selected load balancing algorithm. This algorithm defines how our requests will be sent through our servers or instances.

There are various load balancing algorithms, each with its own characteristics and use cases. Here are some common load balancing algorithms:

Round Robin: This is one of the simplest load balancing algorithms. It distributes traffic evenly to each server in a circular manner. Each incoming request is routed to the next server in the list. Round robin is easy to implement but may not take server load into account, potentially sending traffic to an overloaded server.

— Pros:

If all the available servers have the same capacity then :

Each server has exactly the same requests workload
Routed requests are approximately executed in the same time
The response speed is boosted
Clients receive their responses in time and we have a good user-friendly apps

— Cons:

Distributing request in the round robin fashion may cause server overload because let’s suppose that our “Server 1” is 5 times less powerful that our “server 2”, the “server 1” due to his low capacity will not have enough time to complete the first request in time but will receive new requests witch will be queued. The result will be either a long response time or a down server.

So here we need a Round Robin Algorithm that take into account the capacities of each server.

Weighted Round Robin: Weighted round robin assigns each server a weight, indicating its capacity or performance. Servers with higher weights receive more traffic than those with lower weights. This allows for proportional distribution of traffic based on server capabilities.

— Pros

Same advantages as Round Robin
So basically it’s a Round Robin that takes server capabilities into account.

— Cons

Both Round Robin algorithm don’t take in to account the number of connections that servers must maintain for a certain period when the load balancer distributes requests.

This means that multiple connections can accumulate on a server in the cluster. This causes a server overload, even if it has fewer connections than the others.

Least Connections: This algorithm directs traffic to the server with the fewest active connections or sessions. It is effective at distributing traffic based on server load, ensuring that connections are evenly spread across the servers.

The image above shows that “server 1" has 3 actives connections, “server 3” has 4. So the algorithm send the “Request a” to the “server 3” with has 0 active connection, and here we go again, the operation restarts. So now “server 1” has 3 actives connections, “server 2" has 4 and “server 3” has 1, so the “Request b” goes to the “server 3". The same operation restarts and send the “Request c” to the server 3.

— Pros :

One of the primary advantages of the “Least Connections” algorithm is that it distributes incoming traffic to servers with the fewest active connections. This ensures a relatively even distribution of traffic, preventing any single server from becoming overloaded while others remain underutilized.

— Cons:

The “Least Connections” algorithm is typically stateless. It does not consider server load based on factors like CPU usage, memory usage, or application-specific metrics. It only looks at the number of active connections, which might not be a comprehensive measure of server load in all scenarios.

Weighted Least Connections: Similar to weighted round robin, this algorithm considers server weights but also takes into account the number of active connections. Servers with both lower weights and fewer connections receive priority.

Other Algorithm:

IP Hash
Least Response Time
Random
Least BandwidthChained Failover
Dynamic Algorithms:_
(A part 2 will be entirely dedicated to them)

The selection of an appropriate load balancing algorithm is contingent upon the precise demands and intricacies inherent in the application at hand, as well as the existing infrastructure’s configuration.

Within this context, it becomes evident that certain applications derive notable advantages from employing a straightforward round-robin methodology, which systematically distributes incoming traffic to designated servers in a sequential manner.

However, in contrast, there exist scenarios where the requisites of the application dictate the utilization of more advanced and refined load balancing algorithms, ones that exhibit the capacity to meticulously assess and account for the health and performance metrics of individual servers.

It is imperative to recognize that the world of load balancing is not confined to predetermined algorithms, as some load balancers extend the flexibility of tailoring custom algorithms or intricate configurations, thereby affording the capacity to address idiosyncratic and distinct operational needs with precision and efficacy.

Scaling : _Be prepared to scale your server resources both vertically and horizontally as traffic and demand increase.
_

What is scaling ?

Scaling in computing and technology involves adjusting system capacity and capabilities to accommodate evolving workloads, playing a pivotal role in developing and maintaining applications, networks, and infrastructure to satisfy user and data requirements.

There are two primary types of scaling: vertical & horizontal scaling

*Vertical Scaling * (Scaling Up):

Vertical scaling involves increasing the resources of a single server or node to handle a higher workload.
This typically means upgrading the server’s CPU, memory (RAM), storage, or other hardware components.
Vertical scaling can be limited by the maximum capacity of a single server and can be costlier as more powerful hardware is often more expensive.

Horizontal Scaling (Scaling Out):

Horizontal scaling involves adding more servers or nodes to a system to distribute the workload.
Each new server is identical to the existing ones and shares the processing load.
Horizontal scaling is more scalable and cost-effective for handling high traffic loads because it can be easily expanded as needed.

Here are some common examples of scaling in various technology contexts:

Web Servers: Adding more web servers to distribute incoming web requests across multiple machines to handle increased user traffic. This is horizontal scaling.
Database Scaling: In database systems, scaling can involve adding more database servers or optimizing queries and indexes to handle larger data sets.
Application Scaling: Scaling out application servers to accommodate more concurrent users or application instances to process more tasks simultaneously.
Load Balancing: Distributing incoming network traffic across multiple servers to ensure that no single server is overwhelmed. This can be done using load balancers.
Cloud Computing: Cloud services like AWS, Azure, and Google Cloud offer scalable resources on-demand, allowing you to scale your applications up or down as needed.
Microservices: Breaking down monolithic applications into smaller, independent microservices that can be individually scaled based on demand.

Scalability represents a critical cornerstone in the realm of technology and systems engineering, primarily focused on the assurance that a system possesses the capability to effectively embrace growth, uphold consistent performance levels, and swiftly respond to dynamic shifts in demand.

The essence of scalability lies in its capacity to furnish systems with the agility required to seamlessly adapt to evolving workloads and user requirements. In doing so, it not only assures the preservation of a responsive and reliable user experience but also delivers on the promise of cost-efficiency by optimizing resource utilization and mitigating infrastructure expenses.

Consequently, the concept of scalability stands as a fundamental and indispensable component of modern technological landscapes, underpinning the foundation of robust and adaptive systems.

Multi-Threading : Efficiently handling multiple requests simultaneously.

A thread is similar to a process because it represents the execution of a set of machine language instructions from a processor.

Multithreading in the context of a web API refers to the ability of the web server to handle multiple incoming HTTP requests concurrently by using multiple threads. This is important for improving the scalability and responsiveness of web applications, as it allows the server to efficiently utilize the available hardware resources and handle a large number of client requests simultaneously.

It helps improve the scalability of a web API. As the number of incoming requests increases, the server can create additional threads to handle the load, up to a certain limit, without significant degradation in performance.

When designing a multithreaded web API, it’s essential to consider both blocking and non-blocking operations. Blocking operations, such as I/O operations, can cause a thread to wait, potentially reducing the server’s overall throughput. Non-blocking operations, like asynchronous programming, can help mitigate this issue by allowing threads to work on other tasks while waiting for I/O to complete.

Overall, multithreading is a fundamental concept in the development of high-performance web APIs. It allows web servers to efficiently handle a large number of concurrent client requests, ensuring responsiveness and scalability. However, it also introduces complexity and potential pitfalls that developers need to be aware of and address in their designs and implementations.

Server-side performance is a critical aspect of web and application development focused on optimizing the efficiency and speed of operations that occur on the server. It encompasses various strategies and techniques, including code optimization, database tuning, caching, load balancing, and scalability measures, all aimed at ensuring that server resources are used effectively and that applications can handle increasing user loads while maintaining responsiveness. High server-side performance is crucial for delivering a smooth and responsive user experience, particularly in web and mobile applications.

Follow me there :

linkedin.com/in/laetitia-christelle-ouelle-89373121b/

twitter.com/OuelleLaetitia

dev.to/ouelle

Happy coding ! 😏

APIs Response Time Optimization

Laëtitia Christelle Ouelle — Mon, 21 Aug 2023 01:07:48 +0000

Previously we talked about Restful Design, what it is and the importance for our API to follow its standards and conventions to create a fast, reliable and scalable RESTFUL API.

Now let’s dive into the second step of optimizing web API performance: Response Time Optimization.

Response time is a critical factor in delivering a responsive and efficient API experience to users. Here’s how you can optimize the response time of your API:

Minimize Network Latency:

a- ) Choose data centers or hosting locations that are geographically close to your target audience.

The logics of the real world rules are exactly the same in the logic of the programming world, because going to your kitchen to get a new bottle of coca cola will take less time than picking up that bottle from a supermarket.

Here both supermarket and kitchen represent your data hosting location.

It means that an app that will be only use in Ivory Coast with its hosting location in china will not have the same response speed as if its server(s) was in the same country.

Use case with the image bellow as illustration

Here the bubbles with centered letters represent the servers (hosting location) and the square represents the application. Regardless of the quality and performance of the servers, you should choose the closest server possible.

so servers (E, G, F, H ) are a better choice.

I mentioned server performance and quality because distance is not the only parameter to consider. Choosing a bad server just because it’s the closest is not a good thing to do when you want your API to work properly.

What you need to consider is the geographical distance and the server capacity.

Optimize Database Queries:

a- ) Use efficient database queries by selecting only the necessary columns and rows of data.

Selecting more fields than necessary will increase the response time and the volume of your response

for example, an array of one thousand items like this 👇🏾

const itemArray :{username:string, email:string, pwd: string}=[
  {
    username:"John doe",
    email:"doe@mailio.az", 
    pwd: "skjdubss"
  },
  ....99 other items
]

will have a lower volume and response time than a query that needs to send a response like this 👇🏾

const itemArray :{
  username:string,
  email:string,
  pwd: string,
  avatar_url:string,
  posts: Post[],
  documents: Documents[]
}=[
  {
    username:"John doe",
    email:"doe@mailio.az", 
    pwd: "skjdubss",
    avatar_url:string,
    posts: [{...postsList}],
    documents: [{...documentList}]
  },
  ....99 other items
]

So make sure you really need all the items you are asking your database to send via your queries.

b- ) Avoid N+1 query problems by utilizing eager loading or database joins

N+1 query means querying your database more than once to get the final answer you need.

Suppose you want to fetch a user by his id and in addition you want all his posts, by using the N+1 query method, you will firstly find and fetch the user by his id .

Fetching route example : https://api-route/users/426ghh-5266t-RZGUZHZ

Then fetch the posts table to get all the user posts

Fetching route example : https://api-route/posts/egZHZ-12tgeg-6272v-jzhz
Performing two queries will take longer to get the data we need, which will cause a performance hit at the client level in addition to overloading the server with unnecessary queries.

So do your best to get the data you need in a single query. (utilizing eager loading or database joins)

— What is eager loading :

Eager loading is a performance enhancement strategy employed in software development, often within the realm of Object-Relational Mapping (ORM) frameworks.

In eager loading, when you retrieve data from a database, you fetch not only the main object you’re interested in but also related objects or data that are commonly accessed together. This reduces the number of database queries and, consequently, improves performance by minimizing the “N+1 query problem.”

For instance, let’s take a blog application as an example. In the absence of eager loading, if you retrieve a list of blog posts and then separately retrieve comments for each post, you would execute one query for obtaining the blog posts and N additional queries to fetch comments for each post (with N representing the number of posts). This approach can result in a substantial performance overhead.

In contrast, when you implement eager loading, you can direct your ORM to retrieve both the blog posts and their corresponding comments in a single database query, typically accomplished through SQL JOIN operations. This streamlined approach optimizes data retrieval by reducing the number of database queries, ultimately enhancing the efficiency of your application.

Eager loading proves especially beneficial in situations where you anticipate that specific related data will frequently be accessed together, thereby reducing the time and computational resources required to load and display this data within your application.

— What is database joins :

Database joins are operations used in relational databases to combine data from two or more tables based on a related column between them. They are fundamental for retrieving and working with data distributed across multiple tables in a structured and efficient manner.

Caching

Optimizing response time through caching is a crucial strategy for improving the performance and responsiveness of web APIs and applications. Caching involves the temporary storage of frequently requested data or responses, so that subsequent requests for the same data can be serviced quickly without the need to regenerate the response from the source.

a- ) Client-Side Caching:

Client-side caching involves storing data or responses on the user’s device, typically in the web browser’s cache, commonly used for static assets like images, stylesheets, and JavaScript files and controlled through HTTP caching headers (e.g., Cache-Control, Expires, ETag) sent by the server in response headers.

b- ) Server-Side Caching:

Server-side caching involves storing data or responses on the server or an intermediary server (like a proxy or CDN), especially for dynamic content or data that doesn’t change frequently. It helps reduce the load on the application server and database.

Compressing Responses

Response compression is a performance optimization technique used to reduce the size of data transferred over the network. Smaller responses result in faster load times and better user experience, especially for users with limited bandwidth or on slower connections.

Common Compression Algorithms are :

— GZIP: widely used, and works well for compressing text-based content such as HTML, CSS, JavaScript, and JSON. Most modern web servers and clients support GZIP compression.

— Brotli: a new compression algorithm developed by Google. It offers better compression rates than GZIP, which makes it more efficient for textual content. However, Brotli support may not be as widespread as GZIP.

Applying all these methods will help us to improve the performance of our Apis, which means better client-side application quality and better user experience.

Next time we will talk about “network efficiency” but in the meantime, I hope you find this article useful and feel free to leave your opinions in the comments.

Follow me there :

linkedin.com/in/laetitia-christelle-ouelle-89373121b/

twitter.com/OuelleLaetitia

dev.to/ouelle

Happy coding ! 😏

Basic CRUD operations with NestJs, TypeScript, Fastify & MongoDB

Laëtitia Christelle Ouelle — Fri, 18 Aug 2023 17:49:09 +0000

Fastify is a web framework for building efficient and high-performance web applications and APIs in Node.js. It is designed to be lightweight and focused on speed, making it particularly suitable for applications that require low latency and high throughput. Fastify was developed to address some of the shortcomings of existing Node.js frameworks in terms of performance and simplicity.

Let’s go

Create your NestJs project



npx nest new project-name

Our project name is : fastify-mongo-crud and we’ll use yarn but you can choose any other package manager listed.

Add the Fastify package with this command



yarn add @nestjs/platform-fastify

By default , when you create a new Nestjs project, Nest install “@nestjs/platform-express” package (see the image below),

Because we’ll use Fastify we dont need this express platform anymore.

Create a nest resource with



npx nest generate resource articles --no-spec

then select REST API

Nest will ask you i f you want to generate CRUD entry points : Type ‘n’ to say no.

Great! now as we already know, the default framework is Express, we need to change it to Fastify.

In the root of the project, pass the code bellow into main.ts file



import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { FastifyAdapter,NestFastifyApplication} from '@nestjs/platform-fastify';

async function bootstrap() {
  const app = await NestFactory.create<NestFastifyApplication>(AppModule, new FastifyAdapter());
  await app.listen(3000);
}
bootstrap();

PS: If you have the following issue :

Type 'NestFastifyApplication<RawServerDefault>' does not satisfy the constraint 'INestApplication'.

Perhaps there is a compatibility versions issue of both @nestjs/platform-fastify and NestJS core packages, so run



yarn upgrade-interactive --latest

to update the dependencies to their last stable versions.

Once you’ve done with that, install mongoDb to the project



yarn add @nestjs/mongoose mongoose

Once the mongoose package is installed, we need to import the MongooseModule into the root AppModule. At this stage, your app.module.ts should be like :



import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { ArticlesModule } from './articles/articles.module';
import { MongooseModule } from '@nestjs/mongoose';


@Module({
  imports: [ MongooseModule.forRoot('mongodb://mongO_uri'), ArticlesModule],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Do not forget to replace the mongodb://mongO_uri by a real mongoDb uri.

Create our article schema in src/article/schema/article.schema.ts :



import { Prop, Schema, SchemaFactory } from '@nestjs/mongoose';
import { HydratedDocument } from 'mongoose';

export type ArticleDocument = HydratedDocument<Article>;

@Schema()
export class Article {
  @Prop()
  title: string;

  @Prop()
  slug: string;

  @Prop()
  content: string;  
}

export const ArticleSchema = SchemaFactory.createForClass(Article);

Import the MongooseModule, Article and ArticleSchema in your article.module.ts file



import { Module } from '@nestjs/common';
import { ArticlesService } from './articles.service';
import { ArticlesController } from './articles.controller';
import { MongooseModule } from '@nestjs/mongoose';
import { Article, ArticleSchema } from './schema/article.schema';

@Module({
  imports:[MongooseModule.forFeature([{ name: Article.name, schema: ArticleSchema }])],
  controllers: [ArticlesController],
  providers: [ArticlesService]
})
export class ArticlesModule {}

It’s time to run the project to see if everything works properly.

Run it with yarn start dev

If not and if you got this error:



const stringWidth = require('string-width');
Error [ERR_REQUIRE_ESM]: require() of ES Module

Just delete the node-module file and install all the dependencies again.

Great! MongoDb and Fastify added and set up successfully

Let’s create our services now in order to post and get data from the database.

src/articles/articles.service.ts



import { Injectable } from '@nestjs/common';
import { Article } from './schema/article.schema';
import { InjectModel } from '@nestjs/mongoose';
import { Model } from 'mongoose';

@Injectable()
export class ArticlesService {
    constructor(@InjectModel(Article.name) private readonly articleModel: Model<Article>){}

    async postArticle( body: Article):Promise<Article> {
        const create = new this.articleModel(body)
        return create.save()
    }

    async getArticles(){
        return this.articleModel.find().exec()
    }
}

postArticle() is here for creating new article and save it to the mongoDb database and getArticles() for getting all the articles from the database

Once we created all the services we want, let’s create the controller:

src/articles/articles.controller.ts



import { Body, Controller, Get, Post } from '@nestjs/common';
import { ArticlesService } from './articles.service';
import { Article } from './schema/article.schema';

@Controller('articles')
export class ArticlesController {
  constructor(private readonly articlesService: ArticlesService) {}

  @Post('create')
  postArticle( @Body() body : Article ){
    return this.articlesService.postArticle(body);
  }

   @Get('get-articles')
   getArticles(){
    return this.articlesService.getArticles();
   }
}

For each function, we defined the request type (POST or GET only for this example), the pathname and the necessary parameters.

Great! now let’s open postman to see if we can post and get with our simple Fastify api implementation.

localhost:3000/articles/get-articles result :

localhost:3000/articles/create result :

Congratulation, we’ve delved into the world of basic CRUD operations, leveraging the power of NestJs, TypeScript, Fastify, and MongoDB. By mastering these fundamental techniques, you’ve laid a strong foundation for creating robust applications. As you continue to explore and refine your skills, remember that the journey of a developer is an ongoing evolution.

For more about Fastify 👉🏾 : https://fastify.dev/

You can find the whole project on Github 👇🏾 : https://github.com/laetitiaouelle/fastify-mongo-crud

Follow me there :

https://linkedin.com/in/laetitia-christelle-ouelle-89373121b/

https://twitter.com/OuelleLaetitia

https://dev.to/ouelle

Happy coding ! 😏

API Design and Architecture

Laëtitia Christelle Ouelle — Wed, 16 Aug 2023 12:02:02 +0000

As a developer, the main goal is to produce apps that users can easily use. For this reason, we usually hear words such as: reliable, scalable, fast, etc. All that to say, you have to build great apps which also means you have to know a lot about how to do it.

In our digital world, good application performance is vital, ensuring seamless user experiences. As apps rely more on web APIs to communicate with external services, API performance becomes crucial. Factors like low latency, high throughput, scalability, caching, and error handling influence API efficiency. Balancing these elements ensures apps run smoothly by interacting effectively with APIs in today’s interconnected landscape.

Now let’s dive deeper into the first step of web API performance optimization, which is to design your API with performance in mind.

There are many points to discuss on this subject but we will deal with the most important in my opinion.

RESTful Design, Versioning, Response Size and Format, Caching Headers, Logging and Monitoring.

RESTful Design:

Rest is a type of architectural that provides some standards and/or conventions that must be followed by an API to be called a RestFull or a Rest API.

In 2000, An American computer scientist Roy T. Fielding proposed Rest witch stands for “Representational State Transfert” for building distributed systems based on hypermedia and it aims to facilitate communication between apps.

Rest has 6 standards that a Rest API must follow:

Separation of the client and the server

This approach means that server and client are managed separately and are only linked by communication. Thus, the client can be of any type. Rest API server could be builded using “Python FastAPI” and the client using “ReactJs”.

Statelessness

Communication between client and server does not consider the session state from one request to another because each request is self-sufficient.

Uniformity of the interface

The Uniform Interface constraint subdivides into distinct elements that establish a reliable and foreseeable communication pattern between clients and servers. Here are the main components of the Uniform Interface constraint in a REST API:

Resource Identification in Requests: Each resource is identified by a unique URI

Resource Manipulation Through Representations: Resources are represented in a standardized format, such as JSON or XML.

Self-Descriptive Messages : Every message (request or response) must carry sufficient information for the recipient to grasp its intent, including metadata, headers, and a clear representation format.

Hypermedia as the Engine of Application State (HATEOAS) : The server embeds hypermedia links in responses, directing clients toward potential next steps. Clients utilize these links to traverse the application’s states.

Caching

Implementing caching mechanisms can significantly improve API performance by serving frequently requested data from memory rather than generating it anew each time.

Layered architecture

In REST APIs, interactions and replies span various tiers. It’s essential to avoid assuming direct client-server connections; intermediaries often come into play. REST APIs must be crafted to be agnostic about whether they engage with the end app or an intermediary in the communication loop.

Code on demand (optional)

Typically, REST APIs dispatch static resources, yet on occasion, responses might carry executable code (e.g., Java applets). In such instances, the code should solely execute when prompted.

To put it simply, the RestFull Design:

— Follow the principles of representative state transfer (REST) to design simple, intuitive, and resource-oriented APIs.
— Use standard HTTP methods (GET, POST, PUT, DELETE) appropriately to perform CRUD (Create, Read, Update, Delete) operations.
— Use meaningful resource URLs and adopt a consistent naming convention.

Versioning

Versioning for web API design involves offering a means to handle modifications and updates to your API while upholding backward compatibility. It empowers you to introduce fresh features, adjust current functionality, or retire specific capabilities, all without disrupting existing client apps reliant on your API. Versioning plays a pivotal role in ensuring a seamless experience for developers utilizing your API and the end-users of their applications.

There are several approaches to versioning APIs:

URL Versioning:

Example:

/v1/resource
/v2/resource

Pros:

Easy to understand and implement.
Clear separation between different versions.

Cons:

Clutters the URL space, especially if multiple resources need versioning.

Potential issues with caching and reverse proxy configurations.

Header Versioning: It means including the version information in the HTTP headers of the request or response

For example:

Accept: application/vnd.myapi.v1+json
Accept: application/vnd.myapi.v2+json

Pros:

Keeps the URL cleaner.
Allows for easier integration with client libraries.

Cons:

Developers need to be aware of and handle the versioning in their code.
Slightly more complex implementation.

Query Parameter Versioning:

Version information is included as a query parameter in the URL.

For example:

/resource?v=1
/resource?v=2

Pros:

Allows clients to easily switch between versions.

Cons:

Can lead to issues with caching and search engine indexing.
Can make URLs less readable.

API versioning holds utmost importance in design, wielding substantial influence over your API’s long-term maintainability and user-friendliness. Selecting a versioning approach that harmonizes with your API’s objectives and is effectively conveyed to your developer community is vital.

Response Size and Format

Keep response payloads as small as possible by only including necessary data fields.

Choose a compact data format, such as JSON, and minimize unnecessary whitespace.

Avoid sending excessive metadata in responses.
Implement pagination for large datasets to avoid sending all data in a single response.

Use query parameters (e.g., ?page=2&limit=10) to control the number of items per page and the current page.

Provide the ability for clients to specify which fields they need in the response (field selection).

Use query parameters (e.g., ?fields=name,email) to customize response content.

Caching Headers

Caching headers, HTTP headers employed to manage caching actions for resources shared between clients (like web browsers or API users) and servers, play a pivotal role.
Caching bolsters web app performance by curbing the necessity to continually fetch identical resources from the server.

By configuring suitable caching headers, you wield control over how resources are retained and reused by clients and intermediate caches, including proxy servers and content delivery networks (CDNs).

Logging and Monitoring

Logging: Involves recording events, errors, and relevant information about the interactions and activities of your API.
These logs serve as a historical record that can be used for debugging, auditing, and understanding how your API is being used.

Monitoring: Involves the continuous observation of key metrics and indicators related to your API’s performance, availability, and usage. Monitoring helps you proactively identify performance bottlenecks, downtime, and anomalies, allowing you to take corrective action in a timely manner.

Bear in mind that crafting an efficient API revolves around harmonizing simplicity, flexibility, and efficiency.

As you center your efforts on these design tenets, stay open to adjustments and refinements to align with the shifting usage patterns and needs of your API.

I hope you will find this article useful.
See you soon 🙃

Follow me there :

https://www.linkedin.com/in/laetitia-christelle-ouelle-89373121b/

https://ouelle.medium.com/