DEV Community: Fırat Emre ŞİRVAN

🔴Managing Cron Jobs with NestJS: Solving Multi-Instance Issues and Locking Mechanisms

Fırat Emre ŞİRVAN — Thu, 14 Nov 2024 19:22:31 +0000

Why Cron Jobs Can Cause Problems in a Multi-Instance Environment

Cron jobs are quite useful for running tasks at specific intervals in the background. However, in a horizontally scaled application, a cron job running simultaneously on multiple instances can lead to repetitive tasks and data inconsistencies. For example, each instance might try to update the same record or repeat a certain task, causing serious issues. To solve this, we should use locking mechanisms to ensure that tasks are only executed by a single instance.

Working with Cron Jobs in NestJS

NestJS provides the @nestjs/schedule module for cron jobs, which allows us to easily manage cron tasks. This module offers decorators to schedule cron jobs. First, let's install the module:

npm install @nestjs/schedule

After installing, we can define tasks using decorators like @Cron, @Interval, and @Timeout. Below is an example of a simple cron job definition:

import { Injectable } from '@nestjs/common';
import { Cron, CronExpression } from '@nestjs/schedule';

@Injectable()
export class TasksService {
  // Define a cron job that runs every minute
  @Cron(CronExpression.EVERY_MINUTE)
  handleCron() {
    console.log('Cron job running: ', new Date().toISOString());
  }
}

In the example above, @Cron(CronExpression.EVERY_MINUTE) specifies a cron job that runs every minute. With the @Cron decorator, you can set different time intervals for the task. However, this job will be executed by each instance of the application if there are multiple instances. To ensure each cron job is run only once in a multi-instance environment, you need to implement locking mechanisms.

Locking Mechanisms: Solutions to Multi-Instance Issues

Locking mechanisms ensure that a specific task is executed by only one instance, preventing repeated operations or data inconsistencies. Here are the four most common locking methods:

Database-Based Pessimistic Lock

A database-based pessimistic lock is often used in SQL databases. Before a task starts, a row is locked in the database, and the lock is released once the process is complete. For example, if you are using PostgreSQL or MySQL, you can lock a row using commands like SELECT FOR UPDATE. This method is reliable but can cause performance issues as it requires a database connection for each cron execution.

Advantages:

Reliable and easily implemented with SQL or NoSQL databases.
Provides centralized locking due to integration with database transactions.

Disadvantages:

Can be costly in terms of database connections under heavy load.

Lock Record with Redis

Redis offers fast and lightweight data structures, making it very effective in locking mechanisms. Before a task starts, a lock is created in Redis (e.g., by setting a key), and it is removed once the task completes. Using a timeout with Redis can prevent locks from staying open indefinitely.

Advantages:

Redis is fast and has low latency.
Provides a centralized locking mechanism and is easily scalable.

Disadvantages:

If there are issues with the Redis connection, locks might remain open (though a TTL can mitigate this).
Requires a separate Redis service.

Monitoring with API Calls

In some projects, tasks are monitored through a central API. Each cron job assigns a “running” status in the API before starting, and this status is updated once the job completes. The API response determines whether the task is run only once. This approach is suitable for projects requiring complex and centralized monitoring.

Advantages:

Centralized control.
Makes task monitoring across systems or microservices easier.

Disadvantages:

Requires additional development (e.g., with a third-party app or shell scripts to make API calls).
API performance can slightly affect the efficiency of cron jobs.

Task Management Using Queues

Queue-based approaches are highly effective for processing tasks in sequence and reducing duplicate operations. By using BullMQ in NestJS, each cron job can be added to a queue and processed by only one instance. Queue structures are one of the most effective solutions for task management in multi-instance environments.

Advantages: Task processing in sequence and horizontal scalability compatibility.

Disadvantages: Requires additional dependencies (Redis, BullMQ) and configuration.

Adding Jobs to Queue in Multi-Instance Scenarios

In a multi-instance environment where each instance tries to add the same cron job to a queue, Unique Job Definitions can prevent duplicate jobs. BullMQ can block jobs with the same jobId from being added multiple times, ensuring that even if all instances try to queue the same job, it only gets added once.

Code Example - Redis Lock

Step 1: Create a Redis Client

To set up Redis, first create a Redis client using the ioredis package:

npm install ioredis

// redis.service.ts
import { Injectable } from '@nestjs/common';
import * as Redis from 'ioredis';

@Injectable()
export class RedisService {
  private client: Redis.Redis;

  constructor() {
    this.client = new Redis({
      host: 'localhost', // Redis server host
      port: 6379,        // Redis server port
    });
  }

  getClient(): Redis.Redis {
    return this.client;
  }
}

This service allows you to use the Redis client in other files via RedisService.

Step 2: Using Redis Lock Mechanism for Unique Cron Job Execution

Now, let's write a cron job function that implements locking using the Redis client. In this example, a lock is created in Redis before the task runs; if the lock is acquired, the job executes. Once the job is complete, the lock is released.

// task.service.ts
import { Injectable } from '@nestjs/common';
import { Cron, CronExpression } from '@nestjs/schedule';
import { RedisService } from './redis.service';

@Injectable()
export class TaskService {
  private readonly lockKey = 'cron-job-lock'; // Lock key
  private readonly lockTTL = 60; // Lock TTL in seconds

  constructor(private readonly redisService: RedisService) {}

  @Cron(CronExpression.EVERY_MINUTE)
  async handleCronJob() {
    const client = this.redisService.getClient();

    try {
      // Try acquiring the lock with NX (Only set if not exists) and EX (Expire time)
      const isLocked = await client.set(this.lockKey, 'locked', 'NX', 'EX', this.lockTTL);

      if (!isLocked) {
        console.log('This cron job is already running on another instance.');
        return;
      }

      // Start the job
      console.log('Cron job started: ', new Date().toISOString());

      // Place your cron job logic here
      await this.executeJob();

      console.log('Cron job completed.');
    } catch (error) {
      console.error('Error occurred during cron job:', error);
    } finally {
      await client.del(this.lockKey);
      console.log('Lock released.');
    }
  }

  private async executeJob() {
    return new Promise((resolve) => setTimeout(resolve, 5000)); // Example: 5-second delay
  }
}

Bonus PM2

PM2 is a popular process manager for running Node.js applications in production. It can launch applications with multiple instances, utilizing CPU cores efficiently. PM2’s cluster mode allows multiple instances of the same application to run and load balances requests across instances.

Managing Multiple Instances with PM2

Using the -i parameter, PM2 can start multiple instances. For example, to use the maximum CPU cores, run:

pm2 start app.js -i max

This command starts an instance on each CPU core. Each instance is assigned a unique ID using NODE_APP_INSTANCE, enabling tasks to be tagged with this ID.

Drawbacks of Multiple Instance Management with PM2

A significant drawback of PM2 is that it doesn’t provide failover or single-task control. If a job needs to be handled by only one instance, PM2 does not natively support this. In dynamic environments where instances are scaled up, PM2 doesn't continuously track the application's state, making it difficult to guarantee job consistency.

PM2 provides a basic solution for multi-instance management but lacks support for single-instance cron jobs. For more reliable duplication prevention, consider using Redis-based lock mechanisms or BullMQ in Kubernetes-managed environments.

Conclusion

This guide covers a common issue with multi-instance environments and provides solutions using different locking mechanisms. While the @nestjs/schedule library offers basic cron job support, it doesn't fully meet my expectations for multi-instance management as of this writing. There may be more alternatives, and I welcome any comments with suggestions on other options, including their pros and cons.

Good luck 😊

🔴 NestJS ile Cron İşlerini Yönetmek: Çoklu Instance Sorunlarını Çözme ve Locking Mekanizmaları

Fırat Emre ŞİRVAN — Thu, 14 Nov 2024 19:15:06 +0000

Çoklu Instance Ortamında Cron İşleri Neden Sorun Yaratır?

Cron işleri, arka planda belirli aralıklarla görev çalıştırmak için çok kullanışlıdır. Ancak, yatay ölçeklemeye sahip bir uygulamada, bir cron işinin aynı anda birden fazla instance tarafından çalıştırılması, tekrarlayan işlemlere ve veri tutarsızlıklarına yol açabilir. Örneğin, her bir instance’ın aynı veri kaydını güncellemeye çalışması veya belirli bir görevi tekrarlaması ciddi sorunlara neden olabilir. Bu sorunu çözmek için locking mekanizmaları kullanarak görevlerin yalnızca tek bir instance tarafından çalıştırılmasını sağlamalıyız.

NestJS'de Cron İşleri ile Çalışmak

NestJS, cron işleri için @nestjs/schedule modülünü sunar ve bu modül ile cron görevlerini kolayca yönetebiliriz. Bu modül, cron görevlerini zamanlamak için dekoratörler sağlar. Kurulum için öncelikle modülü ekleyelim:

npm install @nestjs/schedule

Modülü kurduktan sonra, @Cron, @Interval, ve @Timeout gibi dekoratörleri kullanarak görevlerimizi tanımlayabiliriz. Aşağıda, basit bir cron işinin nasıl tanımlandığını görebilirsiniz:

import { Injectable } from '@nestjs/common';
import { Cron, CronExpression } from '@nestjs/schedule';

@Injectable()
export class TasksService {
  // Dakikada bir çalışan bir cron görevi tanımlayalım
  @Cron(CronExpression.EVERY_MINUTE)
  handleCron() {
    console.log('Cron job çalışıyor: ', new Date().toISOString());
  }
}

Yukarıdaki örnekte, @Cron(CronExpression.EVERY_MINUTE) ifadesi, her dakika çalışacak bir cron işini belirtir. NestJS, @Cron dekoratörü ile farklı zaman aralıkları belirlemenize olanak tanır. Ancak bu iş, uygulamanızın birden fazla instance’ı olduğunda her instance tarafından çalıştırılır. Çoklu instance ortamında her cron işini yalnızca bir kez çalıştırmak için kilitleme (locking) mekanizmalarına ihtiyaç duyulur.

Locking Mekanizmaları: Çoklu Instance Sorunlarını Çözme Yöntemleri

Locking mekanizmaları, belirli bir görevin yalnızca bir instance tarafından çalıştırılmasını sağlar. Böylece tekrarlanan işlemler veya veri tutarsızlıkları önlenmiş olur. İşte en yaygın kullanılan dört locking yöntemi:

Veritabanı ile Pessimistic Lock

Veritabanı tabanlı pessimistic locking, özellikle SQL veritabanlarında tercih edilen bir yöntemdir. Bir görev başlamadan önce veritabanında bir satır kilitlenir ve işlem tamamlandığında bu kilit kaldırılır. Örneğin, PostgreSQL veya MySQL kullanıyorsanız, SELECT FOR UPDATE gibi komutlar ile satır kilitleyebilirsiniz. Bu yöntem oldukça güvenilirdir, ancak her cron çalışmasında veritabanı bağlantısı kurduğu için performans sorunlarına yol açabilir.

Avantajlar:

Güvenilir ve SQL, NoSQL destekli veritabanlarında kolayca uygulanabilir.
Veritabanı işlemlerine entegre olduğu için merkezi bir kilitleme sağlar.

Dezavantajlar:

Ağır yük altında veritabanı bağlantıları açısından maliyetli olabilir.

Redis ile Lock Kaydı

Redis, hızlı ve hafif bir veri yapısı sunar, bu nedenle locking mekanizmalarında oldukça etkilidir. Görev çalıştırılmadan önce Redis üzerinde bir kilit oluşturulup (örneğin bir anahtar değeri atanarak) görev sonunda bu kilit kaldırılır. Redis ile zaman aşımı (timeout) ekleyerek kilidin sonsuza kadar açık kalmamasını da sağlayabilirsiniz.

Avantajlar:

Redis hızlıdır ve düşük gecikme süresi sağlar.
Merkezi bir kilit mekanizması sunar ve kolay ölçeklenebilir.

Dezavantajlar:

Redis bağlantısında sorun oluşursa kilitler açık kalabilir. Tabi TTL eklediğimiz durumda bu dezavantajdan kurtulmuş oluruz.
Redis gibi bir harici depolama servisine ihtiyaç duyar.

API Call ile İzleme

Bazı projelerde merkezi bir API aracılığıyla görevlerin durumu izlenir. Her cron işi başladığında bu API’ye bir çağrı yapılarak “çalışıyor” durumu atanır ve iş bittiğinde bu durum güncellenir. API yanıtına göre görev yalnızca bir kez çalıştırılır. Bu yöntem, daha karmaşık ve merkezi bir izleme gerektiren projeler için uygundur.

Avantajlar:

Merkezi bir kontrol sağlar.
Çoklu sistemler veya mikro servislerde görev izlemeyi kolaylaştırır.

Dezavantajlar:

Ek geliştirme süreci gerektirir. Örneğin Api Call'ları atacak third party bir app vasıtasıyla veya curl istekleri atan sh kodlarıyla bu cron yönetilebilir.
API performansı cron işlerinin verimliliğini ufak da olsa etkileyebilir.

Queue (Kuyruk) Kullanımı ile Görev Yönetimi

Queue tabanlı yaklaşımlar, özellikle görevlerin sırayla işlenmesini sağlamada ve işlem tekrarı riskini azaltmada çok etkilidir. NestJS ile BullMQ kullanarak her cron işini bir kuyruğa ekleyebilir ve bu görevlerin yalnızca tek bir instance tarafından işlenmesini sağlayabilirsiniz. Queue yapısı, çok-instance ortamlarında görev yönetiminde en etkili çözüm yöntemlerinden biridir.

Avantajlar: Görevlerin sıralı işlenmesi, yatay ölçekleme uyumu

Dezavantajlar: Ek bağımlılıklar (Redis, BullMQ) ve yapılandırma ihtiyacı

Farklı Instance’ların Aynı İş İçin Queue’ya Ekleme Durumu

Çoklu instance ortamında her instance’ın aynı cron işini queue'ya eklemek istemesi durumunda, görev tekrarlarını önlemek için Unique Job (Benzersiz Görev) Tanımlanabilir. BullMQ, aynı jobId ile eklenen görevlerin birden fazla eklenmesini engelleyebilir. Bu sayede tüm instance’lar aynı işi queue’ya eklemeye çalışsa bile iş yalnızca bir kez eklenmiş olur.

Kod Örneği - Redis lock

Adım 1: Redis Client Oluşturma

İlk olarak, Redis bağlantısını ayarlamak için bir Redis client oluşturun. ioredis kütüphanesini kullanarak bağlantıyı kurabilirsiniz:

npm install ioredis

// redis.service.ts
// Redis/Cache servis oluşturmanın birçok yöntemi bulunmakta istediğiniz bir yöntemi entegre edebilirsiniz.
import { Injectable } from '@nestjs/common';
import * as Redis from 'ioredis';

@Injectable()
export class RedisService {
  private client: Redis.Redis;

  constructor() {
    this.client = new Redis({
      host: 'localhost', // Redis sunucusunun host adresi
      port: 6379,        // Redis sunucusunun port numarası
    });
  }

  getClient(): Redis.Redis {
    return this.client;
  }
}

Bu servis, diğer dosyalarda RedisService üzerinden Redis client’ını kullanmanıza olanak tanır.

Adım 2: Redis Lock Mekanizması ile Cron İşini Tekil Olarak Çalıştırma

Şimdi Redis client’ı kullanarak kilit işlemlerini gerçekleştiren bir cron iş fonksiyonu yazalım. Bu örnekte, Redis üzerinde bir kilit oluşturuluyor; kilit alınabiliyorsa iş çalıştırılıyor. İş tamamlandığında kilit kaldırılıyor.

// task.service.ts
// Ben loglarımı console.log olarak kullandım ama siz yerleşik Nestjs Logger'ı kullanabilirsiniz.
import { Injectable } from '@nestjs/common';
import { Cron, CronExpression } from '@nestjs/schedule';
import { RedisService } from './redis.service';

@Injectable()
export class TaskService {
  private readonly lockKey = 'cron-job-lock'; // Kilit anahtarı
  private readonly lockTTL = 60; // Kilit süresi (saniye cinsinden)

  constructor(private readonly redisService: RedisService) {}

  @Cron(CronExpression.EVERY_MINUTE)
  async handleCronJob() {
    const client = this.redisService.getClient();

    try {
      // NX (Only set if not exists) ve EX (Expire time) ile kilidi almayı deniyoruz.
      const isLocked = await client.set(this.lockKey, 'locked', 'NX', 'EX', this.lockTTL);

      // Eğer kilit alınamazsa işlem zaten başka bir instance tarafından yürütülmektedir.
      if (!isLocked) {
        console.log('Bu cron işi başka bir instance tarafından çalıştırılıyor.');
        return;
      }

      // İşlem başlıyor
      console.log('Cron job başlatıldı: ', new Date().toISOString());

      // Buraya cron işinin yapılacağı işlemleri ekleyin
      await this.executeJob();

      console.log('Cron job tamamlandı.');
    } catch (error) {
      console.error('Cron job çalıştırılırken hata oluştu:', error);
    } finally {
      // İşlem tamamlandığında veya hata oluştuğunda kilidi kaldır.
      // Bu kısım çok kritiktir. Eğer hata oluştuğunda kilit
      // kalkmazsa timeout süresi kadar cron çalışamaz hale gelir. 
      // Bu yüzden try ve finally'yi mutlaka kullanın. Dilerseniz 
      // catch kullanmayıp filterlarda yönetebilirsiniz. Daha doğru 
      // bir yaklaşım olur.
      await client.del(this.lockKey);
      console.log('Kilit kaldırıldı.');
    }
  }

  private async executeJob() {
    // Burada cron job işlemi yapılır
    return new Promise((resolve) => setTimeout(resolve, 5000)); // Örnek: 5 saniye bekleme
  }
}

Bonus PM2

PM2, Node.js uygulamalarını production ortamında yönetmek için yaygın olarak kullanılan bir process manager (işlem yöneticisi) aracıdır. Uygulamayı birden fazla instance ile çalıştırma imkanı sunarak CPU çekirdeklerini verimli kullanmayı sağlar. PM2, cluster mode ile aynı uygulamanın birden fazla örneğini başlatabilir ve load balancing (yük dengeleme) yaparak isteklere cevap verecek instance’ları otomatik olarak seçer.

PM2 ile Multiple Instance Yönetimi
PM2 ile -i parametresini kullanarak birden çok instance başlatabilirsiniz. Örneğin, maksimum CPU çekirdeğini kullanacak şekilde başlatmak için şu komut uygulanabilir:

pm2 start app.js -i max

Bu komut, uygulamanın her bir CPU çekirdeğinde bir instance başlatmasını sağlar. NODE_APP_INSTANCE gibi değişkenlerle her instance’a özel bir ID atanır, böylece farklı işlemler bu ID ile tanımlanabilir.

PM2 ile Multiple Instance Yönetiminin Dezavantajları

PM2’nin birden fazla instance yönetiminde önemli bir dezavantajı, kendi başına bir failover veya tekil işlem kontrolü sağlamamasıdır. Eğer bir işin yalnızca bir instance tarafından yürütülmesi gerekiyorsa, PM2 bu yönetimi doğrudan desteklemez. Dinamik ortamlarda instance’ların ölçeklendirilmesi gerektiğinde, PM2 uygulamanın durumunu sürekli takip etmediği için her instance bağımsız olarak çalışır ve iş sürekliliği garanti edilemez.

PM2, multiple instance yönetiminde başlangıç seviyesinde bir çözüm sunar, ancak özellikle cron işlerinin tek bir instance’ta çalışması gerektiğinde yetersiz kalabilir. Özellikle K8s gibi araçlarda yatay ölçeklendirmeyi de yönetemiyorsanız bu yöntemi kullanmanız imkansız hale gelir. Bu tür görevler için Redis tabanlı lock mekanizmaları veya BullMQ gibi araçlar, daha güvenilir bir yapı sağlayarak tekrar eden işleri tekilleştirmek için daha uygun olacaktır.

Kapanış

Örnekleriyle önemli bir ve çok yaygın bir sorunu ele almaya çalıştım. Aslında nestjs/scheduler kütüphanesinin bunu çok daha iyi ele almasını beklerdim fakat şu tarih itibariyle beklentimi karşılamadı. Bunun gibi daha birçok alternatif olabilir. Yorumlarda siz de bulduğunuz alternatifleri avantaj ve dezavantajlarıyla bahsedebilirseniz çok memnun olurum.

Kolay gelsin 😊

Nest 🆚 Express Hangi Framework'ü Seçmeliyim?

Fırat Emre ŞİRVAN — Tue, 13 Dec 2022 17:39:28 +0000

Nest vs Express, Hangi Framework'ü Seçmeliyim?

Bildiğiniz gibi son yıllarda node.js oldukça popüler. Node.js ile bir serverside application yapmak istediğimizde aklımıza ilk gelen framework Express.js oluyor. Öte yandan kendiliğinden bir template ile gelen ve çoğunlukla "opinionated" yaklaşımı benimsemiş Nest.js de son yıllarda oldukça popüler olmaya başladı.

Bu karşılaştırmadaki en temel madde, Nest gibi içerisinde birçok yapıyı barındıran bir framework'ü mü tercih etmek? Yoksa custom bir biçimde kendi yapımızı oluşturabildiğimiz çok daha esnek, yalın Express ile mi devam etmek olacak.

İlk olarak çok ufak Express ve Nest'i tanımlayıp akabinde hemen karşılaştırmaya geçeceğim.

Dipnot: Sürekli ingilizce kavramlar kullanacağım. Kavram olarak çoğunun karşılığını Türkçede bulamadım.

Express.js

Express, server-side uygulamalar oluşturmak için çok çeşitli işlevler sağlayan bir Node.js web uygulama çerçevesidir (framework). Express MVC mimarisini destekler. Fakat bunu kullanmak tamamen kullanıcıya kalır. Genel olarak "un-opinionated" bir yapı sergiler.

Basit bir Express uygulaması:

const app = express();

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000, () =>
  console.log('Example app listening on port 3000!'),
);

Gördüğünüz gibi birkaç satırla bir server ayağa kaldırabilirsiniz.

Nest.js

Nest de Express gibi server-side uygulamalar oluşturmamızı sağlayan bir Node.js framework'üdür. TypeScript ve JavaScript tabanlıdır. Yapı olarak Angular'ı oldukça andırır. Server-side uygulamalar oluştururken default olarak Express çatısını kullanır. Fakat platform agnostic'dir ve isterseniz Fastify gibi başka bir HTTP framework'ü de kullanabilirsiniz.

Not: Eğer Nest.js kullanırken Express'i tercih ettiyseniz Express'in özelliklerini de kullanabiliyorsunuz. Fakat çoğunluğu tavsiye edilmiyor ve Express üzerindeki Nest'in bize sunduğu yapıları kullanıyoruz.

Karşılaştırma

Opinionated VS Unopinionated

Opinionated mantığı, uygun bir tarza veya bir şeyler yapma yöntemine sahip olduğu anlamına gelir. Böylece çeşitli yapılar oluştururken size kılavuz olur. Ama aynı zamanda sizin uygulama alanınızdaki serbestliğinizi de bir ölçüde kısıtlar. Öte yandan Unopinionated frameworkler ise, geliştiricilere tam bir özgürlük verir, çok çeşitlidir, daha az yapılandırılmıştır. Farklı senaryoları test etmemiz için çok uygundur fakat bir yazılım ekibinde herkes aynı yöntemi kullanmayabilir. Bu da proje dallandıkça çeşitli sorunlara yol açacaktır. Aynı zamanda projeye yeni katılacak biri de oluşturulan yapıyı kolay bir biçimde çözemeyebilir.

Nest.js opinionated bir framework iken Express çoğu yerde unopinionated tutum sergiler Bir diğer deyişle Express.js daha önceden tanımlanmış (pre-defined) kurallara sahip değildir. Nest ise daha önceden tanımlı kurallara sahiptir.

Performans

Nest, uzun kod satırları yazmadan doğrudan komut vermenizi sağlayan CLI (Command Line Interface) içerir. Nest tarafında yapılan Dependency Injection, uygulamanızı sorunsuz bir şekilde çalıştırmak için ihtiyaç duyduğunuz kadar çok dependencies eklemenizi sağlar. Bu gibi özelliklerle Nest hem performansı kötü etkileyecek tarafları bizim ele almamızı engellerken hem de uğraşmamız gerekmeyen birçok satır koddan kurtarır.

Öte yandan Express'in asenkron yapısı ölçeklenebilir değildir.

Mimari (Architecture)

İkisi arasındaki bir diğer fark da mimarileridir. Nest, MVC tasarım modelini takip ederken, Express bunu tamamen size bırakır. Çoğunlukla gördüğüm projeler MVC ile yazılmaya çalışılsa da bu da önemli bir farklılıktır. Bu da Express tarafında enterprise level bir proje daha az optimize edilmiş veya yapı olarak daha karmaşık bir hal almış olabilir.

Ayrıca Nest ile kod yazarken bana hep Spring ve Angular'ı andırıyor. Daha çok OOP programming mantığını benimsiyor. Express ise daha çok FP, FRP gibi mantıklarda kod yazmamızı sağlıyor modeller harici class bile oluşturmamıza gerek kalmıyor.

Popülerlik

Express'in çok daha eski bir framework olması ve hem büyük ölçekli uygulamalar için hem de küçük uygulamalar için de kullanılabilir olması onu çok daha popüler kılıyor. Bu da daha büyük bir community'ye sahip kılıyor. Ve bu da unopinionated bir mantığa sahip framework için oldukça etkili oluyor.

Öte yandan Nest son 2021-2022 arasında npm ile 1 milyon ekstra haftalık indirme kazanmış.

Unit Testing

Daha önce bahsettiğimiz gibi Nest, burada da bize kılavuz oluyor. Unit Test, CLI'i ve Jest'te yapılandırılmış bir varsayılan test ortamı içerdiğinden, NestJS ile oldukça kolay ve hızlıdır.

Öte yandan Express içinde birçok yöntem ve başlık mevcut. Bunlardan en uygun olanı seçmek size kalmış.

Sonuç Olarak

Nest hem Java ve Angular benzeri bir yapısı ile yıllardır aşina olduğumuz OOP kavramını çokça kullanıyor.

Yalın Express'i seçecek olursak geniş community'si bize çeşitli boilerplate'lerle geliyor ve her takıldığımız yerde bize kılavuz oluyor. Fakat Express custom exception handler'ından custom architecture'ına kadar her kısmın seçimini bize bırakıyor bu da gerek güvenlik gerek performans gerek de sürdürülebilirlik olarak risk içeriyor. Yani Amerika'yı yeniden keşfetmiyoruz ve bizim için en uygun Amerikayı oluşturuyoruz. Fakat hata payı da mutlaka oluyor ve bu da maliyeti doğrudan etkiliyor.

Bence burada doğru bir SWOT analizi gerekiyor ve değerlendirilmesi gereken en önemli faktörler;

Ekip üyelerinin yetkinlikleri
Projeyi hazırlayanların sayısı
Ekip üyelerinin uyumu

oluyor.

Öte yandan hiç Express veya Nest tecrübeniz yok ise ve large scale bir application oluşturmak istiyorsanız burada önerim kesinlikle Nest olur. Nest ile çok daha az maliyetli ölçeklenebilir bir proje oluşturabilirsiniz.

Aralarındaki en temel farklara bu yazımda değinmeye çalıştım. Özellikle yeni bir projeye başlarkenki karar aşaması benim için çok yıpratıcıdır.

Bu türkçe içerikle yükünüzü hafiflettiysem ne mutlu bana 🙂. Okuduğunuz için teşekkür ederim. Bir sonraki yazımda görüşmek üzere.