Query, Mutation ve Stream Aynı Tür Asenkron İş Değildir

Çoğu frontend mimarisi, her asenkron sonucu aynı şekilde ele alır: bir promise çözülür, setState çağrılır, arayüz yeniden render edilir. Bu yazı, Query, Mutation ve Stream'in semantik olarak farklı iş türleri olduğunu ve hepsinin tek bir pipeline'a sıkıştırılmasının state karmaşasının başlıca kaynaklarından biri olduğunu savunuyor.

Query, tanımlanabilir bir veri gerçeğini okumakla ilgilidir; kimlik, önbellekleme ve yeniden geçerlilik kontrolüne ihtiyaç duyar ve component içinde geçici state olarak değil, reaktif graf içinde bir kaynak düğümü olarak yaşamalıdır. Mutation'ın gerçek zorluğu isteği göndermek değil, başarılı olduktan sonra hangi mevcut verilerin artık geçersiz sayılması gerektiğini belirlemektir; bu geçersiz kılma mantığını component'lere dağıtmak, etkisi global ama yönetimi yerel olan kırılgan bir sistem yaratır. Stream ise uzun ömürlü bir veri ilişkisidir; bağlantı sağlığı, backpressure, ve anlık değer ile kararlı değer ayrımı gibi konularla ilgilenir — tek bir Promise ya da setState çağrısının ifade edemeyeceği kavramlar.

Temel argüman şu: bu üç kavram 'asenkron iş tamamlandı → state güncelle → render et' şeklinde tek bir akışa indirgendiğinde, mühendisler kendi sistemleri hakkında temel sorulara cevap veremez hale gelir — bir loading state'in query mi yoksa mutation'a mı ait olduğu, ya da bir değerin kararlı mı yoksa stream ortasında mı olduğu belirsizleşir. Bu üçünü kimlik, geçersiz kılma ve yaşam döngüsü açısından ayırmak, kaybolan bu sınırı geri kazandırır.