Javascript import ve requeire farkı

6 Oca

Javascript dilinde import ve require anahtar kelimeleri, modülleri kod içerisine aktarmak için kullanılır. Modülleri yüklerken NodeJS tarafında require kullanılırken, Ecmascript 6 tarafında import kullanılır.

NodeJS de kullanılan require, modülleri senkron bir şekilde yükler. Yani modül yüklenene kadar kod bloke olur ve yükleme işleminden sonra kullanılabilir. Ecma script ile kullanılan import ise modülü asenkron olarak yükler ve kod yükleme sırasında bloke olmaz.

require ve import arasındaki temel fark, require sadece modül içeri aktarma işlemi sırasında kullanılırken, import hem tüm modülün içeri aktarımı, hem de ihtiyaç halinde bir modül içerisinden tek başına export edilmiş türlerin aktarımı için kullanılır. Tek başına export edilen türler birer fonksiyon, sabit, nesne olabilir.

require ile modül yükleme

Örneğin math modülünü require ile yüklemek için aşağıdaki komut kullanılır.

const math = require('math');

math modülüne ait tekil bir export edilmiş tipi yüklemek için:

const log = require('math').log;

import ile modül yükleme

Örneğin math modülünün tümünü import ile yüklemek için aşağıdaki komut kullanılır.

import * as math from 'math';

math modülüne ait tekil bir export edilmiş tipi yüklemek için:

import {log} from 'math';

math modülüne ait tekil olarak birden fazla export edilmiş tipi yüklemek için:

import {log, factorial} from 'math';

import()

Math modülünün tanımlanması:

// math.js
export const pi = 3.14;
export const e = 2.71828;

Math modülünün calculate modülüne yüklenmesi.

// calculate.js
import { pi, e } from './math';
console.log(pi); // output 3.14
console.log(e); // output 2.71828

Mikroservis Repository Yapılandırması

6 Oca

Mikroservis yaklaşımında, kod depolama için iki seçenek bulunur. Birincisi tüm servislerin tek bir repository içerisinde tutulması. İkincisi her bir servis için ayrı repository oluşturulması.

Tek bir repository kullanımı

Genel olarak, tüm mikro servislerde tek bir repository tercih edilebilir, ancak kod büyüdükçe her bir servis için bir alt klasör dizini ve proje yapısını yönetmek zor olabilir. Tüm mikroservisleri tek bir havuza koymaya karar vermeden önce dikkate alınması gereken şeyler şunlardır:

Developer Sınırlarının Belirlenmesi

Tüm mikroservislerin kodu tek bir havuzda olduğundan, aralarında gerçek bir fiziksel sınır yoktur. Bu nedenle geliştiriciler, projeler arasında bir referans veya benzeri eklemeler yaparak diğer mikroservislerdeki bazı kodları kullanabilirler. Tüm mikroservislerin tek bir havuzda olması, geliştiricilerin sınırları aşmaması ve bunları yanlış kullanmaması için biraz disiplin ve kurallar konulması gerektirecektir. Kod sınırları belirlenmediğinde, developer sınırları belirlemek durumunda kalınabilir.

Paylaşılan Kod Oluşumu

Kod altyapısında servislerde ortak kullanılabilecek kodların cazibesine kapılarak, paylaşılan kodlar kümesi oluşabilir. Birbirinden bağımsız servisler oluşturmak amacıyla çıkılan mikroservis yolunda bağımlılıklar oluşmaya başlayabilir. Normalde ortak kullanılan kodlar paketlenerek Nuget, Npm gibi depolara aktarılarak kullanmak uygundur. Doğrudan kod repository içerisinde bağımlılık oluşturmak, servislerin bağımsız geleceği açısından uygun değildir.

Git Yönetimi

Çok fazla ekip üyesinin bir repository üzerinde çalışması pull request ve branch yönetimi açısından zordur. Sürekli gelen commit talepleri ve merge ile çakışmalar artabilir. Bir ekibi ilgilendirmeyen değişikliklerin bildirim mesajları, mailleri o ekibe de düşmeye başlar.

CI/CD Süreçleri

Kodu oluşturmak, test etmek ve/veya dağıtmak için Azure DevOps, Jenkins gibi araçlar kullanıldığında, Jenkins ve GitHub arasındaki entegrasyon gibi bazı yapılandırma güçlükleriyle karşılaşabilirsiniz. Birisi herhangi birmikroservise karşı bir merge/pull request isteği oluşturursa, yalnızca kodun belirli bir bölümünü (ilgili mikroservisi) oluşturacak/test edecek bir ardışık düzen yapılandırmak gerekir. Buna uygun bir yöntem de bulmak gerekecek. Kodda ilgili klasörde veya tag işleminde bir değişiklik olduğunda ilgili build adımının çalışması ve bir docker imaj çıkarması gibi senaryolar oluşturmak gerekebilir. Aynı senaryolar deployment adımları için de geçerlidir.

Sonuç

Bu sorunların tümü veya çoğu, bazı ekstra yönetim ve yapılandırma ile çözülebilir, ancak yine de ne kadar ek çabayla karşılaşabileceğinizi iyi tasarlamak gerekir. Bu nedenle genel tavsiye, mümkünse her bir mikroservis için ayrı repository kullanmak olacaktır.