Flutter önbellekleme stratejileri: yerel önbellek, eski veri, yenileme kuralları

Flutter uygulamalarında önbellekleme neden zorlaşır

Bir mobil uygulamada önbellekleme, verinin bir kopyasını yakında (hafızada veya cihazda) tutmak ve bir sonraki ekranın anında render olmasını sağlamak demektir. Bu veri bir ürün listesi, kullanıcı profili veya arama sonuçları olabilir.

Zor olan kısmı şu: önbelleğe alınan veri sıklıkla biraz yanlış olur. Kullanıcılar bunu çabuk fark eder: güncellenmeyen bir fiyat, takılı kalmış görünen bir bildirim sayacı ya da editledikten hemen sonra eski bilgileri gösteren bir detay ekranı. İşin can sıkıcı yanı zamanlamadır. Aynı uç nokta pull-to-refresh sonrası doğru görünebilir, ama geri navigasyon, uygulama yeniden gelme veya hesap değiştirince yanlış olabilir.

Gerçek bir takas vardır. Her zaman taze veriyi çekerseniz ekranlar yavaş ve takılgan hisseder, pil ve veri boşa gider. Agresif önbellekleme yaparsanız uygulama hızlı hisseder ama kullanıcılar gördüklerine güvenmeyi bırakır.

Basit bir hedef yardımcı olur: tazeliği öngörülebilir kılın. Her ekranın hangi veriyi gösterebileceğine (taze, hafifçe eski, ya da çevrimdışı), verinin ne kadar süre yaşayacağına ve hangi olayların onu geçersiz kılacağına karar verin.

Ortaok çerçevesi: bir kullanıcı bir siparişi açar, sonra sipariş listesine geri döner. Liste önbellekten gelirse eski durumu gösterebilir. Her seferinde yenilerseniz liste titreyip yavaş hissedilebilir. "Önce önbelleği anında göster, arka planda yenile, yanıt gelince her iki ekranı da güncelle" gibi net kurallar gezinme boyunca deneyimi tutarlı yapar.

Önbellek ve tazelik hakkında basit bir düşünce şekli

Önbellek sadece "kaydedilmiş veri" değildir. Bu, kaydedilmiş bir kopya artı o kopyanın ne zaman geçerli olduğuna dair bir kuraldır. Yükü sadece payload olarak saklayıp kuralı atlarsanız iki gerçeklik versiyonunuz olur: bir ekran yeni bilgiyi gösterir, diğeri dünün verisini.

Pratik bir model her önbelleğe alınmış öğeyi üç durumdan birine koymaktır:

• Taze: güvenle gösterilebilir.
• Eski ama kullanılabilir: şimdi göster, arka planda yenile.
• Yenilenmeli: güvenme, göstermeden önce çek (veya bir yükleme durumu göster).

Bu çerçeve UI'nizin her seferinde aynı şekilde tepki vermesini sağlar.

Tazelik kuralları takım arkadaşınıza açıklayabileceğiniz sinyallere dayanmalıdır. Yaygın seçimler zaman tabanlı sona erme (örneğin 5 dakika), sürüm değişikliği (şema veya uygulama sürümü), kullanıcı eylemi (pull to refresh, submit, delete) veya sunucu ipucu (ETag, last-updated zaman damgası veya açık bir "cache invalid" yanıtı) olabilir.

Örnek: bir profil ekranı önbelleğe alınmış kullanıcı verisini anında yükler. Eğer "eski ama kullanılabilir" ise önbellekteki isim ve avatarı gösterir, sonra sessizce yeniler. Kullanıcı profilini az önce düzenlediyse bu "yenilenmeli" anıdır. Uygulama önbelleği hemen güncellemeli ki her ekran tutarlı kalsın.

Bu kurallara kim karar verecek? Çoğu uygulamada en iyi varsayılan: veri katmanı tazelik ve geçersiz kılmadan sorumludur, UI sadece tepki verir (önbelleği göster, yükleme göster, hata göster) ve backend mümkünse ipuçları sağlar. Bu, her ekranın kendi kuralını icat etmesini engeller.

Ne önbelleğe alınır (ve ne alınmaz)

İyi önbellekleme bir soruyla başlar: bu veri biraz eski olsa kullanıcıya zarar verir mi? Cevap "muhtemelen sorun olmaz" ise genellikle yerel önbelleğe almak uygundur.

Sıklıkla okunan ve yavaş değişen veriler genellikle önbelleğe değer: kullanıcıların sık kaydırdığı feed ve listeler, katalog tarzı içerik (ürünler, makaleler, şablonlar) ve kategoriler veya ülkeler gibi referans verisi. Ayarlar ve tercihler ile isim ve avatar URL'si gibi temel profil bilgileri de buraya girer.

Riskli taraf ise para ile veya zamana duyarlı olan her şeydir. Bakiye, ödeme durumu, stok durumu, randevu slotları, teslimat ETA'ları ve "son görüldü" gibi bilgiler eskiyse gerçek sorunlara yol açabilir. Hız için önbelleğe alınabilirler ama karar noktalarında (örneğin siparişi onaylamadan hemen önce) önbelleği geçici bir placeholder olarak kabul edip yenileme zorunlu kılın.

Türetilmiş UI durumu ayrı bir kategoridir. Seçili sekme, filtreler, arama sorgusu, sıralama ya da kaydırma pozisyonunu kaydetmek gezinmeyi yumuşatır. Ancak eski seçimler beklenmedik şekilde geri gelince kafa karıştırabilir. Basit bir kural: kullanıcı aynı akışta kaldığı sürece UI durumunu hafızada tutun, ama kullanıcı kasıtlı olarak "yeniden başla" yaptığında (ana ekrana dönmek gibi) sıfırlayın.

Güvenlik veya gizlilik riski yaratan verileri önbelleğe almakten kaçının: sırlar (parolalar, API anahtarları), tek kullanımlık tokenlar (OTP kodları, parola sıfırlama tokenları) ve çevrimdışı erişim gerçekten gerekli değilse hassas kişisel veriler. Tam kart bilgilerini veya dolandırıcılığı kolaylaştıran hiçbir şeyi önbelleğe almayın.

Alışveriş uygulamasında ürün listesini önbelleğe almak büyük bir kazançtır. Ancak ödeme ekranı, satın alma işleminden hemen önce toplamları ve stok durumunu her zaman yenilemelidir.

Yerel önbellek katmanı seçimi: hafıza, disk, veritabanı

Çoğu Flutter uygulaması ekranların hızlı yüklenmesi ve ağ beklerken boş görünmemesi için bir yerel önbelleğe ihtiyaç duyar. Kritik karar verinin nerede saklandığıdır; çünkü her katmanın hız, boyut sınırı ve temizleme davranışı farklıdır.

Hafıza (memory) önbelleği en hızlısıdır. Uygulama açık kaldığı sürece tekrar kullanılacak veriler için idealdir: mevcut kullanıcı profili, son arama sonuçları veya kullanıcı tarafından yeni görüntülenen bir ürün gibi. Dezavantajı açıktır: uygulama kapandığında kaybolur; soğuk başlatmalar veya çevrimdışı kullanım için yardımcı olmaz.

Diskte anahtar-değer depolama, yeniden başlatmalar arasında kalmasını istediğiniz küçük öğeler için uygundur. Tercihler ve küçük blob'lar: özellik bayrakları, "son seçilen sekme" ve nadiren değişen küçük JSON yanıtları. Bunu kasıtlı olarak küçük tutun. Büyük listeleri doğrudan anahtar-değer deposuna dökmeye başlarsanız güncellemeler karmaşıklaşır ve şişme kolay olur.

Yerel veritabanı, verileriniz daha büyük, yapılandırılmış veya çevrimdışı davranışa ihtiyaç duyuyorsa en iyisidir. Ayrıca sorgulara ihtiyaç olduğunda faydalıdır ("tüm okunmamış mesajlar", "sepetteki öğeler", "geçen ayın siparişleri")—büyük bir blob’u yükleyip hafızada filtrelemek yerine.

Önbelleklemenin öngörülebilir kalması için her veri türü için birincil depoyu seçin ve aynı dataset'i üç yerde tutmaktan kaçının.

Kısa bir kural:

• Hafıza: mevcut oturum içinde yeniden kullanım
• Disk anahtar-değer: küçük, basit, nadiren değişen
• Veritabanı: büyük, yapılandırılmış, çevrimdışı-dostu

Ayrıca boyutu planlayın. "Çok büyük"ün ne anlama geldiğine, öğeleri ne kadar süre saklayacağınıza ve nasıl temizleyeceğinize karar verin. Örneğin: önbelleğe alınmış arama sonuçlarını son 20 sorguyla sınırlayın ve 30 günden eski kayıtları düzenli olarak kaldırın ki önbellek sessizce büyümesin.

Kullanıcıların katlanabileceği eski veriler için yenileme kuralları

Yenileme kuralları her ekran için bir cümlede açıklanabilecek kadar basit olmalı. Mantıklı önbelleklemenin ödülü budur: kullanıcılar hızlı ekranlar elde eder ve uygulama güvenilir kalır.

En basit kural TTL (time to live). Veriyi bir zaman damgasıyla kaydedin ve örneğin 5 dakika boyunca taze sayın. Sonrasında eski olur. TTL, bir feed, kategoriler veya öneriler gibi "olması güzel" verilere uygundur.

Yararlı bir incelik soft TTL ve hard TTL ayrımıdır.

Soft TTL ile önbelleğe alınmış veriyi anında gösterirsiniz, sonra arka planda yenilersiniz ve değiştiyse UI'ı güncellersiniz. Hard TTL ile süre dolunca eski veriyi göstermeyi bırakırsınız. Ya yükleyiciyle engeller ya da "çevrimdışı/tekrar deneyin" durumunu gösterirsiniz. Hard TTL, yanlış olmanın yavaş olmasından daha kötü olduğu durumlar için uygundur: bakiyeler, sipariş durumu veya izinler gibi.

Eğer backend destekliyorsa, ETag, updatedAt veya bir versiyon alanı kullanarak "sadece değiştiyse yenile" yöntemini tercih edin. Uygulamanız "bu değişti mi?" diye sorup tam payload indirmeyi atlayabilir.

Kullanıcı dostu bir varsayılan çoğu ekran için stale-while-revalidate: hemen göster, sessizce yenile ve sadece sonuç farklıysa yeniden çiz. Bu hız verir, rastgele titremeyi önler.

Ekran bazlı tazelik genellikle şöyle olur:

• Ana sayfa feed'i: soft TTL (1 ila 5 dakika), açılışta arka plan yenileme
• Profil: soft TTL (15 ila 60 dakika), düzenlemeden sonra yenile
• Mesajlar: hard TTL veya çok kısa TTL (0 ila 10 saniye), geri geldiğinde yenile
• Checkout/sipariş: hard TTL, her zaman sunucu ile onayla
• Ayarlar/statik listeler: uzun TTL (günler), uygulama güncellemesinde yenile

Kuralları sadece çekme maliyetine değil, yanlış olmanın maliyetine göre seçin.

Önbelleği ne zaman geçersiz kılayım (önemli tetikleyiciler)

Önbellek geçersiz kılma şu soruyla başlar: hangi olay önbelleği yeniden çekme maliyetinden daha az güvenilir kılar? Küçük ve belirgin bir tetikleyici seti seçip ona bağlı kalırsanız davranış öngörülebilir olur ve UI sabit hisseder.

Gerçek uygulamalarda en çok önem taşıyan tetikleyiciler:

• Kullanıcı kaynaklı: pull-to-refresh, bir hata sonrası Retry dokunma veya kullanıcı en son görmek istediği ekrana geri döndüğünde (örneğin inbox).
• Yaşam döngüsü: uygulama başlangıcı (önbelleği ısıt, sonra yenile) ve arka plandan geri dönme (sadece TTL'den eskiyse yenile).
• Kimlik: giriş, çıkış, hesap değiştirme. Bunu sert bir sınır olarak ele alın: kullanıcıya ait önbellekleri temizleyin ve eski kullanıcıya bağlı devam eden istekleri iptal edin.
• Yazma eylemleri (CRUD): oluşturma, güncelleme veya silmeden sonra önbelleği hemen güncelleyin ki ekranlar tutarlı kalsın. Sunucu ek kurallar uyguluyorsa (sıralama, izinler, hesaplanmış alanlar) tekrar çekin.
• Güvenlik: uygulama yükseltmesi, yerel şema değişikliği, feature flag değişiklikleri. Bir önbellek sürümü artırın ve temizleyin veya taşıyın.

Örnek: kullanıcı profil fotoğrafını düzenledi, sonra geri döndü. Sadece zaman tabanlı yenilemeye güvenirseniz önceki ekran eski görüntüyü gösterebilir. Bunun yerine düzenlemeyi tetikleyici olarak görün: önbellekteki profile nesnesini hemen güncelleyin ve yeni bir zaman damgası ile taze işaretleyin.

Geçersiz kılma kurallarını küçük ve açık tutun. Eğer hangi olayın bir önbellek girişini geçersiz kıldığına tam olarak işaret edemiyorsanız, ya çok sık yenilersiniz (yavaş, titreyen UI) ya da gerekli zamanlarda yenilemezsiniz (eski ekranlar).

Adım adım: öngörülebilir bir önbellek akışı uygulamak

Öncelikle ana ekranlarınızı ve her birinin hangi veriye ihtiyaç duyduğunu listeleyin. Endpointler yerine kullanıcıya görünen nesneleri düşünün: profile, sepet, sipariş listesi, katalog öğesi, okunmamış sayaç.

Sonra her veri türü için bir tek gerçek kaynağı seçin. Flutter'da bu genellikle verinin nereden geldiğini (hafıza, disk, ağ) saklayan bir repository'dir. Ekranlar ne zaman ağa gidileceğine karar vermemeli; repository'den veri istemeli ve dönen duruma göre tepki vermeli.

Pratik bir akış:

• Ekranları gerekli verilere eşleştir (ve bunun kullanıcıya özel mi yoksa paylaşılan mı olduğunu belirle).
• Okumaların ve yazmaların hepsini her veri türü için tek bir repository üzerinden yönlendir.
• Veriyi kaydederken metadata ekle: savedAt zaman damgası, şema/uygulama sürümü ve ownerUserId.
• Dört durum için UI davranışı tanımla: taze, eski, yükleniyor, hata.
• İki yenileme yolu ekle: manuel (pull to refresh) ve arka plan (eskiyse sessiz yenileme).

Metadata kuralları zorunlu kılar. Eğer ownerUserId değişirse (çıkış/giriş), eski satırları hemen atabilir veya göz ardı edebilirsiniz; bu sayede önceki kullanıcının verisini kısa bir süre için göstermemiş olursunuz.

UI davranışı için "eski"nin ne anlama geldiğine önceden karar verin. Yaygın bir kural: eski veriyi anında göster ki ekran boş kalmasın, arka planda yenilemeyi başlat ve yeni veri gelince güncelle. Yenileme başarısız olursa eski veriyi tutun ve küçük, net bir hata gösterin.

Sonra kuralları birkaç sıkıcı testle kilitleyin:

• TTL: veri X dakikadan sonra eski olur.
• Logout: ownerUserId'ye ait önbellek temizlenir veya izolasyon sağlanır.
• Güncelleme: yerel yazma önbelleği hemen günceller, sonra senkronize eder.
• Sürüm artışı: şema/uygulama sürümü değişince eski önbellek yok sayılır.
• Hata: yenileme başarısızsa eski veri görünür kalır.

İşte "bizde önbellekleme var" ile "uygulamamız her seferinde aynı davranıyor" arasındaki fark bu testlerdir.

Navigasyon boyunca ekranları tutarlı tutmak

Bir liste ekranında bir değeri görüp detaya girip onu düzenleyip geri döndüğünüzde eski değeri görmek güveni hızla zedeler. Navigasyon boyunca tutarlılık, her ekranın aynı kaynaktan okumasından gelir.

Sağlam bir kural: bir kere çek, bir kere kaydet, birçok kere render et. Ekranlar aynı endpointi bağımsız olarak çağırıp özel kopyalar tutmamalı. Önbelleğe alınmış veriyi paylaşan bir store (durum yönetimi katmanı) kullanın ve hem liste hem detay ekranlarının aynı veriyi izlemesine izin verin.

Tek bir gerçek kaynağı oluşturun

Mevcut değerin ve tazeliğin sahibi tek bir yer olsun. Ekranlar yenileme isteyebilir ama kendi zamanlayıcılarını, yeniden denemelerini ve ayrıştırmalarını yönetmemeli.

"İki gerçeklik"i önleyen pratik alışkanlıklar:

• Rotalar arasında durumu paylaşın (özellik başına bir store/provider, widget başına değil).
• Aynı şeyi iki ekranın aynı anda çekmesini önlemek için uçuşta olan istekleri dedupe edin.
• Geri navigasyonda eski widget durumunu canlandırmak yerine store'dan yeniden okuyun.
• Düzenlemelerden sonra store'u hemen güncelleyin ki her ekran değişikliği yansıtsın.

Neler olduğunu gösterin

İyi kurallar olsa bile kullanıcılar bazen eski veriyi görecek (çevrimdışı, yavaş ağ, arka planda kalmış uygulama). Bunu küçük, sakin sinyallerle belli edin: "Az önce güncellendi" zaman damgası, ince bir "Yenileniyor…" göstergesi veya "Çevrimdışı" rozeti.

Düzenlemelerde iyimser (optimistic) güncellemeler genelde daha iyi hisseder. Örnek: kullanıcı detay ekranda bir ürün fiyatını değiştirir. Shared store'u hemen güncelleyin ki liste ekrana geri dönünce yeni fiyatı göstersin. Kayıt başarısız olursa önceki değere geri dönün ve kısa bir hata gösterin.

Yaygın önbellekleme hataları ve nasıl önlenir

Çoğu önbellekleme hatası sıkıcıdır: önbellek çalışır ama kimse ne zaman kullanılacağını, ne zaman sona ereceğini ve kimin sahibi olduğunu açıklayamaz. En yaygın tuzak önbellekleme yapıp metadata eklememektir. Sadece payload saklarsanız onun eski olup olmadığını, hangi uygulama sürümünün ürettiğini veya hangi kullanıcıya ait olduğunu söyleyemezsiniz. En azından savedAt, basit bir versiyon numarası ve userId saklayın. Bu alışkanlık birçok "neden bu ekran yanlış?" hatasını engeller.

Başka bir yaygın sorun aynı verinin birden fazla cache'inin olmasıdır. Liste ekranı hafızada bir liste tutar, repository diske yazar ve detay ekran tekrar çekip başka bir yerde saklar. Bir kaynak belirleyin (genellikle repository katmanı) ve her ekranın oradan okumasını sağlayın.

Hesap değişiklikleri sık sık ayak kazasıdır. Biri çıkış yapıp başka hesapla giriş yaparsa kullanıcı fotoğrafı veya siparişleri kısa bir süre için eski kullanıcıya ait görünmemeli. Kullanıcıya ait tabloları ve anahtarları temizleyin.

Pratik düzeltmeler:

• Önbellek girdilerini sadece JSON olarak değil, savedAt, version ve userId ile saklayın.
• Her dataset için bir sahip belirleyin (örneğin ProfileRepository profile'dan sorumludur).
• Çoğu ekran için "şimdi önbelleği göster, arka planda yenile" kuralını kullanın.
• Yenilemeyi oranla sınırla (örneğin her endpoint başına X dakika içinde bir ağ yenilemesi).
• Yenileme hatalarını yüzeye çıkar (küçük bir banner veya retry) ve maksimum bir eski süre belirle.

Örnek: ürün listeniz önbellekten anında yüklenir, sonra sessizce yenilenir. Yenileme başarısız olursa önbellek gösterilmeye devam eder ama kullanıcının verinin güncel olmayabileceğini açıkça gösterin ve Retry sunun. Yenileme sırasında UI'ı engellemeyin.

Yayına almadan önce hızlı kontrol listesi

Yayın öncesi, önbellekleme "görünüşe göre iyi" halinden kuralları test edilebilir hale getirin. Kullanıcılar geri gelip giderken, çevrimdışıyken veya farklı bir hesapla giriş yaparken tutarlı veriler görmelidir.

Tazelik ve yenileme davranışını tanımlayın

Her ekran için verinin ne kadar süre taze kabul edileceğine karar verin. Hızlı değişen veriler için dakikalar (mesajlar, bakiyeler), yavaş değişen veriler için saatler (ayarlar, ürün kategorileri) olabilir. Sonra eski olduğunda ne olacağını onaylayın: arka plan yenileme, açılışta yenile veya manuel pull-to-refresh.

Geçersiz kılma ve önbellek metadata'sını kilitleyin

Her veri türü için hangi olayların önbelleği sileceğini veya atlayacağını kararlaştırın. Yaygın tetikleyiciler: çıkış, madde düzenleme, hesap değiştirme ve veri şekli değiştiren uygulama güncellemeleri.

Önbelleğe alınmış girdilerin yanında küçük bir metadata seti saklayın:

• savedAt
• userId
• version (şema/uygulama sürümü)
• source (opsiyonel: network vs local)

Sahipliği net tutun: her veri türü için bir repository kullanın (örneğin ProductsRepository), widget başına değil. Ayrıca çevrimdışı davranışı belirleyip test edin. Hangi ekranların önbellekten gösterileceğini, hangi eylemlerin devre dışı kalacağını ve göstereceğiniz metni ("Kaydedilmiş veriler gösteriliyor" ve görünür bir yenile düğmesi) netleştirin. Manuel yenileme her önbellek destekli ekranda kolay bulunur olmalı.

Örnek: tutarlı kalan bir katalog uygulaması

Basit bir mağaza uygulaması düşünün: ürün kataloğu (liste), ürün detayları ve Favoriler sekmesi. Kullanıcı katalogu kaydırır, bir ürünü açar ve kalp ikonuna dokunarak favoriler ekler. Hedef: yavaş ağlarda bile hızlı hissettirmek, aynı zamanda kafa karıştıran uyumsuzlukları göstermemek.

Anında render etmeye yardımcı olanları yerel olarak önbelleğe alın: katalog sayfaları (ID, başlık, fiyat, küçük resim URL'si, favori bayrağı), ürün detayları (açıklama, teknik bilgiler, bulunabilirlik, lastUpdated), resim metadata'sı (URL'ler, boyutlar, cache anahtarları) ve kullanıcının favorileri (ürün ID seti, opsiyonel zaman damgaları).

Kullanıcı katalogu açtığında önbelleğe alınmış sonuçları anında gösterin, sonra arka planda doğrulayın. Taze veri gelirse sadece değişenleri güncelleyin ve kaydırma pozisyonunu koruyun.

Favori açma/kapama eylemini "tutarlı olmak zorunda" kabul edin. Yerel favoriler setini hemen güncelleyin (optimistic update), sonra aynı ID için önbelleğe alınmış ürün satırlarını ve ürün detay önbelleklerini güncelleyin. Ağ çağrısı başarısız olursa geri alıp küçük bir mesaj gösterin.

Gezinmeyi tutarlı tutmak için liste rozeti ve detay kalp ikonunu aynı kaynak (yerel önbellek veya store) üzerinden yönetin, ayrı ekran durumlarından değil. Listeye geri döndüğünüzde kalp anında güncellenir, detay ekran listeden yapılan değişiklikleri yansıtır ve Favoriler sekmesi beklemeden doğru sayıyı gösterir.

Basit yenileme kuralları ekleyin: katalog önbelleği hızlıca sona erer (dakikalar), ürün detayları biraz daha uzun, favoriler süresiz saklanır ama giriş/çıkış sonrası her zaman reconcile edilir.

Sonraki adımlar: kuralları dokümante edin ve bakımını kolaylaştırın

Önbellekleme, ekibinizin bir sayfa kurala işaret edip ne olacağını kabul ettiğinde gizemini kaybeder. Amaç mükemmellik değil; sürümler arasında aynı kalan öngörülebilir davranış.

Ekran başına küçük bir tablo yazın ve değişikliklerde gözden geçirilebilecek kadar kısa tutun: ekran adı ve ana veri, önbellek konumu ve anahtar, tazelik kuralı (TTL, olay tabanlı veya manuel), geçersiz kılma tetikleyicileri ve yenilenirken kullanıcıya ne gösterileceği.

Ayarlama yaparken hafif logging ekleyin. Önbellek isabetlerini, kaçırmalarını ve neden yenileme olduğunu kaydedin (TTL doldu, kullanıcı pull-to-refresh yaptı, uygulama geri geldi, mutation tamamlandı). Birisi "bu liste yanlış hissettiriyor" dediğinde bu loglar hatayı çözülebilir kılar.

Basit TTL'lerle başlayın, sonra kullanıcıların ne fark ettiğine göre ince ayar yapın. Bir haber akışı 5–10 dakika eski olabilir, oysa bir sipariş durumu ekranı geri gelince ve ödeme sonrası yenileme gerektirebilir.

Hızlı bir Flutter uygulaması inşa ediyorsanız, veri katmanınızı ve önbellek kurallarınızı uygulamadan önce tasarlamak yardımcı olur. Koder.ai (koder.ai) kullanan takımlar için planning mode, ekran başına kuralları yazmak ve sonra onlara göre inşa etmek için kullanışlıdır.

Yenileme davranışını ayarlarken kararlı ekranları koruyun. Yeni bir kural yanlışlıkla titreme, boş durumlar veya gezinti boyunca uyumsuz sayaçlar getirdiyse snapshot ve rollback işinizi kurtarabilir.