Home >Web Front-end >JS Tutorial >Singleton Design Pattern: Managing Global States in Your Applications
Have you ever found yourself dealing with an object that needs to be shared across multiple parts of your application—perhaps a database connection, a WebSocket client, or a configuration manager?
How do you manage such an object so that it remains consistent and accessible throughout the application or process lifecycle? This is where the Singleton Design Pattern comes into play.
Singleton is a creational design pattern , which is a category of design patterns that deals with the different problems that come with the native way of creating objects with the new keyword or operator.
The Singleton Design Pattern focuses on solving two primary problems:
It can simplify and standardize the way we are managing a specific kind or type of global state such as database connections, WebSocket clients, caching services, or anything that we need to persist and mutate in memory during the entire application lifecycle.
The above schema translates into this TypeScript class:
TypeScript example
class Singleton { private static instance: Singleton // other properties... public authorName: string private constructor({ authorName }: { authorName: string }) { this.authorName = authorName } public static getInstance(params) { if (!this.instance) { this.instance = new Singleton(params) } return this.instance } // other methods... }
The keyword static means that the instance object is not associated with the instances of the class but with the class definition itself.
const instance = Singleton.getInstance({ authorName: "Sidali Assoul" }) // let's imagine const instance1 = Singleton.getInstance({ authorName: "Sidali Assoul" }) // "Sidali Assoul" const instance2 = Singleton.getInstance({ authorName: "John Doe" }) // "Sidali Assoul"
We can make use of the above class by calling the static method getInstance which is associated with the Singleton class.
The getInstance method guarantees us that we are always getting the same instance even if we instantiated our class multiple times in different locations of our codebase.
So both variables (instance1 and instance2) share the same singleton instance.
Prisma is a well-known ORM in the JavaScript ecosystem. To use Prisma in your application, you have to import a PrismaClient then instantiate an object from it.
class Singleton { private static instance: Singleton // other properties... public authorName: string private constructor({ authorName }: { authorName: string }) { this.authorName = authorName } public static getInstance(params) { if (!this.instance) { this.instance = new Singleton(params) } return this.instance } // other methods... }
The Prisma client connects to the database in a lazy manner, or in other terms, only when you first try to query or mutate some entity.
const instance = Singleton.getInstance({ authorName: "Sidali Assoul" }) // let's imagine const instance1 = Singleton.getInstance({ authorName: "Sidali Assoul" }) // "Sidali Assoul" const instance2 = Singleton.getInstance({ authorName: "John Doe" }) // "Sidali Assoul"
Every time the prismaClient gets imported in a file, a new instance will be made out of the PrismaClient. Hence, many database connections will be established every time we use those instances.
import { PrismaClient } from "@prisma/client" export const prismaClient = new PrismaClient()
Many open database connections will degrade the performance of your application and may even lead to database shutdown because databases typically can only handle a limited number of connections.
The Singleton Design Pattern can help us prevent such an issue by avoiding having more than one instance of the PrismaClient class and by providing a single point to access it via the PrismaClientSingleton.getInstance() static method.
import { prismaClient } from "@/db" const users = await prismaClient.user.findMany() // query on the users table
Another practical scenario we will be going through is an in-memory rate limiter service.
Users or hackers can spam a specific endpoint by making a ton of requests to it. This can lead to vulnerabilities, unexpected costs, or server failures.
To prevent that, we can implement a basic in-memory rate limiter service.
The service should be limiting the number of requests per IP address for a specific timing window interval (60 seconds, for example).
export const prismaClient = new PrismaClient() // a new instance is created every time it gets imported then used.
The RateLimiterService class stores a map which tracks the number of requests (requests[ip].count) being made by a specific user identified by an IP address (the map key) in a given timing window (requests[ip].lastRequestTime).
Our RateLimiterService is meant to be used globally, or in other terms, we don't want to reset the internal state values consisting of the requests map, limit, and window variables every time the RateLimiterService gets imported.
The Singleton Design Pattern is a powerful tool for effectively managing shared resources in our applications
Key takeaways:
If you have any questions or want to discuss something further feel free to Contact me here.
Happy coding!
The above is the detailed content of Singleton Design Pattern: Managing Global States in Your Applications. For more information, please follow other related articles on the PHP Chinese website!