Tek bir yapay zeka uygulama oluşturucusu React ve Flutter'ı yönetebilir mi?

React web istemcisi ve Flutter mobil istemcisi için iki ayrı yapay zeka aracı kullanmak, ilk ortak kural değişene kadar mantıklı görünür. Sonra bir araç tarayıcı akışını günceller, diğeri dünkü varsayımı korur ve veritabanı iki sürümü de kabul eder. Görünürdeki iş bölümü artık bir entegrasyon işine dönüşmüştür.

Çoğu küçük ekip için tek bir yapay zeka uygulama oluşturucusu daha iyi seçimdir. Bunun için aracın ayrı React, Flutter ve arka uç kod tabanları üretebilmesi, kaynak kodu sunması ve her istemcinin bağımsız yayınlanmasına izin vermesi gerekir. «Tek oluşturucu», tek bir planlama bağlamı ve tek bir sistem sözleşmesi anlamına gelmelidir. Tek dev uygulama, tek sürüm treni ya da TypeScript ile Dart arasında kullanıcı arayüzü kodu paylaşma çabası anlamına gelmez.

Alternatif de işe yarayabilir. Ayrı web ve mobil ekipleri zaten kendi istemcilerinden sorumluysa, API sözleşmesi iki aracın da dışında yönetiliyorsa ve kurum koordinasyon maliyetini kabul ediyorsa iki uzman araç anlamlıdır. Bu koşullar yoksa ikinci araç, ürünün ömrü boyunca birinin denetlemesi gereken bir sınır ekler.

Tek yapay zeka uygulama oluşturucusuna mı, iki araca mı ihtiyacınız var?

Aynı ürün, arka uç, veri modeli ve kimlik sistemi iki istemciye de hizmet veriyorsa tek oluşturucuyu seçin. İki aracı, ancak platform uzmanlığı ortak bağlamdan daha değerliyse ve sınırı korumakla görevli kişileriniz varsa seçin.

Aşağıdaki puanlar, bir kurucu ya da küçük ürün ekibi, tek bir Go API, tek bir PostgreSQL veritabanı, React web istemcisi ve Flutter mobil istemcisi varsayar. 5 puan, yaklaşımın konuyu az elle koordinasyonla desteklediği anlamına gelir. 1 puan ise ekibin eksik bağlantıyı kendisinin kurup denetlemesi gerektiği anlamına gelir.

Bu rakamlar ürün kıyaslaması değil, karar desteğidir. Bir aday kaynak kodu dışa aktaramıyor, gerçek bir arka uç modelleyemiyor ya da web ve mobili tek dağıtıma zorluyorsa puanını ciddi biçimde düşürün. API sözleşmesi, kimlik hizmeti, sürüm ilkesi ve uyumluluk testlerine olgun bir platform ekibi sahipse iki araçlı kurulum da puan kazanabilir.

Ekranları ya da istemleri saymayın. Yetki kaynaklarını sayın. Her iş gerçeği için tek yetki, tek API sözleşmesi, tek kimlik ilkesi ve tek geçiş dizisi istersiniz. React ve Flutter bu kararların tüketicileridir.

Ortak iş mantığı iki istemcinin arkasında yer almalı

İzinleri, fiyatlandırma kurallarını, iş akışı geçişlerini, kotaları ve saklanan veriyi koruyan doğrulamaları arka uca koyun. React ve Flutter hızlı geri bildirim için hafif kontrolleri tekrarlayabilir, ancak son kararı API vermelidir.

Ekipler sıkça iki farklı şeye «ortak mantık» der. Ortak kaynak kodu, iki istemcinin de aynı uygulamayı içe aktarmasıdır. Ortak iş davranışı ise iki istemcinin tek bir yetkiden aynı sonucu almasıdır. React ve Flutter farklı diller ve kullanıcı arayüzü modelleri kullanır; aralarında uygulama paylaşımını zorlamak, genellikle iki istemciden de daha zor anlaşılır üçüncü bir soyutlama yaratır. Bunun yerine davranışı API üzerinden paylaşın.

Bir siparişin draft durumundan submitted durumuna geçebilmesi için en az bir satır öğesi olması ve hesabın etkin olması gerektiğini varsayalım. Her istemci bu kuralın sahibiyse kısa sürede dört sürüm oluşur: React'in form kontrolü, Flutter'ın düğme durumu, web gönderim işleyicisi ve mobil gönderim işleyicisi. İlke değişikliği, herhangi bir istemci yayınlanmadan önce her yere ulaşmalıdır. Eski bir mobil derleme aylarca yüklü kalabilir.

Arka uç izin verilen eylemi göstermeli, eylem geldiğinde de yeniden uygulamalıdır:

{
  "order_id": "ord_4821",
  "status": "draft",
  "allowed_actions": ["submit"],
  "version": 7
}

İstemciler eylemi nasıl göstereceklerine karar verir. Sunucu, submit eyleminin 7. sürümde geçerli olup olmadığına karar verir. Başka bir istek siparişi önce değiştirirse, sunucu son yazanın sessizce kazanmasına izin vermek yerine çakışma döndürür.

React'in belgeleri, her durum parçası için tek bir doğruluk kaynağı önerir. Bu öneri, tüm çok istemcili ürün için değil, tarayıcı ağacının içi için geçerlidir. Web uygulaması ile mobil uygulamanın ortak üst öğesi arka uç sözleşmesidir. Kalıcı iş durumunu buraya taşımak, sistem sınırında aynı fikri izler.

Flutter'ın mimari rehberi görünümleri ve görünüm modellerini depolardan ve hizmetlerden ayırır. Ayrıca hizmetlerin harici API uç noktalarını sarmaladığını, depoların ise sonuçları alan modellerine dönüştürdüğünü söyler. Bu, iyi bir istemci sınırıdır. Depoyu, Dart'ta sunucu ilkesini yeniden kurma izni olarak yorumlamayın. Mobil depo veriyi önbelleğe alabilir, yeniden deneyebilir ve eşleyebilir; bir siparişin gönderilip gönderilemeyeceği konusunda ikinci yetkiye dönüşmemelidir.

Bazı mantıklar haklı olarak istemciye özgü kalır: girdi biçimlendirme, çevrimdışı sunum, gezinme, animasyon ve cihaz izni yönetimi. Mobil uygulama çevrimdışıyken taslağı kuyruğa alabilir, web uygulaması ise hemen kaydedebilir. Bağlandıklarında ikisi de aynı sunucu kuralına aynı komutu göndermelidir.

PostgreSQL bir API'nin arkasında durmalı

Ne React paketi ne de Flutter uygulaması doğrudan PostgreSQL'e bağlanmalıdır. Bunlar, kodları ve bağlantı ayrıntıları kullanıcılar tarafından incelenebilen, kopyalanabilen ve değiştirilebilen dağıtılmış istemcilerdir.

PostgreSQL kılavuzu, istemci kimlik doğrulamasını veritabanı sunucusunun bir istemcinin istenen veritabanı kullanıcısı olarak bağlanıp bağlanamayacağına karar vermesi olarak açıklar. Bu mekanizma veritabanı bağlantısını korur. Alice'in 42 numaralı siparişi düzenleyip 43 numaralı siparişi düzenleyemeyeceğini ya da eski mobil derlemenin yeni eklenmiş iş akışı geçişini kullanmaması gerektiğini anlamaz. Uygulama yetkilendirmesi API'de olmalıdır.

React'ten doğrudan bağlantı özellikle kabul edilemezdir; çünkü tarayıcının veritabanına ağ erişimi olması ve indirilen koda kimlik bilgilerinin eklenmesi gerekir. Flutter'a parola koymak, birisi uygulamayı çıkarana kadar gizler. Satır düzeyi güvenlik PostgreSQL içinde ek savunma sağlayabilir, ancak güvenilmeyen istemciyi güvenli veritabanı eşine dönüştürmez. Yüklü derlemeleri bozmadan şemaları geliştirebileceğiniz sabit uç noktalara, hız kontrollerine, girdi sınırlarına, denetim bağlamına ve bir yere yine de ihtiyacınız vardır.

Tek bir herkese açık uygulama sınırı kullanın:

React client  \
               -> HTTPS API -> domain rules -> PostgreSQL
Flutter client /

API'ye sınırlı yetkili veritabanı rolü verin. Geçiş kimlik bilgilerini çalışan uygulamanın dışında tutun. Geçişleri kendi inceleme ve kurtarma planlarıyla ayrı dağıtım görevi olarak çalıştırın. Bu ayrım, ele geçirilmiş API sürecinin yapabileceklerini sınırlar ve iki istemcinin de veritabanı kimlik bilgilerini öğrenmesini önler.

İki yapay zeka aracı bazen her biri eksiksiz proje istediği için iki arka uç üretir. İki hizmet bilinçli bir alan ayrımı değilse bu çıktıyı reddedin. Aynı tablolara yazan web ve mobil arka uçları, yinelenen yetkilendirme, tutarsız işlemler ve her şema değişikliğinde onarım gerektiren iki yer yaratır. Her istemcinin farklı yanıt biçimlerine ihtiyacı olduğunda ince bir istemciye özel arka uç makul olabilir, ancak bu uyarlayıcılar etrafından yazmak yerine aynı alan hizmetini çağırmalıdır.

Sınırı basit ama etkili bir testle kontrol edin. Oluşturulan React ve Flutter depolarında PostgreSQL bağlantı dizelerini, veritabanı ana makine değişkenlerini, SQL sürücülerini ve ayrıcalıklı hizmet kimlik bilgilerini arayın. İstemci kodunda bunlardan birini bulmak mimari incelemesini başarısız kılar. Beklenen istemci yapılandırması yalnızca API temel URL'si, herkese açık kimlik yapılandırması ve gizli olmayan özellik ayarlarını içerir.

Veritabanı geçişleri de geriye dönük uyumluluk ister. Önce boş olabilen sütun ya da yeni tablo ekleyin, iki biçimi de işleyebilen kodu dağıtın, gerekirse veriyi doldurun, okumaları değiştirin ve eski alanı ancak desteklenen istemciler artık ona bağlı olmadığında kaldırın. Mobil dağıtım, son aralığı yalnızca web ekibinin beklediğinden daha uzun kılar.

Kimlik doğrulamanın tek yetkisi, iki istemci uyarlayıcısı vardır

Tek kimlik sağlayıcısı, tek kullanıcı kaydı ve tek sunucu tarafı yetkilendirme ilkesi kullanın; sonra ayrı tarayıcı ve mobil oturum uyarlayıcıları uygulayın. Kimlik doğrulama, çağıranın kim olduğunu kanıtlar. Yetkilendirme, çağıranın ne yapabileceğine karar verir. Bunları birbirine karıştırmak, geçerli belirteci kabul edip ardından istemcinin yasak eylemleri gizlemesine güvenen uç noktalar üretir.

React istemcisi genellikle tarayıcı yönlendirme davranışı, çerezler ya da belirteçler, siteler arası istek korumaları ve yenileme sırasında yarışabilen sekmelerle çalışır. Flutter, derin bağlantıları, uygulamanın askıya alınmasını, cihaz depolamasını ve işletim sistemi geri çağrılarını ele almalıdır. Bu farklar ayrı istemci kodunu haklı çıkarır. Ayrı kullanıcı dizinlerini ya da roller için farklı anlamları haklı çıkarmaz.

OWASP'ın Mobil Uygulama Güvenliği Bilgi Notu, kimlik bilgilerini sabit kodlamamayı ve platforma özgü güvenli mekanizmalarla saklanan, iptal edilebilir güvenli erişim belirteçlerini önerir. Bu ilkeyi izleyin, ancak güvenli depolamanın neleri yapıp yapamayacağını unutmayın. Dosyalardan belirteç çalınmasını zorlaştırır. Ele geçirilmiş cihazı güvenilir kılmaz; bu nedenle API her korunan işlemde sona erme tarihini, hedef kitleyi, sağlayıcıyı, hesap durumunu ve izni yine kontrol eder.

İki istemciden herhangi birine ekranları uygulamasını istemeden önce kimlik sözleşmesini yazın:

Access token: short lived, sent to the API
Refresh mechanism: rotated or invalidated by the identity system
Logout: ends the local session and revokes server-side refresh authority
Account disabled: API rejects new operations even if a client still shows cached data
Role changed: next authorized request uses current server policy

En açıklayıcı test başarılı giriş değildir. İki istemci de açıkken hesabı devre dışı bırakın. Her istemciden gelen sonraki korunan istek aynı biçimde başarısız olmalı, yerel özel veriler ilkeye göre temizlenmeli ve hiçbir istemci yenilemeyi sonsuza dek denememelidir. Ardından bir rolü değiştirin ve eski bir ekranın önceki eylemi gerçekleştiremediğini doğrulayın.

Rol gerçeğini, eski yetkilendirmeye ne kadar süre dayanabileceğinizden daha uzun süre belirteç iddialarına koymaktan kaçının. İddialar kullanıcı arayüzünün hızlı çizilmesine yardımcı olabilir, ancak hassas işlemler için sunucu güncel ilkeye bakmalıdır. Rol değişikliği hemen etkili olmalıysa eski rolleri taşıyan uzun ömürlü, kendi kendine yeterli belirteç bu gereksinime aykırıdır.

Tek oluşturucu burada 5 yerine 4 puan alır; çünkü ortak bağlam platform güvenliği işini ortadan kaldırmaz. Oluşturucu iki uyarlayıcıyı da üretebilir, ancak bir kişinin yine tarayıcı yönlendirmelerini, mobil derin bağlantıları, yenileme yarışlarını, saat farkını, iptali ve cihaz geri yükleme davranışını test etmesi gerekir.

Tek sözleşme React ve Flutter'ı tutarlı kılar

API açıklamasını iki istemci için de derleme girdisi ve yayınlanmış sürümler için uyumluluk sözü olarak ele alın. Düzyazı bir istem sözleşme değildir; çünkü iki üretim çalışması aynı cümleyi farklı yorumlayabilir.

OpenAPI, HTTP API'leri için pratik bir seçimdir. İstek alanlarını, yanıt alanlarını, hata gövdelerini, kimlik doğrulama gereksinimlerini ve sabit işlem tanımlayıcılarını tanımlayın. Bu belgeden ince TypeScript ve Dart istemcileri üretin ya da elle yönetin; ardından uygulama davranışını sıradan React kancalarında ve Flutter depolarında tutun. Oluşturulan istemci kodu değiştirilebilir olmalı; ürün kararlarını onun içine gömmeyin.

Bu parça sürüm çakışmasını açıkça gösterir:

/orders/{orderId}/submit:
  post:
    operationId: submitOrder
    requestBody:
      required: true
      content:
        application/json:
          schema:
            type: object
            required: [expected_version]
            properties:
              expected_version:
                type: integer
    responses:
      "200":
        description: Order submitted
      "409":
        description: Order changed since the client loaded it

Doğruluk kaynağı sunucu davranışı ve denetlenen sözleşmedir. Oluşturulan TypeScript ve Dart türleri bunun yansımalarıdır. Bir araç sözleşmeyi değiştirmeden istemci türünü düzenlerse, derleme bu düzenlemeyi üzerine yazmalı ya da reddetmelidir.

Sözleşme testleri, statik şemaların ifade edemediği davranışları çalıştırmalıdır. Boş sipariş gönderin ve iki istemci tarafından oluşturulan isteklerden aynı hata kodunu bekleyin. Eski expected_version içeren isteği tekrar oynatın ve 409 bekleyin. Eski istemci sabitine bilinmeyen enum değeri gönderin ve çökmeden güvenli biçimde geri düştüğünü kontrol edin.

Eklemeli API değişikliklerini tercih edin. İstemciler bilinmeyen alanları yok saydığında yeni isteğe bağlı yanıt alanları genellikle güvenlidir. Alan kaldırmak, isteğe bağlı alanı zorunlu yapmak veya enum değerini yeni anlamla yeniden kullanmak, yüklü mobil derlemeyi bozabilir. Yalnızca anlamı koruyamadığınızda uç noktayı sürümleyin; rutin sürüm yükseltmeleri uyumluluk yükünü daha fazla dizine taşır.

Alan modellerini platformlar arası pakette paylaşmaya dair yaygın bir öneri vardır. Sipariş, hesap ve fatura iki istemcide de göründüğü için verimli gelir. Uygulamada TypeScript ve Dart paketleri yine ayrı serileştirme davranışı, null işleme, tarih işleme ve sürüm araçları gerektirir. Aktarım biçimlerini tek sözleşmeden üretin, sonra her istemcinin bunları yerel kullanıcı arayüzü modellerine eşlemesine izin verin. Ortak tanımlar yararlıdır. Zorunlu ortak çalışma zamanı modeli yararlı değildir.

Sözleşme, iki aracı da daha uygulanabilir kılar. Her araca gelişigüzel yeniden yorumlayamayacağı bir sınır verir. Ancak üretim oturumlarının dışında birinin sözleşme değişikliklerinin, uyumluluk kontrollerinin ve sürüm notlarının sahibi olması gerekir. Bu görev kimsede değilse sözleşme uygulamaların gerisinde kalır.

Sürüm trenleri bağımsız kalmalı

Tek oluşturucu üçünü de oluştursa bile web istemcisini, mobil istemciyi ve API'yi ayrı takvimlerle yayınlayın. Koordineli üretim, koordineli dağıtım gerektirmez.

React, dağıtımdan dakikalar sonra kullanıcılara ulaşabilir. Mobil sürümler mağaza incelemesinden geçer ve kullanıcılar güncellemeyi erteleyebilir. Bu nedenle API, güncel web derlemesini ve ekibin destek süresindeki her mobil sürümü desteklemelidir. Tüm istemcilerin birlikte güncelleneceğini varsayan sürüm planı, ilk gecikmiş incelemede ya da kademeli yayında başarısız olur.

Her değişiklik için uyumluluk matrisi kullanın:

Hücrelerdeki sözcükler sürüm numaralarından daha önemlidir. Ekibi eski istemcinin gerçekte ne yaptığını söylemeye zorlarlar. Matrisi değişiklik planında tutun ve mümkün olduğunda iddialarını testlere dönüştürün.

Güvenli özellik yayını çoğunlukla şu sırayı izler:

1. Geriye dönük uyumlu veritabanı yapıları ve API davranışı ekleyin.
2. Yeni yanıtı anlayan, ancak özelliği gizli tutan istemcileri yayınlayın.
3. Yazmaları etkinleştirmeden önce hataları ve uyumluluk sinyallerini gözlemleyin.
4. Özelliği sunucunun denetlediği yetenek ya da hesap ayarıyla etkinleştirin.
5. Eski yolları ancak destek süresi kapandıktan sonra kaldırın.

Özellik bayrakları görünürlük için yararlıdır, uyumsuz şemaları onarmak için değil. Eski istemci yeni zorunlu alanı ya da enum'u ayrıştırırken çöküyorsa, başlangıçtan sonra düğmeyi kapatmak onu kurtarmaz. Uyumluluk, yük tasarımında olmalıdır.

İki araç platforma özgü paketlemede güçlü olabilir. Mobil odaklı oluşturucu mağaza meta verilerini ve cihaz yetkilerini daha iyi anlayabilir; web odaklı oluşturucu ise tarayıcı dağıtımını iyi yönetebilir. Bu güçlü yanlar API hazırlığını, özellik görünürlüğünü ve destek sürelerini koordine etmenin ek işinden ağır basıyorsa iki araçlı yaklaşıma daha yüksek sürüm puanı verin.

Sürüm tanımlayıcılarını günlüklerde ve hata raporlarında görünür tutun. Operatörlerin tarayıcı regresyonunu eski mobil davranıştan ayırt edebilmesi için her API isteği gizli olmayan istemci adını ve derleme tanımlayıcısını taşımalıdır. İstemci bunu taklit edebileceği için bu tanımlayıcıya yetkilendirme amacıyla güvenmeyin.

Geri alma üç farklı anlama gelir

İstemci geri alma, sunucu geri alma ve veri geri alma farklı arızaları çözer; her biri için ayrı prosedür gerekir. Bunları tek bir «geri al» düğmesi saymak, kurtarılabilir sürümün veri kaybına dönüşmesinin yoludur.

React dağıtımı genellikle trafiği önceki yapıya yönlendirebilir. Mobil geri alma çoğu zaman kademeli yayını durdurmak ve düzeltilmiş derlemeyi göndermek demektir; güncellemiş cihazlar sorunlu sürümü kullanmayı sürdürebilir. API bu süre boyunca iki sürümü de tolere etmelidir.

Sunucu kodu ancak veritabanı eski ikiliyle uyumlu kaldığında geri alınabilir. Eklemeli geçiş buna çoğunlukla izin verir. Sütunu yerinde yeniden adlandıran, anlamı değiştiren veya veri silen geçiş izin vermeyebilir. Genişlet ve daralt geçişleri kullanın: yeni gösterimi ekleyin, iki kod sürümünün de çalışmasına izin verin, veriyi taşıyın, okumaları değiştirin ve eski gösterimi sonra kaldırın.

Veri geri alma tehlikeli olandır. Veritabanı anlık görüntüsünü geri yüklemek, anlık görüntüden sonra yapılmış geçerli yazmaları siler. Birçok üretim olayında ileri yönlü onarım daha güvenlidir: düzeltilmiş kodu dağıtın, etkilenen satırları denetim sorgusuyla belirleyin ve dar kapsamlı telafi değişikliği uygulayın. Anlık görüntüler felakete karşı korur, ancak geri alınabilir geçişin sıradan yerine geçmez.

Tipik bir arızayı ele alalım. API dağıtımı delivery_window alanını zorunlu yapar. Yeni web istemcisi alanı gönderir. İncelemedeki mobil derleme göndermez. Ekip veritabanı sütununu NOT NULL yapar ve eski mobil gönderimler sunucu hatası döndürmeye başlar. Yalnızca web istemcisini geri almak hiçbir şeyi değiştirmez. Yalnızca API'yi geri almak, eski ikili yeni şemayı okuyamıyorsa başarısız olabilir. Tüm veritabanını geri yüklemek ilgisiz siparişleri siler.

Temiz kurtarma, API'nin eksik alanı kabul etmesi, belgelenmiş bir varsayılan ataması ya da geçişi ertelemesi ve mobil destek yeterince yaygınlaşana dek alanı isteğe bağlı döndürmesidir. Böylece ekip ilgisiz yazmaları geri sarmadan etkilenen kayıtları onarabilir. Asıl hata geri alma düğmesinin eksikliği değildi. Uyumsuz diziydi.

Her değişiklik için dağıtımdan önce şu dört satırı yazın:

Web rollback: artifact and routing action
Mobile containment: rollout stop, affected builds, fixed build path
API rollback: compatible binary and schema range
Data repair: query, owner, backup point, and forward correction

Tek oluşturucu, anlık görüntüleri ve planlama geçmişi ilgili değişikliği kapsadığında yardımcı olur, ancak kapsamı doğrulayın. Kaynak anlık görüntüsü, dağıtılmış yapı ve PostgreSQL yedeği farklı varlıklardır. İnandırıcı geri alma testi, her varlığı geçici ortamda geri yükler ve eski istemcinin ana yazma akışını hâlâ tamamlayabildiğini kanıtlar.

İki oluşturucu entegrasyon sahipliğini artırır

İki araç bakımı yarıya indirmez. İki üretim geçmişi, iki varsayım kümesi ve ikisinin de dışında yaşayan bir entegrasyon yüzeyi oluşturur.

İlk ay daha hızlı görünebilir; çünkü her araç alışıldık platform kodu üretir. Maliyet değişiklik sınırı geçtiğinde ortaya çıkar: alanı yeniden adlandırmak, izni değiştirmek, hesap durumu eklemek, çıkış davranışını değiştirmek veya uç noktayı kullanımdan kaldırmak. Her istemin güncel sözleşmeyi ve diğer istemcinin sürüm durumunun sonuçlarını içermesi gerekir. Tek ayrıntıyı kaçırmak, derlenen ancak ürün davranışını ihlal eden makul kod üretir.

Arıza kalıbı öngörülebilirdir. Web aracı enum'a archived ekler ve doğru biçimde gösterir. Mobil araç bilinmeyen değerleri hâlâ ayrıştırma hatası sayar. API önce dağıtılır, kullanıcının listesinde arşivlenmiş kayıt görünür ve mobil ekran tüm kayıtları yüklemeyi durdurur. Yerel her değişiklik makul görünüyordu. Kimse sürümler arası birleşimi test etmedi.

Bakımın bir sahibi ve tekrarlanabilir değişiklik paketi olmalıdır:

• Davranış değişikliği ve onun sahibi olan sunucu kuralı
• API ve geçiş farkı
• React kabul senaryoları
• Flutter kabul senaryoları
• Sürüm sırası ve geri alma sınırları

Bu paket tek oluşturucuyla da yararlıdır, ancak tek planlama bağlamı onu tüm değişikliğe bağlı tutabilir. İki araçla ekip paketi aralarında kopyalamalı, iki çıktıyı kaydetmeli ve çelişen düzenlemeleri uzlaştırmalıdır. Otomasyon şema ayrışmasını saptayabilir; hangi yorumun ürüne uyduğuna karar veremez.

Kaynak kodu dışa aktarmanın araç bağımlılığını bitirdiğini varsaymayın. Dışa aktarılan kod size sahiplik verir ve bu önemlidir, ancak sürdürülebilirlik okunabilir yapıya, testlere, bağımlılık seçimlerine, derleme yönergelerine ve yalnızca değişen kısmı yeniden üretmek için temiz yola bağlıdır. Oluşturulan projeyi, oluşturucu yarın ortadan kaybolacakmış gibi inceleyin. Yetkin bir React geliştiricisi web istemcisini yayınlayabilir mi, Flutter geliştiricisi mobil uygulamayı derleyebilir mi, arka uç geliştiricisi özgün sohbet geçmişi olmadan PostgreSQL geçişi yapabilir mi?

Bakımı sıradan kanıtlarla izleyin: sözleşme testi başarısızlıkları, oluşturulan değişiklikleri uzlaştırmak için harcanan süre, yeniden üretimde kaybolan elle düzenleme sayısı, desteklenmeyen istemci sürümleri ve kurtarma provası sonuçları. Paylaşılan kod satırı gibi gösteriş ölçüsünden kaçının. Az miktarda yinelenen sunum eşlemesi, akıllıca görünen paylaşım katmanından daha ucuz olabilir.

İki oluşturucu, iki ekip zaten bu şekilde çalıştığında makul hale gelir. Her ekip kendi istemcisinin sahibidir, platform grubu API ve kimliğin sahibidir, otomatik uyumluluk testleri de sürümden önce çalışır. Bu ortamda araçlar kuruma uyar. Tek başına kurucu, sahip olmadığı bir organizasyon şemasını taklit etmemelidir.

Kararı nasıl vermelisiniz?

Yaklaşımı, her aracın ilk ekranı ne kadar hızlı çizdiğini karşılaştırarak değil, istemciler arası tek değişikliği kanıtlayarak seçin. Deneme şema değişikliği, yetkilendirme kuralı, eski mobil derleme, bağımsız sürümler ve geri alma provasını içermelidir.

Tek oluşturucu adaylarından küçük bir dikey dilim oluşturmalarını isteyin: React ve Flutter istemcileri, PostgreSQL destekli Go API'ye aynı sipariş komutunu göndersin. İki istemci çalıştıktan sonra kuralı değiştirin. İsteğe bağlı alan ekleyin, bir rolü engelleyin, yalnızca web değişikliğini yayınlayın ve yeni satırları kaybetmeden önceki sunucu yapısını geri yükleyin. Kaynak kodu dışa aktarın ve testlerini oluşturucunun arayüzünün dışında çalıştırın.

İki araç adayından, ikisine de sağlanan denetlenmiş OpenAPI belgesiyle aynı diziyi gerçekleştirmelerini isteyin. Oturumlar arasında kaç bilgiyi kopyalamanız gerektiğini ve bir aracın ne sıklıkla sınırının dışını düzenlediğini ölçün. Yalnızca üretim süresini değil, ayrışmayı teşhis etmek için gereken süreyi de dahil edin.

Tek oluşturucuyu şu eşikleri geçiyorsa kullanın:

• Tek sözleşme etrafında ayrı React, Flutter ve arka uç projeleri oluşturur.
• PostgreSQL'i arka ucun arkasında tutar, gizli bilgileri istemcilerden uzak tutar.
• Bağımsız istemci ve sunucu sürümlerini destekler.
• Kaynak kodunu, dağıtım durumunu ve ayrı kurtarma noktalarını sunar.
• Oluşturduğu kod, sohbet geçmişine dayanılmadan derlenip test edilebilir.

Uzman yetenek mobil ya da web sonucunu kayda değer biçimde değiştiriyorsa ve sözleşme yönetiminin sahibi adıyla belliyse iki aracı seçin. «Mobil çıktısı daha güzel göründü» yeterli değildir. Cihaz entegrasyonu, erişilebilirlik davranışı, mağaza paketleme, çevrimdışı çalışma ya da mevcut ekip becerisi, fayda bakım hesabından sonra da kalıyorsa yeterli olabilir.

Koder.ai; tek sohbet bağlamından React, PostgreSQL kullanan Go ve Flutter uygulamaları, planlama modu, kaynak kodu dışa aktarma, dağıtım ve barındırma, anlık görüntüler ve geri alma oluşturabilir. Bu birleşim burada açıklanan tek oluşturucu mimarisine uyar, ancak özellik listesi sürüm ve kurtarma yolunuzu kanıtlayamayacağı için dikey dilim testini yine de yapmalısınız.

Karar daha sonra değişebilir. Sınırları iyi çizilmiş sistem, ekibin iş kurallarını API'nin dışına taşımadan React oluşturucusunu, Flutter oluşturucusunu ya da ikisini birden değiştirmesine izin verir. İlk mimariniz bu seçeneği korumalıdır.

Rahatsız edici test basittir: mobil araç sürüm gününde ortadan kaybolsaydı, güncel API sözleşmesini açıklayabilir, dışa aktarılan istemciyi derleyebilir ve yayın yapmaya devam edebilir miydiniz? Yanıt hatırlanan istemlere bağlıysa başka araç eklemeden önce sahiplik modelini düzeltin.