Web ve mobil uygulamalarda hızlı yineleme için sunucu tarafından yönetilen formlar

Form değişiklikleri neden olması gerektiğinden daha yavaş\n\nFormlar ekranda basit görünür, ama çoğu zaman uygulamaya gömülüdür. Bir form bir sürüme dahil edildiğinde, küçük bir değişiklik bile tam bir teslimat döngüsüne dönüşür: kodu güncelle, tekrar test et, dağıt, ve dağıtımı koordine et.\n\nİnsanların “küçük düzenleme” dediği şey genellikle gerçek işi gizler. Bir etiket değişikliği yerleşimi etkileyebilir. Bir alanı zorunlu hale getirmek doğrulama ve hata durumlarını etkiler. Soruların sırasını değiştirmek analitik veya mantıktaki varsayımları bozabilir. Yeni bir adım eklemek navigasyonu, ilerleme göstergelerini ve birinin akışın ortasında ayrılması durumunda ne olacağını değiştirebilir.\n\nWeb tarafında acı daha azdır ama hâlâ vardır. Yine de bir dağıtım gerekir ve hâlâ QA gerekir çünkü bozuk bir form kayıtları, ödemeleri veya destek isteklerini engeller. Mobilde işler daha kötü: yeni build gönderir, mağaza incelemesini beklersiniz ve kullanıcıların hemen güncelleme yapmamasıyla uğraşırsınız. Bu arada backend ve destek ekipleri aynı anda birden fazla form versiyonuyla uğraşabilir.\n\nYavaşlamalar öngörülebilirdir: ürün hızlı bir düzeltme ister ama mühendislik bunu bir sonraki sürüm treni içine atar; QA tek bir alan değişikliğinin gönderimi kırabileceği için tüm akışları yeniden çalıştırır; mobil güncellemeler iş ihtiyaç acil olduğunda günler alır; destek farklı kullanıcılara gösterilen uyumsuz ekranları açıklamak zorunda kalır.\n\nHızlı yineleme farklı görünür. Sunucu tarafından yönetilen formlarla ekipler bir form tanımını günceller ve değişikliği saatler içinde web ve yerel uygulamalarda görürler, haftalar değil. Bir onboarding formu ayrılmalara neden oluyorsa, aynı öğleden sonra bir adımı kaldırabilir, kafa karıştıran bir alanın adını değiştirebilir ve bir soruyu isteğe bağlı yapabilirsiniz; sonra tamamlanmanın iyileşip iyileşmediğini ölçersiniz.\n\n## Sunucu tarafından yönetilen formlar basitçe ne demektir\n\nSunucu tarafından yönetilen formlar, uygulamanın sert kodlanmış bir form düzeni taşımadığı anlamına gelir. Bunun yerine sunucu, formun bir tanımını gönderir (hangi alanların gösterileceği, hangi sırada, hangi etiketlerle ve hangi kurallarla) ve web veya mobil uygulama bunu render eder.\n\nBunu bir menü gibi düşünün. Uygulama, maddeleri nasıl sunacağını, seçimleri nasıl toplayacağını ve siparişi nasıl göndereceğini bilen garsondur. Sunucu ise bugün menüde ne olduğunu belirleyen mutfaktır.\n\nUygulamada kalan şey render motorudur: metin girişi, tarih seçici, açılır liste, dosya yükleme gibi yeniden kullanılabilir UI parçaları ve hata gösterme ile veriyi gönderme yeteneği. Sunucuya taşınan ise form tanımıdır: bu spesifik onboarding formunun şu an nasıl göründüğü.\n\nİki şeyi ayırmak yardımcı olur:\n\n- Alan tanımları (şema): etiketler, tipler, zorunlu/isteğe bağlı, yardım metni, varsayılanlar, açılır listeler için seçenekler\n- Kullanıcı tarafından girilen veri: birinin yazdığı veya seçtiği gerçek yanıtlar\n\nÇoğu sunucu tarafından yönetilen form sistemi aynı yapı taşlarını kullanır, isimler farklı olsa da: alanlar (tek girdiler), gruplar (bölümler), adımlar (çok sayfalı akışlar), kurallar (göster/gizle, zorunlu koşullar, hesaplanan değerler) ve eylemler (gönder, taslak kaydet, başka adıma geç).\n\nBasit bir örnek: yerel uygulamanız zaten bir açılır listeyi nasıl render edeceğini biliyor. Sunucu açılır listenin etiketini “Role”dan “İş unvanı”na değiştirebilir, seçenekleri güncelleyebilir ve zorunlu olarak işaretleyebilir; yeni bir uygulama sürümü yayınlamaya gerek yoktur.\n\n## Bu yaklaşım ne zaman iyi bir fikir (ve ne zaman değil)\n\nSunucu tarafından yönetilen formlar, formun uygulamanın kendisinden daha sık değiştiği durumlarda en iyi çalışır. Ekibiniz düzenli olarak metin değiştiriyorsa, bir alan ekliyor veya kuralları ayarlıyorsa, sunucu tarafından yönetilen formlar uygulama mağazası incelemeleri ve koordine sürümler nedeniyle geçen günleri kurtarabilir. İstemci aynı kalır. Şema değişir.\n\n### Uygun olduğu durumlar\n\nDüzeni oldukça öngörülebilir ama soruların ve kuralların sık değiştiği akışlar için iyi çalışır: onboarding ve profil kurulumu, anketler ve geri bildirim, dahili araçlar ve yönetici akışları, uyumluluk güncellemeleri ve sorun türüne göre değişen destek formları.\n\nBüyük kazanç daha az koordinasyon ile hızdır. Bir ürün yöneticisi güncellenmiş bir form tanımını onaylayabilir ve hem web hem de yerel uygulamalar bir sonraki yüklemede bunu alır.\n\n### Uygun olmadığı durumlar\n\nForm deneyimi ürünün kendisiyse veya UI çok sıkı yerel kontrol gerektiriyorsa genelde kötü bir uyumdur. Örnekler: çok özel düzenler, tamamen çevrimdışı-first deneyimler, alan başına yoğun animasyon ve jest odaklı etkileşimler veya derin platforma özgü bileşenlere dayanan ekranlar.\n\nTakasa basit: esneklik kazanırsınız, ama piksel-hassas UI kontrolünden vazgeçersiniz. Yerel bileşenleri yine kullanabilirsiniz, ama bunların şemanıza temiz eşlenmesi gerekir.\n\nPratik bir kural: formu “alanlar, kurallar ve bir gönderme eylemi” olarak tanımlayabiliyorsanız ve değişikliklerin çoğu içerik ve doğrulama ise, sunucu tarafından yönetilen yapıya geçin. Değişikliklerin çoğu özel etkileşimler, çevrimdışı davranış veya görsel incelikse, istemci tarafında bırakın.\n\n## Alan tanımlarını veritabanında nasıl saklamalısınız\n\nİyi bir veritabanı modeli iki şeyi ayrı tutar: bir formun kalıcı kimliği ve nasıl göründüğüne/davranacağına dair değişebilir ayrıntılar. Bu ayrım, formları eski gönderimleri veya eski istemcileri bozmadan güncellemenizi sağlar.\n\nYaygın bir yapı şöyle görünür:\n\n- Form: uzun ömürlü form (örneğin “Müşteri onboarding”)\n- FormVersion: yayınlayabileceğiniz ve geri alabileceğiniz değiştirilemez bir anlık görüntü\n- Field: bir versiyondaki her alan için bir satır (tip, anahtar, zorunlu vb.)\n- Options: seçme veya radyo alanları için sıralama dahil seçenekler\n- Layout: gruplama ve gösterim ipuçları (bölümler, ayırıcılar)\n\nİlk alan tiplerinizi küçük ve sade tutun. Metin, sayı, tarih, select ve checkbox ile çok ilerleyebilirsiniz. Dosya yüklemeleri faydalıdır ama yüklemeleri, boyut limitlerini ve depolamayı uçtan uca çözdüğünüzde ekleyin.\n\nSıralama ve gruplama için oluşturulma zamanına dayalı “sihrinden” kaçının. Alanlara ve seçeneklere açık bir pozisyon (tamsayı) saklayın. Gruplama için ya section_id referansı (normalize) ya da her bölümde hangi alan anahtarlarının göründüğünü listeleyen bir layout bloğu saklayın.\n\nKoşullu görünürlük veriye olarak saklandığında en iyi çalışır, koda değil. Pratik bir yaklaşım her alan üzerinde visibility_rule adında bir JSON nesnesi tutmaktır, örneğin “alan X eşitse Y göster”. Başlangıçta eşit, eşit değil, boş olup olmama gibi kural tiplerini sınırlı tutun ki her istemci bunları aynı şekilde uygulayabilsin.\n\nYerelleştirme metinleri ayrı tutmak işleri kolaylaştırır; örneğin FieldText(field_id, locale, label, help_text) gibi bir tablo. Bu, çevirileri düzenli tutar ve metinleri değiştirmeyi mantıktan ayırır.\n\nJSON ile normalleştirilmiş tablolar arasında basit bir kural kullanın: sorgulayıp raporladığınız şeyi normalize edin, nadiren filtrelenen UI ayrıntıları için JSON kullanın. Alan tipi, zorunlu bayrakları ve anahtarlar sütunlarda olmalı. Stil ipuçları, placeholder metin ve daha karmaşık kural nesneleri JSON içinde olabilir, yeter ki formla birlikte versiyonlansınlar.\n\n## Web ve yerel uygulamalar aynı şemayı nasıl render eder\n\nSunucu tarafından yönetilen formlar web ve yerelde çalışsın istiyorsanız, her iki istemcinin de aynı kontrata ihtiyacı vardır: sunucu formu tanımlar, istemci ise her alanı bir UI bileşenine çevirir.\n\nPratik bir desen “alan kayıt tablosu”dur (field registry). Her uygulama alan tipinden bileşene (web) veya view'e (iOS/Android) küçük bir eşleme tutar. Kayıt sabit kalır, form değişse bile işe yarar.\n\nSunucunun gönderdiği veri yalnızca alan listesinden daha fazlası olmalı. İyi bir payload şema (alan id'leri, tipler, etiketler, sıra), varsayılanlar, kurallar (zorunlu, min/max, pattern kontrolleri, koşullu görünürlük), gruplama, yardım metni ve analitik etiketleri içermelidir. Kuralları yürütülebilir koda yakın değil, betimleyici tutun; böylece istemciler basit kalır.\n\nSelect alanları genelde asenkron veri ister. Büyük listeler göndermek yerine bir veri kaynağı tanımlayıcısı gönderin (örneğin “countries” veya “products”) artı arama ve sayfalama ayarları. İstemci generic bir endpoint’i çağırır: “kaynak X için seçenekleri getir, sorgu Y”, sonra sonuçları render eder. Bu, web ve yerel davranışın seçenek değiştiğinde uyumlu kalmasını sağlar.\n\nTutarlılık piksel-hassas olmak zorunda değildir. Boşluk, etiket yerleşimi, zorunlu işaretleri ve hata stilı gibi paylaşılan yapı taşlarında anlaşın. Her istemci platforma uygun şekilde aynı anlamı sunabilir.\n\nErişilebilirlik unutması kolay ve sonra düzeltmesi zor bir konudur. Bunu şema sözleşmesinin bir parçası gibi ele alın: her alanın bir etiketi, isteğe bağlı ipucu ve açık bir hata mesajı olmalı. Odak sırası alan sırasını takip etsin, hata özetleri klavyeyle erişilebilir olsun ve seçiciler ekran okuyucularla çalışsın.\n\n## İstemcileri çok akıllı yapmadan doğrulama ve kurallar\n\nSunucu tarafından yönetilen formlarda “geçerli”nin ne olduğunu sunucu belirler. İstemciler anlık geri bildirim için hızlı kontroller yapabilir (zorunlu veya çok kısa gibi), ama son karar sunucuda olmalı. Aksi halde web, iOS ve Android arasında farklı davranışlar olur ve kullanıcılar doğrudan istek göndererek kuralları atlatabilir.\n\nDoğrulama kurallarını alan tanımlarının yanında tutun. Günlük hayatta insanların sık karşılaştığı kurallarla başlayın: zorunlu alanlar (bir alan X olduğunda zorunlu gibi koşullu zorunluluk dahil), sayılar ve uzunluk için min/max, posta kodu gibi regex kontrolleri, alanlar arası kontroller (başlangıç tarihi bitiş tarihinden önce olmalı) ve izin verilen değerler.\n\nKoşullu mantık ekipleri genelde istemcileri gereğinden fazla karmaşık hale getirir. Yeni uygulama mantığı göndermek yerine basit kurallar gönderin: “başka bir alan eşleştiğinde bu alanı göster.” Örnek: “Şirket büyüklüğü” yalnızca “Hesap türü” = “İşletme” seçildiğinde gösterilsin. Uygulama koşulu değerlendirir ve alanı gösterir/gizler. Sunucu bunu zorlar: alan gizliyken zorunlu yapma.\n\nHata yönetimi sözleşmenin diğer yarısıdır. Her sürümde değişebilecek serbest metne güvenmeyin. İstemcilerin dostça mesajlara eşleştirebileceği stabil hata kodları kullanın (veya sunucu metnini yedek olarak gösterin). Faydalı bir yapı: kod (REQUIRED gibi sabit tanımlayıcı), field (hangi input başarısız oldu), message (isteğe bağlı gösterim metni) ve meta (min=3 gibi ekstra ayrıntılar).\n\nGüvenlik notu: istemci doğrulamasına asla yalnızca güvenmeyin. İstemci kontrollerini kolaylık için kabul edin, zorunlu onlar değildir.\n\n## Adım adım: sıfırdan sunucu tarafından yönetilen form uygulamak\n\nKüçük başlayın. Sık değişen gerçek bir form seçin (onboarding, destek kaydı, lead capture) ve başlangıçta yalnızca birkaç alan tipi destekleyin. Bu, ilk sürümü hata ayıklamayı kolay tutar.\n\n### 1) v1 ve alan tiplerini tanımlayın\n\nWeb ve yerelde render edebileceğiniz 4–6 alan tipi seçin: tek satır metin, çok satırlı metin, sayı, select, checkbox ve tarih gibi. Her tipin ne gerektirdiğini (etiket, placeholder, zorunlu, seçenekler, varsayılan) ve henüz desteklemeyeceğiniz şeyleri (dosya yüklemeleri, karmaşık grid'ler) belirleyin.\n\n### 2) Şema yanıtını tasarlayın\n\nAPI istemcinin ihtiyaç duyduğu her şeyi tek bir payload'ta döndürmeli: form kimliği, versiyon ve kurallarla sıralı alan listesi. Başlangıçta kuralları basit tutun: zorunlu, min/max uzunluk, regex ve başka bir alana dayalı göster/gizle.\n\nPratik bir ayrım: bir endpoint tanımı almak için, diğeri yanıtları göndermek için. İstemciler kuralları tahmin etmemeli.\n\n### 3) Bir renderer oluşturun, sonra aynısını diğerlerine kopyalayın\n\nÖnce web'de renderer'ı uygulayın; iterasyon için daha hızlıdır. Şema stabil göründüğünde iOS ve Android'de aynı renderer'ı aynı alan tipleri ve kural isimleriyle kurun.\n\n### 4) Gönderimleri tanımlardan ayrı saklayın\n\nGönderimleri (submissions) append-only kayıtlar olarak saklayın ve (form_id, version) referansı tutturun. Bu denetim dostudur: form değiştikten sonra bile kullanıcının ne gördüğünü görebilirsiniz.\n\n### 5) Bir düzenleme ve yayınlama iş akışı ekleyin\n\nDahili bir editörde taslak değişiklikler yapın, şemayı doğrulayın, sonra yeni bir versiyon yayınlayın. Basit bir iş akışı yeterlidir: mevcut versiyonun bir kopyasını taslak olarak açın, alanları ve kuralları düzenleyin, kaydederken sunucu tarafı doğrulaması çalıştırın, yayınla (versiyon artışı) ve eski versiyonları raporlama için okunabilir tutun.\n\nGerçekte gizli gereksinimler burada ortaya çıkar; bir gerçek formu uçtan uca test edin sonra daha fazla alan tipi ekleyin.\n\n## Versiyonlama, rollout ve neyin değiştiğini ölçme\n\nHer form değişikliğini bir sürüm gibi ele alın. Sunucu tarafından yönetilen formlar istemci güncellemesi gerektirmeden değişiklik göndermenizi sağlar, bu harika ama kötü bir şema herkesin deneyimini bir anda bozabilir.\n\nBasit bir versiyon modeliyle başlayın. Birçok ekip editörlerin güvenli iterasyon yapması için “draft” ve “published” kullanır. Diğerleri karşılaştırma ve denetim için numaralı versiyonlar (v12, v13) tercih eder. Hangi yöntemi seçerseniz seçin, yayınlanan versiyonları değiştirilemez tutun ve küçük değişiklikler için bile yeni bir versiyon oluşturun.\n\nDeğişiklikleri bir özellik gibi yayınlayın: önce küçük bir kohorta, sonra genişletin. Eğer feature flag kullanıyorsanız bir flag form versiyonunu seçebilir. Kullanılmıyorsa, “X tarihinden sonra oluşturulan kullanıcılar” gibi sunucu kuralları işe yarar.\n\nGerçek hayatta neyin değiştiğini anlamak için birkaç sinyali sürekli kaydedin: render hataları (bilinmeyen alan tipi, eksik seçenek), doğrulama hataları (hangi kural hangi alanda başarısız oldu), terk noktaları (görülen son adım/bölüm), tamamlama süresi (genel ve adım başına) ve gönderim sonucu (başarılı, sunucu reddi). Her gönderime form versiyonunu ekleyin.\n\nRollback için sıkıcı ama etkili bir yaklaşım kullanın: v13 hata patlatırsa kullanıcıları hemen v12'ye geri döndürün, sonra v13'ü düzeltip v14 olarak yeniden yayınlayın.\n\n## Sonradan acı veren yaygın hatalar\n\nSunucu tarafından yönetilen formlar kullanıcıların gördüğünü hızla değiştirmeyi kolaylaştırır. Dezavantajı, kestirme yolların birden fazla uygulama sürümü varken büyük arızalara dönüşebilmesidir.\n\nBir hata şemayı piksel düzeyinde UI talimatlarıyla doldurmaktır. Web uygulaması “iki sütunlu grid ve tooltip ikonu” gibi şeyleri idare edebilir, ama yerel ekran bunu desteklemeyebilir. Şemayı anlam odaklı tutun (tip, etiket, zorunlu, seçenekler) ve her istemcinin sunumu karar vermesine izin verin.\n\nBir başka sorun yeni bir alan tipi ekleyip fallback bırakmamaktır. Eski istemciler “signature” veya “document scan” bilmezse çökebilir veya alanı sessizce düşürebilir. Bilinmeyen tipleri güvenli bir yer tutucu ile gösterme, uyarıyla gizleme veya “Güncelleme gerekli” şeklinde isteme gibi stratejiler planlayın.\n\nEn zor sorunlar genelde değişiklikleri karıştırmaktan çıkar: form tanımını düzenlerken aynı sürümde saklanan cevapları migrate etmek, istemci doğrulamalarına güvenmek, “geçici” JSON’ın büyümesine izin vermek, seçenek değerlerini değiştirip eski değerleri geçersiz kılmak veya tek bir istemci sürümünü varsaymak ve eski native kurulumları unutmak gibi.\n\nGerçekçi bir başarısızlık örneği: company_size alan anahtarını team_size olarak yeniden adlandırırsınız ve aynı anda cevap depolama biçimini de değiştirirsiniz. Web anında güncellenir, ama eski iOS sürümleri eski anahtarı göndermeye devam eder ve backend gönderimleri reddeder. Şemaları sözleşme gibi ele alın: önce yeni alanı ekleyin, bir süre her iki anahtarı da kabul edin, kullanım düştüğünde eski anahtarı kaldırın.\n\n## Yeni bir form versiyonu yayınlamadan önce hızlı kontrol listesi\n\nYeni şemayı yayınlamadan önce, gerçek kullanıcı gönderimleri başladıktan sonra ortaya çıkan sorunlara karşı hızlı bir kontrol yapın.\n\nHer alanın sabit, kalıcı bir tanımlayıcısı olmalı. Etiket, sıra ve yardım metni değişebilir ama alan id değişmemeli. Etiket değişse bile id aynı kalsın ki analiz, eşlemeler ve kayıtlı taslaklar çalışsın.\n\nŞemayı canlıya almadan önce sunucuda doğrulayın. Şema yanıtını bir API gibi ele alın: zorunlu özellikleri, izin verilen alan tiplerini, seçenek listelerini ve kural ifadelerini kontrol edin.\n\nKısa bir ön-yayın kontrol listesi:\n\n- Alan id'leri değiştirilemez; kaldırılan alanlar depreceated olarak işaretlenir (sessizce yeniden kullanılmaz).\n- İstemcilerin bilinmeyen alan tipleri için bir fallback'ı var.\n- Hata mesajları web ve yerelde tutarlı ve kullanıcının hatayı nasıl düzelteceğini söylüyor.\n- Her gönderim form versiyonunu (ve ideal olarak bir şema hash'ini) içeriyor.\n\nSon olarak, bir “eski istemci, yeni şema” senaryosu test edin. Sunucu tarafından yönetilen formlar burada ya zahmetsiz hissedilir ya da kafa karıştırıcı hatalarla başarısız olur.\n\n## Örnek: mobil/web istemcileri yeniden dağıtmadan onboarding formu değiştirmek\n\nBir SaaS ekibinin neredeyse her hafta değişen bir müşteri onboarding formu var. Satış yeni detaylar ister, uyumluluk ek sorular talep eder ve destek daha az “lütfen e-posta gönderin” takipleri ister. Sunucu tarafından yönetilen formlarla uygulama alanları sert kodlamaz; backend'e en son form tanımını sorar ve bunu render eder.\n\nİki hafta içinde şöyle olabilir: 1. hafta Company size açılır listesi (1-10, 11-50, 51-200, 200+) eklenir ve KDV numarası isteğe bağlı yapılır. 2. hafta düzenleyici-endüstri soruları (License ID, Compliance contact) eklenir ve bunlar yalnızca kullanıcı Finance veya Healthcare gibi ilgili bir sektör seçtiğinde zorunlu olur.\n\nKimse yeni bir mobil build göndermez. Web anında güncellenir. Yerel uygulamalar formu bir dahaki yüklemelerinde (veya kısa bir önbellek süresinden sonra) yeni şemayı alır. Backend değişikliği alan tanımlarını ve kuralları güncellemekten ibarettir.\n\nDestek de daha temiz bir iş akışı elde eder. Her onboarding kaydında form_id ve form_version gibi meta veriler bulunur. Kullanıcı “Ben o soruyu hiç görmedim” dediğinde destek, kullanıcının doldurduğu tam versiyonu açıp aynı etiketleri, zorunlu bayrakları ve koşullu alanları görebilir.\n\n## Sonraki adımlar: küçük bir prototip oluşturun ve ölçeklendirin\n\nSık değişen ve net etkisi olan bir form seçin: onboarding, destek kaydı veya lead capture gibi. Birinci günde ne desteklemesi gerektiğini tanımlayın: dar bir alan tipi seti (metin, sayı, select, checkbox, tarih) ve birkaç temel kural (zorunlu, min/max, basit koşullu göster/gizle). Daha sonra zengin bileşenleri ekleyin.\n\nUçtan uca prototip oluştururken kapsamı dar tutun: bir formu dönüştürün, veri modelinizi çizin (form, version, fields, options, rules), API'nizin döndüreceği JSON'u tanımlayın, web ve mobilde küçük bir renderer oluşturun ve davranışın tutarlı kalması için sunucu tarafı doğrulamayı zorunlu kılın.\n\nSomut bir ilk kazanım: “Company size”ı serbest metinden açılır listeye çevirin, zorunlu bir onay kutusu ekleyin ve “İletişime geçin” işaretli değilse “Telefon numarası”nı gizleyin. Eğer şema ve renderer doğru kurulmuşsa, bu güncellemeler veri değişikliği olur, istemci sürümü gerektirmez.\n\nEğer her backend endpoint'ini ve istemci akışını el ile yazmak istemiyorsanız, AppMaster (appmaster.io) gibi bir no-code platform pratik olabilir. Şemayı ve veriyi tek bir yerde modelleyebilir, doğrulamayı backend'de tutarken sunucu tarafından sağlanan şemaları render edebilen web ve yerel uygulamalar üretebilirsiniz.