Yapay zekâ ile API tiplerini yazarken Zod’a nerede sınır çiziyorsunuz?

2 Yanıt 9 Görüntülenme
Puanlayanlar
Katılımcılar
Konuyu Açan #1
Son zamanlarda kod asistanlarına API yanıt örneklerinden TypeScript tipi ve Zod şeması çıkarttırıyorum. Hız kazandırıyor ama bir noktada önemli bir ayrım beliriyor: TypeScript tipi derleme zamanında yardımcı oluyor; sunucudan gerçekten gelen veriyi doğrulamıyor. Asistanın ürettiği şemayı doğrudan kabul etmek bu yüzden içime sinmiyor.

Benim iş akışımda en çok şu iki kontrol işe yarıyor:

  • Birkaç gerçek yanıt örneği veriyorum: başarılı yanıtın yanı sıra eksik alan, null değer ve hata yanıtı da olsun. Tek bir örnekten çıkarılan tip, çoğu zaman alanların isteğe bağlı mı yoksa nullable mı olduğunu karıştırabiliyor.
  • Şemayı oluşturduktan sonra sınır durumlarını test ettiriyorum. Özellikle union türlerinde, örneğin farklı durumlara göre değişen yanıt nesnelerinde, ayrımı sağlayan alanı ve bilinmeyen alanların nasıl ele alınacağını ayrıca gözden geçiriyorum.


Yine de her küçük, güvenilir iç API için çalışma anında doğrulama eklemek gerekli mi, emin değilim. Dış servislerden gelen veya uygulamanın kritik akışlarını etkileyen verilerde değeri açık; sabit ve kontrol edilen bir yapıda maliyetine değmeyebilir.

Siz yapay zekâya şema üretimini hangi ölçüde bırakıyorsunuz; Zod gibi çalışma zamanı doğrulamasını hangi sınırda vazgeçilmez görüyorsunuz?
#2
TechWizard şöyle dedi:
TypeScript tipi derleme zamanında yardımcı oluyor; sunucudan gerçekten gelen veriyi doğrulamıyor.

Tam da sınırı burada çiziyorum: Zod’u her fonksiyon çağrısına değil, güvenilmeyen verinin sisteme girdiği noktaya koyuyorum. Dış API yanıtı, webhook, kullanıcı girdisi ve kritik iş akışındaki mesajlar mutlaka doğrulanmalı. Böylece içeride aynı veriyi katman katman tekrar parse edip maliyet ve karmaşa yaratmıyorum.

Kontrollü iç API’de de “güvenilir” varsayımı sözleşme testleri ve dağıtım disipliniyle destekleniyorsa her yanıtı çalışma anında doğrulamak şart değil; ama servisler bağımsız dağıtılıyorsa sınır yine gerçek. Yapay zekânın ürettiği şemayı taslak kabul ederim; optional ile nullable ayrımını ve union ayracını elle kontrol ederim. Bilinmeyen alanlarda ise katı reddetme kararını API’nin sürümleme ve ileriye uyumluluk beklentisine göre veririm.
#3
WebMasterX şöyle dedi:
Zod’u her fonksiyon çağrısına değil, güvenilmeyen verinin sisteme girdiği noktaya koyuyorum.

Bu yaklaşım bana da doğru geliyor; yalnız “kontrollü iç API” kısmında sözleşme testlerini çalışma zamanı kontrolünün tam ikamesi saymamak lazım. Testler bilinen senaryoları yakalar, dağıtımlar arasında oluşan uyumsuzluğu veya beklenmedik bir yanıtı her zaman yakalayamaz. Servisler ayrı dağıtılıyorsa tüketici tarafında en azından kritik yanıtları doğrulamak ucuz bir emniyet kemeri olabilir.

Bilinmeyen alanlarda da kararın yanında uygulanan davranışı açıkça seçmek önemli: reddetmek, yok saymak ya da veriyi korumak farklı sonuçlar doğuruyor. Özellikle şemadan türetilen tiplerde doğrulama sonrası elde edilen verinin dönüştürülüp dönüştürülmediğini de kontrol ediyorum; sadece “parse geçti” demek her zaman beklenen veriyi aldığımız anlamına gelmiyor.

Yanıt vermek için giriş yapmış olmalısınız.

0 alıntı seçildi