n8n'ün execution engine'inin içinde: 208 bin yıldızlı workflow aracı iş akışlarınızı gerçekte nasıl çalıştırıyor

Kendi sunucunuzda barındırılan, kod çıkış kapısına sahip bir Zapier alternatifi

n8n sıklıkla açık kaynak bir Zapier olarak anılır; dev.to'daki güncel derinlemesine bir inceleme, bu etiketin hem yararlı hem de yanıltıcı olduğunu savunuyor. Zapier kiraladığınız barındırılmış bir ürün; n8n ise kendi veritabanınıza yönlendirilen, uçtan uca size ait olan, kendinizin çalıştırdığı bir Node.js uygulaması. Görev başına ölçüm yok, satıcıya bağımlılık yok ve makaleye göre beş-on dolar aralığındaki bir VPS şaşırtıcı ölçüde fazla yükü taşıyabiliyor. Proje, fair-code lisansı altında yaklaşık 208.000 GitHub yıldızı topladı.

Yazarın asıl odağı ise bu tanıtım değil, mekanizmanın kendisi: Execute Workflow düğmesine tıklamakla canvas'ta yeşil onay işaretlerinin belirmesi arasında neler olduğudur. Bu davranış — node'ları planlamak, join'leri eşzamanlamak, çalışmaları iptal edilebilir tutmak, lifecycle hook'larını yaymak — yaklaşık 1.250 satırlık TypeScript kodunda yaşar.

Tek bir serileştirilebilir nesne ve tek bir döngü

Makaleye göre n8n her node için bir thread oluşturmuyor. Çalışmayı bekleyen node'lardan oluşan aktif stack'i, kısmen karşılanmış girdiler için bir waiting map'i, metadata'yı ve nihai sonuçları taşıyan tek bir serileştirilebilir çalışma nesnesi, IRunExecutionData, oluşturuyor. Aynı nesne editörden sunucuya, oradan engine'e, isteğe bağlı olarak Redis kuyruğu üzerinden bir worker sürecine ve geri kez seyahat ediyor.

Engine — çekirdek paketteki WorkflowExecute — stack'i başlangıç node'u ile tohumluyor ve sonra döngüye giriyor: en öndeki girdiyi al, node'u çalıştır, sonucu kaydet, aşağı akıştaki node'ları kuyruğa ekle. Gizli bir thread havuzu yok, sihirli bir graph walker yok. Sadece bir stack ve bir waiting map var.

Yürütme sırası tek bir satıra indirgeniyor

Makale, executionOrder ayarını en önemli workflow ayarı olarak öne çıkarıyor; çünkü bu ayar zamanlayıcıdaki tek bir satırı değiştiriyor. v0 sürümü yeni işi kuyruğun sonuna ekliyor, böylece daha eski iş önce çalışıyor ve yürüme genişlik öncelikli hissediliyor: derinlik birdaki tüm kardeşler, derinlik iki başlamadan bitiyor. v1 sürümü yeni işi öne ekliyor, böylece mevcut dal çalışmaya devam ediyor ve yürüme derinlik öncelikli hissediliyor.

Bu ayar zamanlamayı değiştirir, grafı değil. v1'de kardeş sıralaması hâlâ canvas konumunu izliyor — önce sol üst — ama yalnızca gerçekten hazır olan kardeşler arasında. Canvas yürütme grafiği değildir; yalnızca zamanlayıcının serbest olduğu yerlerde sıralamayı şekillendirir.

Join'ler, boş dallar ve döngüler

İki girdili bir node, ilk dal geldiğinde tetiklenmez. Engine kısmi veriyi girdi başına yer tutucularla waiting map'te bekletir ve node'u yalnızca gerekli her girdi boş değil olduğunda kuyruğa ekler. Ana stack boşaldıktan sonra bir süpürme işlemi, artık yeterli veriye sahip olan beklemedeki herhangi bir node'u ileri çeker — isteğe bağlı girdiler boş kalmış olsa bile — böylece bir dal erken ölürse bir join yine de tamamlanabilir.

Makaleye göre boş çıktı normalde bir dalı bitirir; ancak node alwaysOutputData değerini true yaparsa engine, aşağı akıştaki node'ları çalışmaya devam ettirmek için tek bir boş item üretir. Döngülere özel bir muamele yok: bir node yalnızca kendi için daha fazla iş planlarsa döngüye girer, tıpkı batch bölme node'unun döngü durumunu kendi bağlamında saklaması gibi; bir döngü koruması ise aynı node ve çalışma indeksi ilerleme olmadan geri döndüğünde kazara tekrarları durdurur.

Queue modu: aynı engine, daha çok süreç

Standalone modunda ana süreç iş akışlarını doğrudan yürütür. EXECUTIONS_MODE queue olarak ayarlanan queue modunda ise ana süreç BullMQ üzerinden Redis'e bir iş ekler ve hemen geri döner; bir worker bu işi kuyruktan çıkarır, aynı çalışma nesnesini yeniden oluşturur, özdeş engine döngüsünü çalıştırır ve sonuçları PostgreSQL'e yazar. Worker'lar durumsuzdur ve kuyruk derinliğine göre yatayda ölçeklenebilir; kod node'ları ise izole task-runner sidecar'larda çalışır — JavaScript için isolated-vm ile V8 isolate'leri, Python için ayrı süreçler — WebSocket RPC üzerinden haberleşir.

Altında üç katmanlı bir veri modeli yatar: node'lar arasında akan item'lar, her node'un geçmişine eklenen çalışma başına görev kayıtları ve sonuçları canlı makine durumuyla birlikte paketleyen execution nesnesi. Yazar, bu paketlemenin n8n'ün bir çalışmayı queue worker'ına devretmesini veya bir Wait node'unda duraklatıp sonra devam ettirmesini mümkün kılan şey olduğuna dikkat çekiyor.

Neden önemli

Otomasyon platformları kenar noktalarında başarılı olur ya da başarısız olur: beklemesi gereken join, sessizce ölen dal, hiç sonlanmayan döngü. dev.to incelemesi, n8n'ün kenar davranışının anlaşılmaz bir mekanizma yerine küçük ve okunabilir bir kural kümesiyle — bir stack, bir waiting map, birkaç ayar — yönetildiğini gösteriyor. Zapier ile karşılaştıran ekipler için asıl argüman bu okunabilirliktir: davranış sizi şaşırttığında cevap birkaç yüz satır TypeScript ötesindedir ya da engine'i hiç okumak yerine bir Code node'uyla JavaScript ya da Python'da düzeltmeyi tercih ediyorsanız oradadır.