Backend'ler

Özet

Bir backend, platformun bileşim katmanıdır: parametreleri ve dosyaları bağlanmış, deploy etmeye hazır component release'lerinden oluşan tipli bir graf. Component'ler kodun ne yaptığını tanımlar; backend'ler ise o kodla belirli bir ürün iş akışının ne yaptığını tanımlar.
Bir backend bir betik değil, bir nesnedir: incelenebilir, düzenlenebilir, geri alınabilir, yeniden deploy edilebilir ve üretimdeki tam component release'i için sorgulanabilir. Platform mutasyon yüzeyine sahiptir; her değişikliğin nasıl kaydedildiğini ve geri alındığını Backend işlemleri sayfasında görün.
Platform, grafı düzenleme zamanında tip-kontrolünden geçirir, yalnızca deploy zamanında değil. Bir Image output'unu bir [BoundingBox] input'una bağlamak, daha sonra bir container içinde bir runtime hatası olarak ortaya çıkmak yerine, edge'i adlandıran kesin bir hatayla anında reddedilir.
Backend'ler, kayan etiketleri değil, belirli component release sürümlerini sabitler. Yeni bir component release'inin promote edilmesi, daha eski bir release'e karşı zaten kablolanmış herhangi bir backend'i sessizce değiştirmez.
Bir backend, çalışan kod değildir. Bir ürün iş akışının kontrol edilmiş tanımıdır. Onu çalıştırmak bir deployment'ın işidir; backend'in kendisi, incelenebilir, geri alınabilir, yeniden deploy edilebilir graf tanımı olarak kalır.

Bir backend gerçekte nedir

Bir backend, Pipelogic'in bir ürünün iş akışını nasıl temsil ettiğidir: component yeteneklerinin tipli, kontrol edilmiş, yeniden üretilebilir bir bileşimi. Component'ler kodun ne yaptığını tanımlar; bir backend, belirli bir ürünün o kodla ne yaptığını tanımlar ve bunu, component'lerin etrafına sarılmış orkestrasyon kodu olarak değil, açık, incelenebilir bir nesne olarak yapar.

Bileşimi birinci sınıf bir nesne olarak modellemek, iş akışının kendisini işletilebilir kılan şeydir. Backend bir nesne olduğu ve betik olmadığı için, bir takım arkadaşı tarafından incelenebilir, bir araç tarafından düzenlenebilir, kötü bir değişiklikten sonra geri alınabilir, yeniden derlenmeden yeniden deploy edilebilir ve üretimde gerçekte hangi component release sürümünün olduğu için sorgulanabilir. Sistemin şekli, dosyalara ve yazarın hafızasına yayılmış yapıştırıcı kod değil, graftır ve component'lerin bildirdiği tip garantileri, portlar elle bağlandığında kaybolmak yerine kablolama boyunca taşınır.

Bir backend bir graftır: vertex'ler sabitlenmiş component release sürümleri artı her birine bağlanmış parametreler ve dosyalardır; edge'ler tipli output akışlarını uyumlu tipli input akışlarına bağlar; tüm yapı yeniden üretilebilirdir çünkü ona yapılan her değişiklik, backend'in günlüğündeki kaydedilmiş bir işlemdir. Backend incelenebilir, düzenlenebilir, geri alınabilir, compact edilebilir, tip-kontrolünden geçirilebilir, deploy edilebilir, yeniden deploy edilebilir, fork'lanabilir ve hakkında akıl yürütülebilir, çünkü kodun bir yan etkisi değil, birinci sınıf bir nesnedir.

Ayrım kasıtlıdır: bileşim, component'te değil, backend'de yaşar. Bir component yetenektir; backend, o yeteneğin belirli bir iş akışındaki kullanımıdır. Tek bir component, her biri onu farklı yukarı-akışlara kablolayan, farklı parametreleyen, farklı dosyalar bağlayan birçok backend'de bir vertex olarak yer alabilir. İşte bu yüzden bir kez iyi bir dedektör inşa etmek, ürün başına fork'lanmak yerine birçok ürüne hizmet edebilir. Bu, mikro-servislerin standart modülerlik kazancıdır — bağımsız sürümlenmiş, yeniden kullanılabilir yetenekler — alışılmış vergi olmadan: servis başına yapıştırıcı kod yok, işletilecek bir orkestrasyon katmanı yok, sözleşme kayması yok, çünkü kablolama, her takımın elle bakımını yaptığı kod yerine platformun kontrol ettiği tipli bir graftır.

Zihinsel model

   ┌──────────────────────────────────────┐
   │ input_image_http                     │
   │ ()  →  (Image, String)               │
   └──────────────────────────────────────┘
     vertex 1
           │  out 0 → Image
           ▼
   ┌──────────────────────────────────────┐
   │ convert_image_format                 │
   │ Image  →  Image                      │
   │ color_model=RGB                      │
   └──────────────────────────────────────┘
     vertex 2
           │  out 0 → Image
           ▼
   ┌──────────────────────────────────────┐
   │ detect_objects_ultralytics_yolo      │
   │ Image  →  [BoundingBox]              │
   │ threshold=0.4 · model=<file>         │
   └──────────────────────────────────────┘
     vertex 3

Her vertex, sabitlenmiş bir release sürümü artı bağlamalarıdır — aynı release üzerindeki farklı parametrelere veya farklı dosya bağlamalarına sahip iki vertex farklı vertex'lerdir. Her edge (from-vertex, from-output) → (to-vertex, to-input)'tur: input'lar en fazla bir yukarı-akış edge'i kabul eder, output'lar birden fazla tüketiciye dağılabilir. Deploy edilen şey tüm yapıdır; bir deployment hakkında hiçbir şey örtük değildir.

Bir vertex'in sabitlediği birim için Component'ler sayfasına ve edge'lerin karşıladığı sözleşme için Tipler sayfasına bakın.

Graf, açıp düzenlediğiniz bir dosya olarak saklanmaz; platform mutasyon yüzeyine sahiptir, her değişiklik kaydedilmiş bir işlemdir ve mevcut graf, o günlüğün yeniden oynatılmasıyla türetilir. İşlem sözcük dağarcığı, her değişikliğin nasıl geri alındığı ve compact semantiği için Backend işlemleri sayfasına bakın.

Tip sistemi kablolamayı düzenleme zamanında yakalar

Bir connect işleminin neden reddedildiğini anlamak için bu çerçeveyi kullanın.

Her component, akışlarının her birinin tipini component.yml'sinde bildirir. Bir backend iki vertex'i kabloladığında, platformun tip çıkarımı, önerilen edge boyunca ve tüm graf boyunca çalışır ve bağlantının sağlam olup olmadığını belirler. Bir Image output'unun bir [BoundingBox] input'una bağlanması, edge'i ve çakışmayı adlandıran bir hatayla reddedilir. Bir Maybe<String>'in bir String'e bağlanması reddedilir (sarmalama önemlidir). Genel bir [t]'nin bir [Image]'e bağlanması, yalnızca t graftaki başka bir yerde tutarlı bir şekilde Image olarak somutlaşırsa kabul edilir.

Kontrol, yalnızca deploy zamanında değil, düzenleme zamanında çalışır. Bu yük taşıyan ayrıntıdır. Düzenleme anında doğrulamak, bir tip uyuşmazlığının deploy edilmiş bir container içindeki bir runtime çökmesi olarak değil, ona neden olan işlem üzerinde raporlanması anlamına gelir. Bir bağlantı sağlam olmadığında işlem kaydedilmez, graf geçerli kalır ve düzenlemeyi düzeltip devam edersiniz.

Aynı kontrol deploy zamanında yeniden çalışır ve kasıtlı olarak aynı makinedir — deploy zamanı kontrolü, düzenleme zamanı kontrolünden daha katı değildir. Platformun kabul ettiği bir düzenleme, deploy zamanında yeniden kabul edilir. Bu simetri, backend yazarlarının düzenleme zamanı geri bildirimine güvenmesini sağlayan şeydir.

Kontrolün karşı çalıştığı tip sistemi için Tipler sayfasına bakın.

Mutable bağlamalar ile topoloji değişiklikleri

Bir backend düzenlemesinin redeploy gerektirip gerektirmediğini merak ettiğinizde bu çerçeveyi kullanın.

Bir backend grafına yapılan çoğu düzenleme redeploy gerektirir: bir vertex eklemek, bir vertex kaldırmak, bir vertex'in sabitlenmiş release sürümünü değiştirmek, edge'leri bağlamak veya bağlantısını kesmek, farklı bir dosya bağlamak veya mutable: true olarak bildirilmemiş bir parametreyi değiştirmek. Bunlar topoloji değişiklikleridir — çalışan container'lar artık yeni grafla eşleşmez, bu yüzden değiştirilirler.

Küçük bir düzenleme kümesi redeploy gerektirmez. Component'in config_schema'sında mutable: true olarak bildirilen parametreler, çalışan deployment'a karşı güncellenir: platform yeni değeri çalışan container'a iter ve component, bir sonraki çağrıda onu subscribe-config yolu üzerinden okur. Bu, eşik değerleri, runtime ayar düğmeleri ve component yazarının yeniden deploy etmeden canlı ayarlamak için güvenli olarak işaretlediği herhangi bir parametre için geçerlidir.

Topoloji değişikliklerinin mutable bir karşılığı yoktur. Bir vertex'in canlı eklenmesi ve bir edge'in canlı yeniden kablolanması yoktur; bu değişiklikler grafı yeniden tanımlar ve runtime eşleşmesi için yeniden deploy edilir. Aynısı dosya bağlamaları için de geçerlidir — runtime, dosyaları container başlangıcında mount eder, bu yüzden yeniden bağlama yeni bir container gerektirir.

Tasarım, mutable parametrelerin backend tarafından değil, component tarafından bildirilmesini zorunlu kılar. Component yazarı hangi parametrelerin runtime için güvenli olduğuna karar verir; backend operatörü canlı ayarlama için tam olarak o yüzeyi alır ve başka bir şey almaz. Bu ayrım, canlı değiştirilmesi güvenli olmayan parametrelerin canlı düzenlenebilir olarak ele alınmasını engeller.

Bir backend'i fork'lamak ne demektir

İki paralel ortama ihtiyacınız olduğunda bunu kullanın — staging vs üretim, A vs B, mavi vs yeşil.

Bir backend ile deployment'ı arasındaki bağlantı 1:1'dir. Tek bir backend iki eşzamanlı deployment'ı barındıramaz. İki paralel ortam çalıştırmak için, önce backend'i fork'layın: grafı kopyalayın (hangi değişikliklerle olursa olsun), ardından her fork'u bağımsız olarak deploy edin. İki backend, alttaki component release'lerini paylaşır ve vertex parametrelerinde, vertex dosya bağlamalarında veya graf topolojisinde — paralel ortamın gerektirdiği her ne ise — farklılık gösterir.

1:1 bağlantı, üretim durumunu belirsizlikten arındırır: bir deployment'ta çalışan şey, o backend'in şu anda işaret ettiği graftır. İki paralel ortam, bir nesnenin iki görünümü değil, iki ayrı nesnedir, böylece backend başına işlem geçmişi, ortam başına kaydedilmiş değişiklik geçmişi ve deployment başına canlı ayarlama, her biri bağımsızdır.

1:1 bağlantının ayrıntıları için Deployment'lar sayfasına bakın.

Bir backend'in sahip olduğu ve olmadığı şeyler

Bir backend, vertex'lerine (sabitlenmiş release sürümleri artı parametre, dosya ve kısıt bağlamaları), edge'lerine, endpoint alias'larına (çağıranların belirli output portlarına ulaşmak için kullandığı adlar) ve işlem günlüğüne (her değişikliğin kaydedilmiş geçmişi) sahiptir. Ayrıca görüntüleme kimliğine ve workspace sahipliğine de sahiptir.

Component implementasyonuna (o, component release'inde yaşar), çalışan container'lara (onlar deployment'ta yaşar), genel URL'ye (o, backend'in endpoint alias'larından türetilerek deployment'ta yaşar), takım üyeliğine (o, workspace'te yaşar) veya herhangi bir ortam başına runtime durumuna sahip değildir. Backend kontrol edilmiş bileşimdir; runtime, gözlemlenebilir durum ve dışarıdan erişilebilir yüzey, deployment'a ve workspace'e aittir.

Driver'lar endpoint alias'larına karşı hizalanır

Bir backend bir driver_id taşımaz. Hizalama örtüktür: bir backend, driver'ın bildirdiği her RequiredEndpoint için bir vertex'in endpoint-alias eşlemesi o endpoint'i eşleşen rolde adlandırdığında, driver'ın kabul ettiği bir aktarımla ve doğru yönle, bir driver'ı karşılar. Alias eşlemesi ayrıştırma dikişidir — driver, backend'in neyi açığa çıkardığını tanımlar, vertex'in sabitlenmiş component release'i nasıl yapıldığına karar verir ve operatör, sözleşmeyi bozmadan bir alias'ın arkasındaki implementasyonu değiştirebilir.

Aynı hizalama, bir application'ın sabitlediği iki yüzey tarafından tüketilir: canlı wire sözleşmesi (needs_driver, UX ihtiyacı başına aktarım) ve yakalama ve replay sözleşmesi (taps_driver, her zaman HTTP, her iki yön). Aynı backend'e karşı bir kayıt başladığında, platform taps_driver'ın gerekli endpoint'lerini aynı alias eşlemesi üzerinden çözer ve deploy-çözümleme sırasında eşleşen vertex'lerin üzerine HTTP tap URL'leri bindirir — backend grafı asla değiştirilmez.

Sözleşme katmanı için Driver'lar sayfasına ve taps_driver'ı alias eşlemesi üzerinden tüketen yakalama yüzeyi için Replay'ler sayfasına bakın.

Bu nereye oturur

Backend'ler, platformun ilgi alanı ayrımının bir araya geldiği yerdir. Component'ler yeniden kullanılabilirdir, release'ler değişmezdir, tipler uçtan uca kontrol edilir, işlem günlüğü yeniden üretilebilirdir ve deployment'lar tanımlardan ayrıştırılmıştır. Backend, bu garantileri tek bir iş akışına dönüştüren ilkeldir. Pipelogic'teki her ürün bir veya daha fazla backend'tir — sabitlenmiş, tipli, olay-kaynaklı, yeniden deploy edilebilir — ve bu tekdüzelik, bir ürünün bileşimini büyüdükçe incelenebilir ve yeniden üretilebilir tutan şeydir.

İlgili

Component'ler — bir backend'in sabitlediği yayımlanmış yetenekler.
Tipler — platformun grafı karşı doğruladığı sözleşme.
Backend işlemleri — ayrıntılarıyla işlem günlüğü.
Deployment'lar — 1:1 bağlantının runtime tarafı.
Lease'ler — test backend'lerinin etrafındaki geçici zarflar.
Solution'lar — backend endpoint'leri ve hizmet ettikleri tüketiciler.
Quickstart — ilk göreviniz için rota seçici.