mevcut API'yı özel uç noktalarla genişletme

Birden fazla müşteri için bir API oluşturuyorum. Gibi temel uç noktalar /usersher müşteri tarafından kullanılır, ancak bazı uç noktalar bireysel özelleştirmeye dayanır. Bu nedenle, A Kullanıcısı özel bir uç nokta istiyor olabilir /groupsve başka hiçbir müşterinin bu özelliği olmayacaktır. Tıpkı bir sidenote gibi , her müşteri bu ekstra özellikler nedeniyle kendi veritabanı şemasını da kullanacaktı.

Şahsen NestJs'i kullanıyorum (kaputun altında Express). Yani app.moduleşu anda (vb kendi uç noktaları ile) tüm çekirdek modüllerini kaydeder

import { Module } from '@nestjs/common';

import { UsersModule } from './users/users.module'; // core module

@Module({
  imports: [UsersModule]
})
export class AppModule {}

Bu sorunun NestJs ile ilgili olmadığını düşünüyorum, bu yüzden teoride bunu nasıl ele alırsınız?

Temel olarak temel bir sistem sağlayabilecek bir altyapıya ihtiyacım var. Artık hiçbir çekirdek uç nokta yok çünkü her uzantı benzersizdir ve birden fazla /usersuygulama mümkün olabilir. Yeni bir özellik geliştirirken çekirdek uygulamaya dokunulmamalıdır. Uzantılar kendilerini entegre etmeli veya başlangıçta entegre olmalıdır. Çekirdek sistem uç nokta olmadan gönderilir ancak bu harici dosyalardan genişletilir.

Bazı fikirler aklıma geliyor

İlk yaklaşım:

Her uzantı yeni bir havuzu temsil eder. Tüm bu uzantı projelerini tutan özel bir harici klasörün yolunu tanımlayın. Bu özel dizin bir klasör içerecektir groupsa ilegroups.module

import { Module } from '@nestjs/common';

import { GroupsController } from './groups.controller';

@Module({
  controllers: [GroupsController],
})
export class GroupsModule {}

API'm bu dizine göz atabilir ve her modül dosyasını içe aktarmayı deneyebilir.

• Artıları:

  1. Özel kod, çekirdek depodan uzak tutulur

• Eksileri:

  1. Önce kodu derlemek zorunda NestJs Typescript kullanır. API uygulamalarını ve yapılarını özel uygulamalardan nasıl yönetirim? (Tak ve çalıştır sistemi)

  2. Özel uzantılar çok gevşek çünkü sadece bazı daktilo dosyaları içeriyorlar. API'nın node_modules dizinine erişemedikleri için, editörüm dış paket bağımlılıklarını çözemediği için bana hatalar gösterecek.

  3. Bazı uzantılar başka bir uzantıdan veri alabilir. Belki grup hizmetinin kullanıcı hizmetine erişmesi gerekir. Burada işler zorlaşabilir.

İkinci yaklaşım: Her uzantıyı API'nın src klasörünün bir alt klasöründe tutun. Ancak bu alt klasörü .gitignore dosyasına ekleyin. Artık uzantılarınızı API içinde tutabilirsiniz.

• Artıları:

  1. Editörünüz bağımlılıkları çözebilir

  2. Kodunuzu dağıtmadan önce build komutunu çalıştırabilirsiniz ve tek bir dağıtımınız olur

  3. Diğer hizmetlere kolayca erişebilirsiniz ( /groupsbir kullanıcıyı kimliğe göre bulmanız gerekir)

• Eksileri:

  1. Geliştirirken, depo dosyalarınızı bu alt klasörün içine kopyalamanız gerekir. Bir şeyi değiştirdikten sonra bu dosyaları geri kopyalamanız ve depo dosyalarınızı güncellenmiş olanlarla geçersiz kılmanız gerekir.

Üçüncü yaklaşım:

Harici bir özel klasörün içinde, tüm uzantılar tam teşekküllü bağımsız API'lardır. Ana API'niz yalnızca kimlik doğrulama öğelerini sağlar ve gelen istekleri hedef API'ye yönlendirmek için bir proxy görevi görebilir.

• Artıları:

  1. Yeni uzantılar kolayca geliştirilip test edilebilir

• Eksileri:

  1. Dağıtım zor olacak. Kendi işlemlerini başlatan ve bir bağlantı noktasını dinleyen bir ana API ve n uzantı API'sına sahip olacaksınız .

  2. Proxy sistemi zor olabilir. İstemci /users, proxy'nin bu uç nokta için hangi uzantı API'sını dinlediğini bilmesini isterse , bu API'yı çağırır ve bu yanıtı istemciye iletir.

  3. Uzantı API'larını korumak için (kimlik doğrulama ana API tarafından gerçekleştirilir) proxy'nin bu API'larla bir sır paylaşması gerekir. Dolayısıyla, uzantı API'si yalnızca gelen istekleri proxy'den sağladığında gelen istekleri iletir.

Dördüncü yaklaşım:

Mikro hizmetler yardımcı olabilir. Buradan bir rehber aldım https://docs.nestjs.com/microservices/basics

Kullanıcı yönetimi, grup yönetimi vb. İçin bir mikro hizmet alabilir ve bu mikro hizmetleri çağıran küçük bir api / ağ geçidi / proxy oluşturarak bu hizmetleri tüketebilirim.

• Artıları:

  1. Yeni uzantılar kolayca geliştirilip test edilebilir

  2. Ayrılmış endişeler

• Eksileri:

  1. Dağıtım zor olacak. Kendi işlemlerini başlatan ve bir bağlantı noktasını dinleyen bir ana API ve n mikro hizmetiniz olacaktır .

  2. Özelleştirilebilir olmasını istiyorsanız, her müşteri için yeni bir ağ geçidi API'si oluşturmam gerektiği anlaşılıyor. Bu nedenle, bir uygulamayı genişletmek yerine, her seferinde özelleştirilmiş bir ortak API oluşturmam gerekiyordu. Bu sorunu çözmezdi.

  3. Uzantı API'larını korumak için (kimlik doğrulama ana API tarafından gerçekleştirilir) proxy'nin bu API'larla bir sır paylaşması gerekir. Dolayısıyla, uzantı API'si yalnızca gelen istekleri proxy'den sağladığında gelen istekleri iletir.

Buna birkaç yaklaşım var. Yapmanız gereken, ekibiniz, kuruluşunuz ve müşterileriniz için en uygun iş akışının hangisi olduğunu bulmaktır.

Bu bana kalmış olsaydı, modül başına bir havuz kullanmayı ve yapılandırmayı işlemek için özel veya kuruluş kapsamındaki paketlerle NPM gibi bir paket yöneticisi kullanmayı düşünürdüm. Ardından yeni sürümlerde paket deposuna aktarılan derleme yayın boru hatlarını ayarlayın.

Bu şekilde tek ihtiyacınız olan ana dosya ve özel kurulum başına bir paket bildirim dosyasıdır. Yeni sürümleri bağımsız olarak geliştirebilir ve dağıtabilirsiniz ve istemci tarafında gerektiğinde yeni sürümler yükleyebilirsiniz.

Daha fazla pürüzsüzlük için, modülleri rotalara eşlemek ve önyüklemenin çoğunu yapmak için genel bir rota oluşturma komut dosyası yazmak için bir yapılandırma dosyası kullanabilirsiniz.

Bir paket herhangi bir şey olabileceğinden, paketlerdeki çapraz bağımlılıklar fazla uğraşmadan çalışacaktır. Değişim ve sürüm yönetimi söz konusu olduğunda sadece disiplinli olmanız gerekir.

Özel paketler hakkında daha fazla bilgiyi buradan edinebilirsiniz: Private Packages NPM

Şimdi Özel NPM kayıtları maliyetlidir, ancak bu bir sorunsa başka seçenekler de vardır. Lütfen ücretsiz ve ücretli bazı alternatifler için bu makaleyi inceleyin.

Özel npm kaydınızı almanın yolları

Şimdi kendi yöneticinizi devretmek istiyorsanız, kodu repodan almak, yüklemek ve daha sonra almak için bir tür yöntem sağlamak için gerekli bilgileri içeren basit bir servis bulucu yazabilirsiniz. örnek.

Böyle bir sistem için basit bir başvuru uygulaması yazdım:

Çerçeve: lokomotif servis bulucu

Palindromlar için örnek bir eklenti kontrolü: lokomotif eklentisi örneği

Eklentileri bulmak için çerçeveyi kullanan bir uygulama: lokomotif uygulaması örneği

Aşağıdaki şemaya sahip npm install -s locomotionbir plugins.jsondosya belirtmeniz gerekecek şekilde kullanarak npm'den alarak bunu oynayabilirsiniz :

{
    "path": "relative path where plugins should be stored",
    "plugins": [
        { 
           "module":"name of service", 
           "dir":"location within plugin folder",
           "source":"link to git repository"
        }
    ]
}

misal:

{
    "path": "./plugins",
    "plugins": [
        {
            "module": "palindrome",
            "dir": "locomotion-plugin-example",
            "source": "https://github.com/drcircuit/locomotion-plugin-example.git"
        }
    ]
}

şu şekilde yükleyin: const loco = requir ("hareket");

Daha sonra, hizmetlerinizi ele geçirmek için konum belirleyici yöntemine sahip olan hizmet bulucu nesnesini çözecek bir söz döndürür:

loco.then((svc) => {
    let pal = svc.locate("palindrome"); //get the palindrome service
    if (pal) {
        console.log("Is: no X in Nixon! a palindrome? ", (pal.isPalindrome("no X in Nixon!")) ? "Yes" : "no"); // test if it works :)
    }
}).catch((err) => {
    console.error(err);
});

Lütfen bunun yalnızca bir referans uygulaması olduğunu ve ciddi uygulamalar için yeterince sağlam olmadığını unutmayın. Bununla birlikte, desen hala geçerlidir ve bu tür bir çerçeveyi yazmanın özünü gösterir.

Şimdi, bu eklenti yapılandırması, başlatmalar, hata kontrolü, belki de bağımlılık enjeksiyonu için destek eklemek vb.

Harici paketler seçeneğini tercih ediyorum.

Uygulamanızı bir packagesklasöre sahip olacak şekilde yapılandırabilirsiniz . Bu klasörde UMD derlenmiş dış paketler derlenmiş olurdu, böylece derlenmiş yazı tipi paketleri ile herhangi bir sorun olmaz. Tüm paketlerin index.jsher paketin kök klasöründe bir dosya olmalıdır .

Ve uygulamanız, paketleri fsve requiretüm paketleri index.jsuygulamanızda kullanarak bir döngü çalıştırabilir .

Sonra tekrar bağımlılık kurulumu dikkat etmeniz gereken bir şeydir. Her paketteki bir yapılandırma dosyasının da bunu çözebileceğini düşünüyorum. npmUygulamayı başlatmadan önce tüm paket bağımlılıklarını yüklemek için ana uygulamada özel bir komut dosyanız olabilir .

Bu şekilde, paketi paketleri klasörüne kopyalayıp uygulamayı yeniden başlatarak uygulamanıza yeni paketler ekleyebilirsiniz. Derlenmiş yazı tipi dosyalarınıza dokunulmaz ve kendi paketleriniz için özel npm kullanmak zorunda kalmazsınız.