Elm Architecture'ı Zorlayan Gerçek Bir Batch İşi

Native Elm çalışma zamanı elm-run'ı test etmek için yazar, küçük bir örnek yerine gerçek ve oldukça büyük bir uygulamanın içindeki asıl batch işini kullandı. Bu, elm-pages'in Script modundan (BackendTask ile zincirlenen doğrusal bir boru hattı) farklı olarak, init, update ve subscriptions içeren gerçek bir The Elm Architecture döngüsünü tarayıcı yerine işletim sistemine karşı çalıştırma denemesiydi; yüzlerce öğenin kendi hızında birkaç durumdan geçtiği ve yarı yolda başarısız olabildiği bir iş yükü için bu döngü, tek seferlik bir boru hattından çok daha değerli çıktı.

Batch'teki her öğe, Queued, Submitted, Processing, Finished ve Failed gibi durumları taşıyan bir union type ile modellendi; bu sayede geçersiz geçişler (ör. hiç gönderilmemiş bir öğe için sonuç çekmeye çalışmak) derleyici tarafından tamamen imkânsız hale getirildi. Failed dalı, hatanın oluştuğu anki tüm önceki Item değerini taşıdığı için, bir hatayı geri sarmak yalnızca önceki duruma dönmekten ibaret; bu da yeniden denemeyi 'baştan başla ve umut et' yerine 'kaldığın yerden devam et' haline getiriyor.

Bu yaklaşımın batch işlerinde arayüzlere göre çok daha kritik olduğu vurgulanıyor: bir batch'teki ele alınmamış bir durum, kimsenin fark etmediği sessiz bir atlamaya dönüşebilirken, tükenmez örüntü eşleştirme bunu derleme zamanında engelliyor. Ayrıca update saf bir fonksiyon olduğu için, kaydedilmiş mesaj dizileriyle geri oynatma ve checkpoint'ten devam etme gibi senaryolar IO'ya dokunmadan test edilebiliyor.

En dikkat çekici nokta ise aynı Elm domain tiplerinin, encoder/decoder'ların ve iş mantığının artık üç farklı çalışma ortamında -bir Lamdera frontend'i, Lamdera backend'i ve elm-run ile derlenen native bir batch binary'sinde- aynı modüllerden paylaşılması; bu da istemci ile arka plan işçisi arasında zamanla ortaya çıkan tip kayması hatalarını kökten ortadan kaldırıyor.