- Kimler için?
- Yeni bir Flutter ürünü kuran veya mevcut backend’ini değiştiren ekipler.
- Başlamadan önce
- Temel ekran akışları, kullanıcı rolleri, veri ilişkileri ve beklenen çevrimdışı davranış.
1. Özellik listesini veri akışına dönüştürün
Bir yapılacaklar uygulaması ile çok satıcılı pazaryeri aynı backend ihtiyacına sahip değildir. Ekran listesinden başlayın: her ekran hangi veriyi okuyor, hangi kaydı değiştiriyor, kimin onayını bekliyor? Sipariş ve ödeme gibi birden fazla kaydı tutarlı değiştiren işlemleri işaretleyin. Sohbet ya da canlı skor gibi güncelleme hızı yüksek akışları da ayrı değerlendirin.
- Kullanıcı rollerini ve kaynak sahipliğini tanımlayın.
- Offline yapılabilecek işlemler ile sunucu onayı gerekenleri ayırın.
- Ürün fotoğrafı, bildirim ve satın alma doğrulamasını veri tablosundan ayrı ihtiyaçlar olarak yazın.
2. Üç yaklaşımın sorumluluklarını karşılaştırın
BaaS entegrasyonu bazı hazır özelliklere erişimi hızlandırabilir; güvenlik politikaları ve maliyet takibi yine uygulama ekibinin sorumluluğudur. Kendi API’niz iş kurallarını tek noktada toplar fakat yayın, izleme ve bakım işi ekler. Hibrit yaklaşım uygun servisleri koruyarak özel işlemleri API’ye alır; bu kez iki sistem arasındaki kimlik ve veri tutarlılığı tasarlanmalıdır.
| Yaklaşım | Başlangıç avantajı | Kontrol edilmesi gereken |
|---|---|---|
| BaaS | Hazır SDK ve servisler | Kurallar, kotalar, ürün bağımlılığı |
| Kendi API | Özel iş kuralları ve veri sınırı | Bakım, sürümleme, işletme |
| Hibrit | Parça parça değişim | Kimlik eşleşmesi ve hata akışı |
3. Flutter istemcisini backend’den ayırın
Widget içinden doğrudan veri sağlayıcısına bağlanmak, backend değişikliğini ekran değişikliğine dönüştürür. Bir repository sınırı oluşturun; DTO’yu uygulamanın alan modeline bu katmanda çevirin. Ekran yükleniyor, boş, hata ve güncel veri durumlarını açıkça temsil etsin. Token yenileme ya da yeniden deneme davranışının her ekranda farklı yazılmasını önleyin.
Widget → ViewModel / State → Repository → API veya BaaS adapter
Sunucu → Yetki kontrolü → İş kuralları → Veritabanı4. Küçük bir prototipte zor senaryoları deneyin
Sadece başarılı giriş ve liste ekranını kurmak karar için yeterli değildir. Token süresi dolunca, ağ yarıda kesilince, aynı kayıt iki cihazda değişince ve kullanıcı hesabı silinince ne olduğunu deneyin. Bir örnek satın alma veya dosya işleminin tekrar çağrıldığında iki kez etki oluşturmadığını kontrol edin. Prototipteki hızla üretim bakım maliyetini ayrı ölçün.
5. Kararı bir kabul tablosuyla kaydedin
Adaylar için gecikme, veri modeli, güvenlik testi, offline kapsam, aylık gider ve operasyon sahibi satırlarını doldurun. Bilinmeyen alanları sıfır yerine araştırılacak konu olarak bırakın. Flutter sayfamız planlanan servis kapsamını açıklar; gerçek müşteri backend tahsisi henüz sunulmaz. Bağımsız örnek API tasarımı ise bugün kendi ortamınızda uygulanabilir.
Uygulama özeti
- Backend kararını ekran ve iş kuralına bağlayın.
- Repository sınırı değişiklik maliyetini azaltır.
- Prototipte ağ, kimlik ve tekrar çağrı hatalarını deneyin.
Sık sorulan sorular
Flutter doğrudan SQL’e bağlanmalı mı?
Hayır; genel bir SQL parolasını uygulamaya koymayın. Kendi API’niz veya kullanıcıya göre politika uygulayan uygun bir veri katmanı kullanın.
Hibrit yapı geçici olmak zorunda mı?
Hayır. Kimlik ve veri sahipliği açıkça tasarlanırsa kalıcı bir mimari tercih de olabilir.
Kaynaklar ve kapsam
Teknik kaynaklar aşağıda. Örnekler açıklama ve kendi ortamınızda uygulama içindir; gerçek müşteri ölçümü veya çalışan Uygulama Cloud servisi iddiası içermez. Sağlayıcı ayarlarını uygulamadan önce ilgili belgenin güncel sürümünü kontrol edin.
Kaynak kontrolü: