GraphQL ile ilgili sorunları daha da genişletelim GraphQL çekirdeğinin avantajı, sözde tip sistemi değildir; aslında, güçlü tip kısıtlamaları RESTful sistemlerde iyi uygulanabilir. Zod'un çok terminalli kod üretebilen orpc şemasından tam anlamıyla yararlanarak, Python ekosistemindeki FastAPI + Pydantic çözümü benzer etkiler elde edebilir GraphQL'nin temel avantajı, müşterilerin ihtiyaçlarına göre esnek şekilde veri talep etmelerine olanak sağlamasıdır. Bu aynı zamanda geleneksel BFF katmanının uyguladığı ana özelliklerden biridir. Ancak geleneksel BFF katmanından fark, GraphQL uygulamasının genellikle iş dünyasına sıkı sıkıya bağlı olması ve benzer sorunlarla ilgilenecek ayrı bir altyapının olmamasıdır. Bu durumda, esneklik GraphQL sisteminde (veya benzer BFF planları) birçok sorun getirecektir (veya işe girdikten sonra benzer BFF planlarıyla karşılaşacak). En basit halinde, esneklik daha büyük bir saldırı yüzeyine yol açar. En basit halinde, kötü niyetli bir kullanıcı, basit AST ayrıştırma yoluyla sunucu kaynaklarınızın çoğunu tüketecek kadar karmaşık bir sorgu oluşturabilir. Elbette, birçok kişi "Ah, neden Sorgu'nun karmaşıklığını sınırlamıyorsun?" diyebilir. O halde size soracağım, Sorgu karmaşıklığını hesaplarken AST veya AST'leri çözmek gerekli mi? Tabii ki, bazı insanlar 'Sorgu desenini neden sınırlamasın?' diyebilir. O zaman size sormak istiyorum, kalıplarınız da AST'leri çözmeli mi? Ve GraphQL'nin en büyük avantajını sınırlıyorsunuz, sizin geleneksel RESTful API'lerle aranızdaki fark nedir? Ayrıca, GraphQL'nin AST ayrıştırması iş dünyasından çözülmezse, Node'un tek iş parçacıklı modeliyle olay döngüsü gecikmeniz doğrudan büyür ve kullanıcı deneyimi N seviye yükselir GraphQL'nin kendisinin yapması gereken birçok şey, işi çözmek için ayrı bir altyapı tarafından çözülmek zorunda; örneğin sorgu düzeyinde hız sınırları, özel kimlik doğrulama mantığı vb Açıkçası, GraphQL veri platformları veya dahili hizmetler için iyi bir tercih olabilir. Ancak, yüksek hacimli toC hizmetleri için GraphQL, geleneksel RESTful API'lere göre daha fazla karmaşıklık ve belirsizlik getirecek ve bu API'ler daha fazla altyapı geliştirme gerektirecek.

Bir noktaya daha değinmek istiyorum GraphQL, Facebook tarafından dünya çapında başarılı bir teknoloji dolandırıcılığıdır

AIGC Startup SRE olarak AWS'nin bazı operasyonlarını kısaca gözden geçirelim, umarım herkese yardımcı olabilir Ana kümemizin USE1 olduğunu keşfetmek için işe alımın başlangıcından itibaren bazı hazırlıklar yapmaya başladım. Bunlar benim yaptığım başlıca şeyler 1. Çekirdek veritabanlarımızın birçoğu birden çok yerde yedeklenerek USE1, Tokyo ve SG yedekleri oluşturulmuştur. Bu sayede aşırı durumlarda verilerin bir kısmını kaybediyoruz ama aynı zamanda hizmetin devamını da sağlayabiliyoruz 2. SG test kümemizi orijinal EC2 K3S'den standart bir AWS EKS kümesine yeniden yapılandırın. Bu, bir olağanüstü durum durumunda kümeyi hızlı bir şekilde ısıtmanıza ve mevcut AWS bileşenlerini yeniden kullanmanıza olanak tanır. Bildirim değişikliklerinin maliyetini en aza indirin 3. Kullanıcı duyuruları, DNS değiştirme, sürüm engelleme vb. dahil olmak üzere bir SOP'yi kısaca sıralayın Bugün, AWS olayından yaklaşık 10 dakika sonra, konteynerlerimizde kurulamayan yeni podlar olduğunu keşfettim. AWS Destek ile bunun bir USE1 sorunu olduğunu onayladıktan sonra, ECR olaylarının diğer olaylarla ilgili olması gerektiğini fark ettim, bu yüzden Tier1 düzeyindeki olayları kendi planıma göre işlemeye karar verdim (SRE'ler için bu tür şeylerin yanlış olması kaçırılmasından daha iyidir) T+0 dk, tüm personele bir anons yaptım ve acil durum moduna girmeye başladım. Herkesin katıldığı halka açık bir toplantı düzenledim. Tüm insanlar istedikleri zaman katılabilir T+2 dk, etkinliğin beklediğim gibi kademeli olarak genişlediğini doğruladım ve iki talimat verdim, 1. Pano genelinde herhangi bir kod birleştirmeyi/işlemeyi yasaklayın (esas olarak yeni oluşturulan kaynakların pod rotasyonunun trafiği etkilemesine neden olmasını önlemek için), 2. Lütfen operasyon öğrencileri için bir duyuru hazırlayınız T+3 dk, SOP'yi takip etmeye başladım, SG bölgesinde veritabanı kurtarmayı başlattım ve OpenSearch/Redis vb. bağımlılıklar oluşturmak için basamaklı geçiş yaptım T+5 dakika, yukarı ve aşağı bağımlılıkların belirli sorunlarını resmi olarak doğrulamaya başladık ve yeni başlatılan bir çekirdek hizmetin etkilendiğini doğruladık T+10dk, hizmet askıya alma duyurumuz ve diğer hizmetler için etkilenen duyuru yayınlanacaktır T+10dk, diğer iki kişiden yeni ECR'nin kurulmasına ve test ortamındaki mevcut kaynakların aynı anda temizlenmesine ve CTO'nun senkronize edilmesine yardımcı olmalarını istedim, aşırı durumlarda deneyimi koruma ve veri kaybetme kararı alabiliriz. T+15dk, sonunda şu ana kadar oluşturulan kaynakların ve gelen trafiğin yönünün büyük ölçüde etkilenmeyeceğini doğruladık. Geçiş beklemede, ancak ilgili kaynakları hazırlamaya devam ediyoruz T+30dk, ilk veritabanımız geri yüklendi T+40dk, ikinci veritabanımız geri yüklendi T+1h, ilişkili tüm çekirdek altyapılarımız, RDS/ES/Redis beklemede ve master-slave gibi optimizasyon seçenekleri üretim mimarisine göre ayarlanıyor. Aynı zamanda yeni kümelerde yeni hizmetler de sunmaya başlıyoruz Neyse ki, sonuçta AWS çökmesi tüm hizmetlerimizi etkilemedi. Trafiği değiştirdikten sonra karmaşık veri onarım işleriyle uğraşmak zorunda kalmıyoruz T+2 ila T+3 saat arasında tüm personele resmi olarak haber verdim ve olağanüstü hal kaldırıldı. Güvenli tarafta olmak için, bu gece yine de gösterime kapalı olacağız. Tüm olaya dönüp baktığımda, daha fazlasını yapabilirdim 1. Kendim için hazırladığım ekstrem durum SÇP'sini tüm çalışanlara açıklayın. Bu, çevrimiçi olmasam bile birisinin benim yerime geçebilmesini sağlıyor 2. Bazı ileri tatbikatlar yapabiliriz 3. Emirler daha belirleyici olabilir Neredeyse bu kadar, küçük bir paylaşım, umarım herkese yardımcı olabilir