Belajar NATS - Subjects & Wildcards

#Pendahuluan

Episode 3 membuat kalian terhubung. Episode 4 ini mengasah seni routing: subject adalah bahasa NATS, dan kalian harus fasih berbahasa. Pilihan penamaan subject menentukan seberapa mudah sistem kalian dipahami, diperluas, dan diamankan.

Kita akan membahas hierarki subject, best practice penamaan berbasis event-driven, perbedaan wildcard * dan >, serta implikasi keduanya terhadap permission dan subscription. Ini fondasi yang nantinya menentukan keamanan di episode 12-13.

#Hierarki Subject

#Subject sebagai Pohon Routing

Subject adalah string bertitik yang membentuk hierarki natural:

orders
  └── created
        └── eu
            └── de
  └── cancelled
payments
  └── charged

orders.created.eu.de adalah subjek paling spesifik; subscriber orders.> akan menerima semuanya. Hierarki ini murni konvensi penamaan — server tidak menyimpan tree — tapi ia memberikan kekuatan routing yang luar biasa.

#Subject Sebagai Perintah

Pola yang sangat umum: subject diawali kata kerja untuk memodelkan request. Misalnya auth.login, users.get, orders.process. Subscriber *.get bisa melayani semua permintaan baca. Pola ini berpasangan sempurna dengan request-reply yang akan dibahas di episode 5.

nats pub orders.created "pesanan-1"
nats pub orders.created.eu "pesanan-2"
nats pub orders.cancelled "pesanan-3"

nats pub orders.created.eu "pesanan-2" mengirim ke subject yang lebih spesifik; subscriber orders.created hanya melihat pesanan-1, sementara subscriber orders.> melihat ketiganya.

#Best Practice Penamaan Subject

#Konvensi Event-Driven

Penamaan yang baik mengikuti pola domain + entity + action. Ini membantu tim memahami semantik dari nama saja:

• orders.created, orders.shipped, orders.delivered — lifecycle pesanan.
• payments.charged, payments.refunded — kejadian pembayaran.
• user.registered — peristiwa pendaftaran pengguna.

Gunakan kata past tense untuk event yang sudah terjadi dan present tense untuk request yang masih berjalan. Konsistensi ini memudahkan pencarian dan permission.

#Aturan Penamaan

Beberapa aturan emas yang dipakai komunitas:

• Token dipisahkan titik, lowercase, tanpa spasi.
• Gunakan dot sebagai pemisah hierarki, bukan underscore.
• Hindari wildcard dalam penamaan — simpan untuk subscription.
• Dokumentasikan skema subject di awal project.

#Wildcard: * dan >

#Satu Token vs Sisa Token

Dua wildcard NATS memiliki perbedaan tegas:

• * mencocokkan tepat satu token pada posisinya.
• > mencocokkan satu atau lebih token dan hanya valid di akhir subject.

nats sub 'orders.*'
nats sub 'orders.>'

nats sub 'orders.*' menerima orders.created tetapi menolak orders.created.eu (dua token). nats sub 'orders.>' menerima keduanya sekaligus. Wildcard hanya boleh digunakan pada sisi subscription atau permission, bukan saat publish.

#Kombinasi Wildcard

Wildcard bisa dikombinasikan untuk pola yang presisi:

orders.*.eu     # orders.created.eu, orders.cancelled.eu
orders.>.de     # orders.created.eu.de, orders.cancelled.de
*.created       # orders.created, payments.created

Pola orders.*.eu mencocokkan semua event pesanan untuk region eu dengan tepat satu level aksi. Pemahaman presisi ini penting: wildcard terlalu luas bisa menangkap pesan yang tidak diinginkan.

#Implikasi Wildcard terhadap Permission

#Wildcard dalam Authorization

Wildcard tidak hanya untuk subscription — ia dipakai dalam permission per user di blok authorization. Perbedaan * dan > menjadi soal keamanan:

authorization {
  users = [
    { user: alice, permissions: {
      subscribe: { allow: ["orders.>"], deny: ["orders.internal"] }
      publish: { allow: ["orders.created", "payments.>"] }
    }}
  ]
}

Blok authorization di atas memberi alice hak subscribe semua subject orders kecuali yang berawalan orders.internal, dan hak publish hanya ke orders.created plus semua subject payments. Wildcard menentukan batas aman akses.

#Konflik Pencocokan

Perhatikan konflik: jika alice diizinkan orders.> tapi dilarang orders.internal, maka pesan orders.internal.something akan ditolak karena aturan deny lebih spesifik menang. Server mengevaluasi allow dan deny, dan deny yang lebih presisi memenangkan konflik.

Simulasi keputusan permission

def boleh_subscribe(user, subject):
    if subject.startswith("orders.internal"):
        return "TOLAK"
    if subject.startswith("orders"):
        return "IZIN"
    return "TOLAK"

Fungsi boleh_subscribe(user, subject) di atas menyederhanakan logika permission NATS: aturan deny yang spesifik mengalahkan allow yang luas. Prinsip inilah yang harus kalian ingat saat merancang multi-tenancy di episode 12.

#Penutup

Episode 4 mengajarkan bahasa routing NATS: hierarki subject yang berbentuk pohon, best practice penamaan berbasis event-driven dengan pola domain-entity-action, perbedaan wildcard * satu token dan > sisa token, serta implikasi keduanya terhadap permission dan konflik pencocokan.

Inti yang harus dibawa pulang:

• Subject adalah string bertitik yang membentuk hierarki tanpa deklarasi awal.
• Penamaan event memakai past tense; request memakai present tense.
• * mencocokkan satu token, > mencocokkan sisa token dan hanya di akhir.
• Wildcard dipakai untuk subscription dan permission, bukan saat publish.
• Aturan deny yang lebih spesifik memenangkan konflik dengan allow.
• Skema subject adalah kontrak API — rancang dengan hati-hati.

Di episode 5 selanjutnya kita akan membahas request-reply & queue groups — memakai nats request untuk pola RPC antar microservices, menangani timeouts, serta load balancing antar consumer dengan queue groups dan perbandingannya dengan competing consumers. Di sinilah NATS mulai terasa seperti tulang punggung microservices.