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.
Overview
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:
- How can we provide a global point of access to our instance?
- How can we ensure that a class or a specific type of objects has only one instance?
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.
How can we implement the Singleton Design Pattern?
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 class should define a static property for storing the uniquely sharable instance.
The keyword static
means that the instance object is not associated with the instances of the class but with the class definition itself.
- The constructor of the class should be marked as private. The only way for getting an instance of our class is by calling the
getInstance
static method.
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.
First Practical Scenario
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.
import { PrismaClient } from "@prisma/client"
export const prismaClient = new PrismaClient()
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.
import { prismaClient } from "@/db"
const users = await prismaClient.user.findMany() // query on the users table
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.
export const prismaClient = new PrismaClient() // a new instance is created every time it gets imported then used.
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 "@prisma/client"
class PrismaClientSingleton {
private static instance: PrismaClient
private constructor() {}
public static getInstance(): PrismaClient {
if (!PrismaClientSingleton.instance) {
PrismaClientSingleton.instance = new PrismaClient()
}
return PrismaClientSingleton.instance
}
}
export default PrismaClientSingleton
Second Practical Scenario
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).
class RateLimiterService {
private static instance: RateLimiterService
private requests: Map<string, { count: number; lastRequestTime: number }>
private readonly limit: number // Maximum number of requests
private readonly window: number // Time window in milliseconds
private constructor(limit: number = 5, window: number = 60000) {
this.requests = new Map()
this.limit = limit
this.window = window
}
// Method to get a unique singleton instance
public static getInstance(): RateLimiterService {
if (!RateLimiterService.instance) {
RateLimiterService.instance = new RateLimiterService()
}
return RateLimiterService.instance
}
public isRateLimited(ip: string): boolean {
const currentTime = Date.now()
const userRequestData = this.requests.get(ip)
if (userRequestData) {
const isExpired =
currentTime - userRequestData.lastRequestTime > this.window
if (isExpired) {
userRequestData.count = 1
userRequestData.lastRequestTime = currentTime
return false
} else {
userRequestData.count++
if (userRequestData.count > this.limit) {
return true
}
return false
}
} else {
this.requests.set(ip, { count: 1, lastRequestTime: currentTime })
return false
}
}
}
export default RateLimiterService
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.
Conclusion
The Singleton Design Pattern is a powerful tool for effectively managing shared resources in our applications
Key takeaways:
- Singleton ensures a class has only one instance and provides a global point of access to it.
- It's useful for managing shared resources like database connections, configuration settings, or caches.
- Practical applications include optimizing database connections with ORMs like Prisma and implementing rate limiting services.
Contact
If you have any questions or want to discuss something further feel free to Contact me here.
Happy coding!
Top comments (5)
i can tell this is very good example of singleton
I have looked for this solution many times. Finally I found the solution explained very well.
Good article!
Glad you found it helpful!
thanks for this article. the scenarios are very useful and informative <3
You're welcome!
Thank you, @akaanuzman