İlerleme güncellemeli arka plan görevleri: işe yarayan UI desenleri

Neden kullanıcılar arka planda çalışan işlerde takılır\n\nUzun süren eylemler UI'yı engellememeli. İnsanlar sekme değiştirir, bağlantıyı kaybeder, dizüstlerini kapatır veya bir şeylerin olup olmadığını merak eder. Ekran donduğunda kullanıcılar tahminde bulunur; tahminler tekrar tıklamalara, çift gönderimlere ve destek taleplerine dönüşür.\n\nİyi arka plan işleri aslında güvenle ilgilidir. Kullanıcılar üç şey ister:\n\n- Açık bir durum (queued, running, done)\n- Zaman hissi (kaba bir tahmin bile olsa)\n- Belirgin bir sonraki eylem (bekle, çalışmaya devam et, iptal et veya sonra dön)\n\nBunlar yoksa iş düzgün çalışıyor olsa bile deneyim bozuk hissedilir.\n\nSık yapılan bir hata, yavaş bir isteği gerçek arka plan işi gibi ele almaktır. Yavaş istek hâlâ kullanıcıyı bekleten tek bir web çağrısıdır. Arka plan işi farklıdır: bir işi başlatırsınız, hemen onay alırsınız ve ağır işlem başka yerde olurken UI kullanılabilir kalır.\n\nÖrnek: bir kullanıcı müşteri eklemek için CSV yüklüyor. UI bloklanırsa sayfayı yenileyebilir, tekrar yükleyebilir ve çoğaltmalar oluşur. İçerik arka planda başlarsa ve UI bir iş kartı ile ilerlemeyi ve güvenli bir İptal seçeneği gösteriyorsa, kullanıcı çalışmaya devam edebilir ve net bir sonuca dönebilir.\n\n## Temel yapı taşları: işler, kuyruklar, worker'lar ve durum\n\nArka planda ilerleme güncellemelerinden bahsedildiğinde genelde dört parça birlikte çalışır.\n\nBir job iş birimidir: "bu CSV'yi içe aktar", "bu raporu oluştur" veya "5.000 e-posta gönder" gibi. Bir queue işler işlenene kadar beklediği bekleme hattıdır. Bir worker kuyruğun işlerini alır ve işi yapar (birer birer veya paralel).\n\nUI için en önemli parça işin lifecycle state'idir. Durumları az ve öngörülebilir tutun:\n\n- Queued: kabul edildi, worker bekleniyor\n- Running: aktif olarak işleniyor\n- Done: başarıyla tamamlandı\n- Failed: hata ile durdu\n\nHer işin bir job ID'si (benzersiz referans) olmalıdır. Kullanıcı bir butona tıkladığında o ID'yi hemen döndürün ve görev panelinde bir "Task started" satırı gösterin.\n\nSonra "Şu an ne oluyor?" diye soracak bir yola ihtiyacınız var. Bu genelde job ID alıp durum ve ilerleme detaylarını döndüren bir durum uç noktasıdır. UI bunu yüzde tamamlama, mevcut adım ve herhangi bir mesajı göstermek için kullanır.\n\nSon olarak, durum kalıcı bir depoda yaşamalıdır, sadece bellekte değil. Worker'lar çöker, uygulamalar yeniden başlar ve kullanıcılar sayfayı yeniler. Kalıcı depolama ilerlemeyi ve sonuçları güvenilir kılan şeydir. En azından saklayın:\n\n- güncel durum ve zaman damgaları\n- ilerleme değeri (yüzde veya sayılar)\n- sonuç özeti (nelerin oluşturulduğu veya değiştirildiği)\n- hata detayları (hata ayıklama ve kullanıcı dostu mesajlar için)\n\nEğer AppMaster gibi bir platformda inşa ediyorsanız, durum deposunu diğer veri modelleri gibi ele alın: UI job ID ile okur ve worker iş ilerledikçe burayı günceller.\n\n## İş yükünüze uygun bir kuyruk deseni seçmek\n\nSeçeceğiniz kuyruk deseni, uygulamanızın ne kadar "adil" ve öngörülebilir hissettiğini değiştirir. Bir görev başka işler yığınının arkasında bekliyorsa kullanıcı onu rastgele gecikmelerle deneyimler, sistem sağlıklı olsa bile. Bu yüzden kuyruk seçimi sadece altyapı değil UX kararıdır.\n\nHacim düşük, işler kısa ve ara sıra yeniden denemelere tahammül edilebiliyorsa basit bir veritabanı destekli kuyruk genellikle yeterlidir. Kurulumu kolaydır, denetlenmesi kolaydır ve her şeyi tek yerde tutabilirsiniz. Örnek: bir yönetici küçük bir ekip için gece raporu çalıştırıyor. Bir kez yeniden denerse kimse panik yapmaz.\n\nİş hacmi arttığında, işler ağırlaştığında veya güvenilirlik vazgeçilmez olduğunda genellikle özel bir kuyruk sistemi gerekir. İçe aktarmalar, video işleme, toplu bildirimler ve yeniden başlatmalar arasında çalışmaya devam etmesi gereken iş akışları daha iyi izolasyon, görünürlük ve güvenli yeniden deneme davranışından faydalanır. Bu, kullanıcıya görünen ilerleme eksikliği ve takılı kalmış durumlar açısından önemlidir.\n\nKuyruk yapısı öncelikleri de etkiler. Tek bir kuyruk daha basittir, ama hızlı ve yavaş işleri karıştırmak hızlı işleri yavaş hissettirebilir. Kullanıcı tetikli işler anında hissedilmeli ve planlı toplu işler bekleyebilir ise ayrı kuyruklar yardımcı olur.\n\nEşzamanlılık (concurrency) limitlerini amaçlı belirleyin. Çok fazla paralellik veritabanınızı aşırı yükleyebilir ve ilerlemenin sıçramalı hissetmesine neden olabilir. Çok az ise sistem yavaş hissedilir. Kuyruk başına küçük, öngörülebilir eşzamanlılıkla başlayın ve ancak tamamlanma sürelerini stabil tutabileceğinize emin olduğunuzda artırın.\n\n## UI'de gerçekten gösterebileceğiniz bir ilerleme modeli tasarlamak\n\nİlerleme modeliniz belirsizse UI de belirsiz hisseder. Sistemin dürüstçe ne bildirebileceğine, ne sıklıkla değiştiğine ve kullanıcıların o bilgilerle ne yapması gerektiğine karar verin.\n\nÇoğu işin destekleyebileceği basit bir durum şeması şöyle görünebilir:\n\n- state: queued, running, succeeded, failed, canceled\n- percent: ölçülebiliyorsa 0-100\n- message: kullanıcıların anlayacağı kısa bir cümle\n- timestamps: created, started, last_updated, finished\n- result_summary: işlenen, atlanan, hatalar gibi sayımlar\n\nSonra "ilerleme"nin ne anlama geldiğini tanımlayın.\n\nYüzde, gerçek bir payda (dosyadaki satır sayısı, gönderilecek e-postalar) olduğunda işe yarar. İş değişken veya tahmin edilemezse (bir üçüncü taraf bekleniyor, değişken hesaplama, pahalı sorgular) yanıltıcı olur. Bu durumlarda adım tabanlı ilerleme daha güven verir çünkü açık parçalarda ilerler.\n\nPratik bir kural:\n\n- Gerçekten "X of Y" bildirebiliyorsanız percent kullanın.\n- Süre bilinmiyorsa steps kullanın (Validate file, Import, Rebuild indexes, Finalize).\n- Hiçbiri mümkün değilse belirsiz ilerleme kullanın, ama mesajı taze tutun.\n\nKısmi sonuçları iş çalışırken kaydedin. Bu, UI'nin iş bitmeden önce bile canlı bir hata sayısı veya değişiklik önizlemesi göstermesini sağlar. Bir CSV içe aktarırken rows_read, rows_created, rows_updated, rows_rejected ve son birkaç hata mesajını saklayabilirsiniz.\n\nBu, kullanıcıların güvendiği arka plan işler için temelidir: UI sakin kalır, sayılar hareket eder ve iş bittiğinde "ne oldu?" özeti hazırdır.\n\n## İlerleme güncellemelerini iletme: polling, push ve melez yaklaşımlar\n\nBackend'den ekrana ilerleme getirmek birçok uygulamanın başarısız olduğu yerdir. İlerleme ne kadar sık değişiyor ve kaç kullanıcının bunu izlemesini beklediğinize uygun bir iletim yöntemi seçin.\n\nPolling en basitidir: UI her N saniyede bir durum sorar. İyi bir varsayılan, kullanıcı aktif şekilde sayfaya bakıyorsa 2–5 saniyedir, sonra zamanla geri çekilmek. İş bir dakikadan uzunsa 10–30 saniyeye geçin. Sekme arka plandaysa daha da yavaşlatın.\n\nPush güncellemeleri (WebSocket, server-sent events veya mobil bildirimler) ilerleme hızlı değişiyorsa veya kullanıcılar "şimdi" haberi önemsiyorsa yardımcı olur. Push anındalık sağlar ama bağlantı koptuğunda bir yedeğe ihtiyaç duyarsınız.\n\nMelez bir yaklaşım genellikle en iyisidir: başlangıçta hızlı poll yapın (böylece UI queued'dan running'e çabuk geçişi görür), sonra iş stabil hale gelince yavaşlayın. Push ekliyorsanız yavaş bir polling'i güvenlik ağı olarak tutun.\n\nGüncellemeler durduğunda bunu birinci sınıf bir durum olarak ele alın. "Son güncelleme 2 dakika önce" gösterin ve yenileme teklif edin. Backend'de heartbeat olmayan işleri stale olarak işaretleyin.\n\n## Uzun süren işler için net hissettiren UI desenleri\n\nNetlik iki şeyden gelir: az sayıda öngörülebilir durum ve insanların ne olacağını söyleyen metin.\n\nDurumları sadece backend'de değil UI'de de adlandırın. Bir iş queued (sırasını bekliyor), running (iş yapıyor), waiting for input (seçim gerekiyor), completed, completed with errors veya failed olabilir. Kullanıcı bunları ayırt edemiyorsa uygulamanın takıldığını varsayar.\n\nİlerleme göstergesinin yanında açık, faydalı bir metin kullanın. "Importing 3,200 rows (1,140 processed)" gibi bir ifade "Processing."'den iyidir. Bir cümle ekleyin: "Bu pencereyi kapatabilirsiniz. İçerik arka planda içe alınmaya devam edecek ve hazır olduğunda sizi bilgilendireceğiz."\n\nİlerlemenin nerede görüneceği kullanıcının bağlamına uygun olmalı:\n\n- Modal, görevin bir sonraki adımı engellediği durumlarda (ör. hemen ihtiyaç duyulan fatura PDF'si oluşturma) işe yarar.\n- Toast hızlı görevler için, dikkat dağıtmadan haber vermek için uygundur.\n- Tablo satırında inline ilerleme öğe bazlı işlemler için uygundur.\n\nBir dakikadan uzun tüm işler için insanların sonra bulabileceği basit bir Jobs sayfası (veya Activity paneli) ekleyin.\n\nAçık bir uzun süreli görev UI'sı genellikle bir durum etiketi (son güncelleme zamanı ile), bir ilerleme çubuğu veya adımlar, bir satır detay ve güvenli İptal davranışı ile sonuç özetini içerir. Tamamlanmış işleri erişilebilir tutun ki kullanıcılar tek bir ekranda beklemek zorunda kalmasın.\n\n## "Hatalarla tamamlandı"yı kullanıcıyı karıştırmadan raporlamak\n\n"Tamamlandı" her zaman bir zafer değildir. Bir arka plan işi 9.500 kaydı işlerken 120 tanesi başarısız olursa, kullanıcıların ne olduğunu günlük okumadan anlaması gerekir.\n\nKısmi başarıyı birinci sınıf sonuç olarak ele alın. Ana durum satırında her iki tarafı da gösterin: "Imported 9,380 of 9,500. 120 failed." Bu, sistemin dürüst olmasını sağlar ve işin kaydedildiğini doğrular.\n\nArdından kullanıcıların eylem alabileceği küçük bir hata özeti gösterin: "Missing required field (63)" ve "Invalid date format (41)" gibi. Nihai durumda "Completed with issues" genellikle "Failed" demekten daha nettir çünkü hiçbir şeyin çalışmadığını ima etmez.\n\nDışa aktarılabilir bir hata raporu, kafa karışıklığını yapılacaklara dönüştürür. Basit tutun: satır veya öğe tanımlayıcısı, hata kategorisi, insan dostu mesaj ve ilgili alan adı.\n\nBir sonraki eylemi belirgin ve özetin hemen yanında tutun: veriyi düzelt ve başarısız öğeleri yeniden dene, hata raporunu indir veya sistem sorunu gibi görünüyorsa destek ile iletişime geç.\n\n## Kullanıcıların güvenebileceği İptal ve Yeniden Deneme eylemleri\n\nİptal ve yeniden deneme basit görünür ama UI bir şey söylüyor sistem başka bir şey yapıyorsa güveni hızla bozar. Her iş tipi için İptal'in ne anlama geldiğini tanımlayın ve bunu arayüzde dürüstçe yansıtın.\n\nGenelde iki geçerli iptal modu vardır:\n\n- "Stop now": worker iptal bayrağını sık kontrol eder ve hızlıca çıkar.\n- "Stop after this step": mevcut adım tamamlanır, sonra iş bir sonraki adım başlamadan durur.\n\nUI'de "Cancel requested" gibi ara bir durum gösterin ki kullanıcı sürekli tıklamasın.\n\nİptali güvenli kılmak için işi tekrarlanabilir yapın. Eğer bir iş veri yazıyorsa idempotent işlemleri tercih edin (iki kez çalıştırmak güvenli) ve gerekli temizlikleri yapın. Örneğin CSV içe aktarım kayıtlar oluşturuyorsa, hangi değişikliklerin run #123'te yapıldığını inceleyebilmek için bir job-run ID saklayın.\n\nYeniden deneme aynı netlik gerektirir. Aynı iş örneğini yeniden denemek işi kaldığı yerden devam ettirebiliyorsa mantıklı olabilir. Temiz bir çalıştırma için yeni bir iş örneği oluşturmak, yeni zaman damgası ve denetim izi istediğinizde daha güvenlidir. Her iki durumda da neyin tekrar çalıştırılacağını ve neyin çalıştırılmayacağını açıklayın.\n\nİptal ve yeniden denemeyi öngörülebilir kılan korunma önlemleri:\n\n- Yeniden deneme sayısını sınırlayın ve sayıyı gösterin.\n- Yeniden deneme sırasında duplicate oluşmasını önlemek için Retry butonunu iş çalışırken devre dışı bırakın.\n- E-posta, ödeme, dışa aktarma gibi yan etkileri çoğaltabilecek yeniden denemeler için onay isteyin.\n- Detay panelinde son hatayı ve son başarılı adımı gösterin.\n\n## Adım adım: tıklamadan tamamlanmaya uçtan uca akış\n\nİyi bir uçtan uca akış bir kuralla başlar: UI işi kendisi için asla beklememeli. Sadece job ID için beklemeli.\n\n### Akış (kullanıcı tıklamasından nihai duruma)\n\n1) Kullanıcı görevi başlatır, API hızlı döner. Kullanıcı Import veya Generate report'e tıkladığında sunucunuz hemen bir job kaydı oluşturur ve benzersiz bir job ID döndürür.\n\n2) İşi kuyruğa alın ve ilk durumu ayarlayın. Job ID'yi kuyruğa koyun ve durumu queued, ilerlemeyi %0 olarak ayarlayın. Bu, worker alınmadan önce UI'ye gerçek bir şey gösterir.\n\n3) Worker çalışır ve ilerlemeyi bildirir. Worker başladığında durumu running olarak ayarlayın, bir başlama zamanı saklayın ve ilerlemeyi küçük, dürüst sıçramalarla güncelleyin. Yüzde ölçülemiyorsa Parsing, Validating, Saving gibi adımlar gösterin.\n\n4) UI kullanıcıyı yönlendirir. UI polling veya abonelikle güncellemeleri alır ve net durumları render eder. Kısa bir mesaj (şu an ne yapılıyor) gösterin ve o anda mantıklı olan sadece ilgili eylemleri sunun.\n\n5) Kalıcı bir sonuçla sonlandırın. Tamamlandığında bitiş zamanını, çıktıyı (indirme referansı, oluşturulan ID'ler, özet sayımlar) ve hata detaylarını saklayın. Hatalarla tamamlanmayı belirsiz bir başarı yerine ayrı bir sonuç olarak destekleyin.\n\n### İptal ve yeniden deneme kuralları\n\nİptal açık olmalı: İptal isteği gönderilir, worker bunu onaylar ve canceled olarak işaretler. Yeniden deneme yeni bir job ID oluşturmalı, orijinali geçmiş olarak saklamalı ve neyin yeniden çalıştırılacağını açıklamalıdır.\n\n## Örnek senaryo: ilerleme ve kısmi hatalarla CSV içe aktarma\n\nArka planda ilerleme güncellemelerinin önemli olduğu yaygın bir yer CSV içe aktarmadır. 8.420 satırlık customers.csv yükleyen bir CRM düşünün.\n\nYüklemeden hemen sonra UI "Butona tıkladım" durumundan "bir iş var, sayfayı terk edebilirsiniz" durumuna geçmelidir. Imports sayfasında basit bir iş kartı iyi çalışır:\n\n- Upload received: "Dosya alındı. Sütunlar doğrulanıyor..."\n- Queued: "Mevcut bir worker için bekleniyor (önünüzde 2 iş)."\n- Running: "Müşteriler içe aktarılıyor: 3,180 of 8,420 işlendi (%38)."\n- Wrapping up: "Sonuçlar kaydediliyor ve rapor oluşturuluyor..."\n\nÇalışırken kullanıcıya güvenilir bir tek ilerleme sayısı (işlenen satırlar) ve kısa bir durum satırı (şu anda ne yapılıyor) gösterin. Kullanıcı başka yere giderse iş Recent jobs alanında görünür kalmalıdır.\n\nŞimdi kısmi hataları ekleyin. İş tamamlandığında çoğu satır doğruysa korkutucu bir Failed banner kullanmaktan kaçının. Finished with issues ve net bir bölünme kullanın:\n\nImported 8,102 customers. Skipped 318 rows.\n\nEn yaygın nedenleri basit bir dille açıklayın: geçersiz e-posta formatı, company gibi gerekli alanların eksikliği veya yinelenen dış kimlikler. Kullanıcının satır numarası, müşteri adı ve düzeltilmesi gereken alanı içeren bir hata tablosunu indirmesine veya görüntülemesine izin verin.\n\nYeniden deneme güvenli ve spesifik olmalı. Ana eylem "Başarısız satırları yeniden dene" olabilir; bu, kullanıcı CSV'yi düzelttikten sonra yalnızca 318 atlanan satırı yeniden işleyen yeni bir iş oluşturur. Orijinal işi salt okunur tutun ki geçmiş doğru kalsın.\n\nSon olarak, sonuçları sonra kolay bulunur hale getirin. Her içe aktarma sabit bir özet taşımalı: kim çalıştırdı, ne zaman, dosya adı, sayılar (imported, skipped) ve hata raporunu açma yolu.\n\n## Karışıklığa yol açan yaygın hatalar\n\nGüveni kaybetmenin en hızlı yolu gerçek olmayan sayılar göstermektir. 2 dakika 0% kalan sonra aniden %90'a sıçrayan bir ilerleme çubuğu tahmin gibi hissedilir. Gerçek yüzdelere sahip değilseniz adımları (Queued, Processing, Finalizing) veya "X of Y items processed" gösterin.\n\nBir diğer yaygın sorun ilerlemenin sadece bellekte saklanmasıdır. Worker yeniden başlarsa UI işi "unutur" veya ilerlemeyi sıfırlar. İş durumunu kalıcı depoda saklayın ve UI'nin tek doğru kaynaktan okuduğundan emin olun.\n\nYeniden deneme UX'i, kullanıcı aynı işi birden fazla başlatabildiğinde de bozulur. Import CSV butonu hâlâ aktif görünüyorsa biri iki kez tıklar ve çoğaltmalar oluşur. Yeniden denemeyi hangi çalıştırma üzerinde yapacağınızı belli etmek zorlaşır.\n\nTekrarlayan hatalar:\n\n- Gerçek işi yansıtmayan sahte yüzde ilerleme\n- Son kullanıcıya gösterilen teknik hata dökümleri (stack trace, kodlar)\n- zaman aşımı, çoğaltma veya idempotency için eksik ele alma\n- yeniden denemenin yeni bir iş oluşturduğunu açıklamayan UX\n\nKüçük ama önemli bir detay: kullanıcı mesajını geliştirici detaylarından ayırın. Kullanıcıya "12 satır doğrulamada başarısız" gösterin, teknik izleri loglarda tutun.\n\n## Yayına almadan önce hızlı kontrol listesi\n\nYayınlamadan önce kullanıcıların fark edeceği parçaları hızlıca gözden geçirin: netlik, güven ve toparlanma.\n\nHer iş gösterilebilecek bir anlık görüntü sunmalı: state (queued, running, succeeded, failed, canceled), progress (0-100 veya adımlar), kısa bir mesaj, zaman damgaları (created, started, finished) ve bir sonuç göstergesi (çıktının veya raporun nerede olduğu).\n\nUI durumlarını açık ve tutarlı yapın. Kullanıcıların güncel ve geçmiş işleri bulacakları güvenilir bir yer lazım, ayrıca geri döndüklerinde net etiketler ("Dün tamamlandı", "Hala çalışıyor") görünmeli. Bir Recent jobs paneli tekrar tıklamaları ve çift çalışmaları önleyebilir.\n\nİptal ve yeniden deneme kurallarını düz Türkçe ile tanımlayın. Her iş tipi için İptal'in ne anlama geldiğine, yeniden denemenin izinli olup olmadığına ve neyin yeniden kullanılacağına karar verin (aynı girdiler mi, yeni job ID mi). Kenar durumları test edin: örneğin tamamlanmaya yakın bir iptali.\n\nKısmi hataları gerçek bir sonuç olarak ele alın. Kısa bir özet gösterin ("97 import edildi, 3 atlandı") ve kullanıcıların hemen kullanabileceği eyleme dönüştürülebilir bir rapor sağlayın.\n\nToparlanma planlayın. İşler yeniden başlatmalarda ayakta kalmalı ve takılı kalan işler açık bir duruma zaman aşımı ile girmeli ve rehberlik sunmalı ("Tekrar dene" veya "Job ID ile destekle iletişime geç").\n\n## Sonraki adımlar: bir iş akışını uygulayın ve oradan genişletin\n\nKullanıcıların zaten şikayet ettiği bir iş akışını seçin: CSV içe aktarmalar, rapor dışa aktarımları, toplu e-posta gönderimleri veya resim işleme. Küçük başlayın ve temelleri kanıtlayın: bir iş oluşturuluyor, çalışıyor, durum raporu veriyor ve kullanıcı sonra sonucu bulabiliyor.\n\nBasit bir iş geçmişi ekranı genellikle en büyük kalite artışını sağlar. İnsanlara bir spinner'a bakmak yerine geri dönebilecekleri bir yer verir.\n\nÖnce bir ilerleme iletim yöntemi seçin. Polling sürüm bir için uygundur. Yenileme aralığını backend'e nazik olacak kadar yavaş, ama canlı hissedecek kadar hızlı yapın.\n\nYeniden yazımlardan kaçınan pratik bir inşa sırası:\n\n- önce iş durumlarını ve geçişlerini uygulayın (queued, running, succeeded, failed, finished-with-errors)\n- temel filtrelerle bir iş geçmişi ekranı ekleyin (son 24 saat, sadece benim işlerim)\n- sadece dürüst kalabileceğinizde ilerleme sayılarını ekleyin\n- tutarlı temizlik garanti edilmeden iptal eklemeyin\n- iş idempotent olduğundan emin olmadan yeniden deneme eklemeyin\n\nEğer kod yazmadan bunu inşa ediyorsanız, AppMaster gibi no-code bir platform bir job status tablosu (PostgreSQL) modellemenize ve iş akışlarından bunu güncellemenize izin vererek yardımcı olabilir. Backend, UI ve arka plan mantığını tek bir yerde kurmak isteyen ekipler için AppMaster (appmaster.io) tam uygulamalar için tasarlanmıştır, sadece formlar veya sayfalar için değil.