Eve Porcello ile Çarpıcı Podcast Bölüm 31: GraphQL Nedir?

Bu bölümde GraphQL hakkında konuşuyoruz. Nedir ve bazı yaygın API sorunlarını nasıl çözer? Öğrenmek için uzman Eve Porcello ile konuştum.

Notları göster

• Twitter'da Havva
• Eve'in şirketi Moon Highway
• O'Reilly'den GraphQL Öğrenme
• GraphQL Wilderness'ta Yolunuzu Keşfedin - Eve'in GraphQL atölyesi 2021'in başlarında başlıyor

Haftalık güncelleme

• Bir Next.js Web Sitesinde Akıl Sağlığında Depolanan MDX Nasıl Kullanılır
  Jason Lengstorf'un yazdığı
• Google'ın Dialogflow'unu Kullanarak Konuşma NLP Etkin Bir Chatbot Oluşturma
  Nwani Zafer tarafından yazıldı
• UX Araştırmasında Etik Hususlar: Eğitim ve İnceleme İhtiyacı
  Victor Yocco'nun yazdığı
• Web Sitelerini Konuşmayı Kolaylaştırmak
  Frederick O'Brien'ın yazdığı
• Karmaşık Bir Çözümünüz Olduğunda Basit Bir Kullanıcı Arayüzü Nasıl Tasarlanır?
  Suzanne Scacca'nın yazdığı

Transcript

Drew McLellan: Yazılım mühendisi, eğitmen, yazar ve eğitim ve müfredat geliştirme şirketi Moon Highway'in kurucu ortağıdır. Kariyeri, teknik şartnameler yazmaya ve web projeleri için UX tasarımları oluşturmaya başladı. 2012'de Moon Highway'e başladığından beri, egghead.io ve LinkedIn Learning için video içeriği yarattı ve O'Reilly's Media için Learning React ve Learning GraphQL kitaplarının ortak yazarlığını yaptı.

Drew: Aynı zamanda sık sık konferans konuşmacısı ve React Rally, GraphQL Summit ve OSCON gibi konferanslarda sunumlar yaptı. GraphQL konusunda uzman olduğunu biliyoruz, ancak bir zamanlar bir kutup ayısına satranç oynamayı öğrettiğini biliyor muydunuz? Ezici dostlarım, lütfen Eve Porcello'ya hoş geldiniz.

Drew: Merhaba Eve, nasılsın?

Eve Porcello: Eziyorum.

Drew: Orada bahsettiğim gibi, JavaScript ve React gibi konularda çok iyi bir eğitimcisiniz, ancak bugün sizinle diğer uzmanlık alanlarınızdan biri olan GraphQL hakkında konuşmak istedim. Birçoğumuz GraphQL'i bir dereceye kadar duymuş olacağız, ancak ne olduğundan veya ne yaptığından ve özellikle web yığınında ne tür bir sorunu çözdüğünden tam olarak emin olamayabiliriz.

Drew: Öyleyse, ön uç geliştiriciysem, GraphQL ekosisteme nerede giriyor ve benim için hangi işlevi yerine getiriyor?

Havva: Evet. GraphQL, ön uç ve arka uç arasına sığar. İkisinin ortasında yaşamak gibi bir şey ve ön uç geliştiricilere ve arka uç geliştiricilere birçok fayda sağlıyor.

Eve: Bir ön uç geliştiriciyseniz, tüm ön uç veri gereksinimlerinizi tanımlayabilirsiniz. Örneğin, büyük bir React bileşenleri listeniz varsa, bir sorgu yazabilirsiniz. Ve bu, o sayfanın verilerini doldurmak için ihtiyaç duyacağınız tüm alanları tanımlayacaktır.

Eve: Şimdi arka uç parçasıyla, gerçekten kendine ait, çünkü birçok farklı kaynaktan çok fazla veri toplayabiliriz. Yani REST API'lerinde, veritabanlarında ve tüm bu farklı yerlerde verilerimiz var. Ve GraphQL, tüm verilerimizin bulunduğu yerdeki kaosu gerçekten anlamamız için bize bu güzel küçük düzenleme katmanını sağlıyor. Bu yüzden yığının her yerindeki herkes için gerçekten faydalı.

Drew: Yani temelde API tabanlı bir teknoloji, değil mi? Ön ucunuzla arka ucunuz arasında oturur ve bir çeşit API sağlar, bu doğru mu?

Havva: Evet, aynen öyle. Kesinlikle.

Drew: Bence son on yılda API'ler için altın standart dinlenme oldu. Dolayısıyla, bir istemci tarafı uygulamanız varsa ve onu arka uçtan gelen verilerle doldurmanız gerekiyorsa, bir REST API uç noktası oluşturur ve bunu sorgularsınız. Peki bu model nereye düşüyor? Ve GraphQL'in gelip bunu bizim için çözmesine ne zaman ihtiyacımız olabilir?

Eve: Pekala, GraphQL'in bize gerçekten yardımcı olduğu problem, bir tür altın problem, sanırım GraphQL'in sağladığı altın çözüm, REST ile çok fazla veri getirmemiz. Bu yüzden, eğik çizgi kullanıcılarım veya eğik çizgim ürünlerim varsa, rotaya her bastığımda bu bana tüm verileri geri verecek.

Eve: GraphQL ile hangi verileri istediğimiz konusunda biraz daha seçici olabiliriz. Dolayısıyla, yüzü olan bir nesneden yalnızca dört alana ihtiyacım olursa, bu alanları gerçekten tam olarak belirleyebileceğim ve cihazınıza veri yüklemem veya söylemem gereken tüm bu verileri cihazınıza yüklemem gerekmeyecek, çünkü bu, özellikle telefonunuz için çok fazla ayak işi.

Drew: Geçmişte, geri istediğiniz verilerin bir listesini iletebileceğiniz veya geri gelenleri ekstra şeylerle artırabileceğiniz isteğe bağlı bir alana sahip REST API'lerini gördüm ve bunlarla çalıştım. Ve sanırım bu sorunu tanımlıyor, değil mi? Bu, her seferinde aynı verileri her zaman geri istemeyeceğiniz anlamına gelir. Öyleyse GraphQL, ön ucun veri açısından arka ucun ne döndüreceğini belirlemesine izin verme yaklaşımını resmileştiriyor mu?

Havva: Evet, aynen. Böylece sorgunuz nasıl sorduğunuz, nasıl filtrelediğiniz, herhangi bir yerden herhangi bir bilgiyi nasıl elde ettiğiniz olur.

Eve: GraphQL ile gerçekten başarılı bir şekilde çalışmak için tüm REST API'lerimizi yıkmak zorunda olmadığımızı da not etmenin önemli olduğunu düşünüyorum. Orada gördüğüm en başarılı GraphQL uygulamalarının çoğu, REST API'lerinin etrafındaki sarmalayıcılar. Ve GraphQL sorgusu size gerçekten ihtiyacınız olan verileri düşünmeniz için bir yol sunar. Ve sonra belki verilerinizin bir kısmı kullanıcılarımızdan ve ürünlerimizden gelir, örnekler, verilerin bir kısmı REST'ten, bir kısmı bir veritabanından gelir.

Drew: Sanırım tanıdık senaryo şu ki, web sitenizde, başlığı görüntülemek için bir kullanıcı hakkında bilgi döndüren bir uç noktanız olabilir. Size kullanıcı adını ve avatarını verebilir. Ve bunu her sayfada çıkarır ve verileri doldurursunuz, ancak daha sonra uygulamanızda başka bir yer bulursanız, tam adını göstermeniz gerekir.

Drew: Yani bunu son noktaya eklersiniz ve o onu döndürmeye başlar. Ardından hesap yönetimi bölümünü yaparsınız ve onların posta adresini beğenmeniz gerekir. Böylece bu, o uç nokta tarafından da döndürülür.

Drew: Ve siz farkına bile varmadan, bu uç nokta, arka uçta bir araya getirilmesi oldukça maliyetli ve açıkçası indirmesi de çok fazla olan ağır bir yük getiriyor.

Drew: Ve bu sadece bir avatar göstermek için her sayfada itlaf edildi. Sanırım bu zamanla büyüyen türden bir problem, özellikle büyük takımlarda içine düşmesi çok kolaydı, o GraphQL, bu problemin üstünde. Bunu nasıl çözeceğini biliyor ve bunu çözmek için tasarlandı.

Havva: Aynen. Ve evet, bence tüm bu GraphQL Şeması fikri, bence gerçekten, GraphQL'nin sorgu dili kısmından daha az konuşuluyor. Ama özellikle Şema'nın bize API için bu güzel tip sistemi verdiğini hissediyorum.

Eve: Yani ekipteki herkes, yöneticiler, ön uç geliştiriciler, arka uç geliştiriciler, gerçekten verilerle ilgilenen herkes bir araya gelebilir, bu API'de hangi verileri sunmak istediğimiz konusunda birleşebilir ve sonra herkes bu kaynağın ne olduğunu bilir. Gerçek şu ki, buna dayalı olarak uygulamanın kendi bölümlerini oluşturmaya gidebilirler.

Eve: Yani bununla birlikte ortaya çıkan bazı zor Şema yönetimi şeyleri var. Ancak mikro hizmetlerden monolitlere geri dönersek, bunu bir nevi yapıyoruz, ancak yine de mikro hizmetlerden sevdiğimiz tüm faydaları elde ediyoruz.

Drew: Ve bir GraphQL sistemi kurmanın tipik yolunun, temelde tek bir rotaya sahip olmanız olduğunu doğru anlamış mıyım? en zor şey, neye ad verileceğini ve bu sorgunun hangi yolda olması gerektiğini bulmaktır. Kullanıcıları ve ürünleri geri getiriyor, kullanıcıları bir şeyi mi yoksa ürünü bir şeyi mi kesiyor?

Drew: GraphQL ile sorgularınızı yönlendirebileceğiniz tek bir uç noktanız olur ve uygun bir yanıt alırsınız.

Havva: Aynen. Evet. Tek bir son noktadır. Sanırım hala adlandırma sorunlarıyla uğraşıyorsunuz çünkü Şema'daki her şeyi adlandırıyorsunuz. Ancak, mikro hizmetler üzerine büyük bahisler yapan birçok şirket gibi hissediyorum, herkes gibi, hangi uç noktalara sahibiz? Neredeler? Nasıl belgelenirler? Ve GraphQL ile, API'nin nasıl çalıştığı hakkında öğrenmek istediğimiz her şeyi aramak için tek bir yerimiz, bir tür sözlüğümüz var.

Drew: Diğer sorgu dillerine çok aşinayım, örneğin SQL, birçok web geliştiricisinin bileceği bir sorgu dilinin bariz bir örneğidir. Ve bunun içindeki sorgular neredeyse bir komuta benziyor. Bu bir metin dizisi, değil mi, Bunu oradan seçin, nerede, her neyse. Sorgular GraphQL ile hangi biçimi alır?

Eve: Bu hala bir teknoloji dizisi ama bu mantığın nereden geldiğini tanımlamıyor. Ve mantığın çoğu sunucuya geri taşınır. Dolayısıyla GraphQL sunucusu, GraphQL API'si, "Git bu verileri olduğu yerden al, bu parametrelere göre filtrele" demekten gerçekten sorumludur.

Eve: Ama sorgu dilinde çok alan odaklı. Bu yüzden almak istediğimiz her şey için alanlar ekliyoruz. Elbette bu sorgulara da filtreler koyabiliriz. Ama bu bilginin nereden geldiği konusunda biraz daha az doğrudan olduğunu düşünüyorum. İşlevselliğin çoğu sunucuda yerleşiktir.

Drew: Böylece bir sorguda karıştırıp eşleştirebilirsiniz. Tek bir istekte çok sayıda farklı veri türünü geri getiren bir istekte bulunabilirsiniz. Bu doğru mu?

Havva: Evet, kesinlikle doğru. Böylece, sunucunuzun izin verdiği kadar çok alan için bir sorgu gönderebilir ve her türlü iç içe geçmiş veriyi geri getirebilirsiniz. Ama gerçekten böyle çalışıyor, farklı türleri tarlalarda birbirine bağlıyoruz. Bu yüzden sanırım kullanıcılarım ve ürünler fikrimi geri dönüştüreceğiz, ancak kullanıcının bir ürün listesi döndüren bir ürünler alanı olabilir. Bunların hepsi diğer türlerle de ilişkilidir. Böylece, sorgunun gitmesini istediğimiz kadar iç içe olabiliriz.

Drew: Yani bu, web uygulamanızda her türlü şeyin olabileceği tipik bir görünüm için verileri almak anlamına mı geliyor, yani arka uca sadece bir istekte bulunabilirsiniz ve hepsini farklı hale getirmeye gerek kalmadan tek seferde alabilirsiniz. farklı uç noktalara sorgular, çünkü hepsi tek bir şey mi?

Havva: Evet. Hedefin tamamı bu, sadece tek bir sorgu, istediğiniz her alanı tanımlayın ve ardından tek bir yanıtta döndürün.

Drew: Ve sorgular JSON tabanlı, doğru mu?

Eve: Sorgunun kendisi bir metin dizesidir, ancak genellikle JSON verilerini döndürür. Dolayısıyla, alanlarım varsa, o zaman JSON yanıtım tam olarak eşleşir ve bu nedenle, bu sorguyu gönderdiğinizde ne elde ettiğiniz gerçekten açıktır, çünkü veri yanıtı tamamen aynı görünür.

Drew: Görünüşe göre sorguların çoğu, bir müşteri veya bir ürün gibi neredeyse çıplak nesneler için. İş mantığının arka uçta kontrol edildiği daha karmaşık sorguları belirtmenin bir yolu var mı? Diyelim ki bir kullanıcı için ekiplerin bir listesini almak istiyorum, ancak yalnızca bu kullanıcının bir ekibin yöneticisi olduğu ve ekip planının süresinin dolmadığı ve günlük web uygulaması geliştirmede karşılaştığımız tüm bu tür gerçek kısıtlamalar. Bu GraphQL ile başarılabilir mi?

Havva: Kesinlikle. GraphQL ile ilgili gerçek heyecan verici, güçlü şey bu, bu mantığın çoğunu sunucuya taşıyabilirsiniz. Karmaşık bir sorgunuz varsa, gerçekten belirli bir kullanıcı tipi elde etmek istiyorsanız, Şema'da yapmanız gereken tek şey "Karmaşık kullanıcı alın" demek ve ardından sunucuda bir fonksiyon olurdu. tüm mantığı istediğiniz dilde yazabilirsiniz. JavaScript, bir tür en popüler GraphQL uygulama dilidir, ancak bunu hiç kullanmak zorunda değilsiniz. Yani Python, Go, C++, ne kullanmak isterseniz onunla bir GraphQL sunucusu oluşturabilirsiniz. Ama evet, istediğiniz kadar karmaşık bir sorgu tanımlayabilirsiniz.

Drew: Ve sanırım bu, birçok iş mantığını yeni nesne türlerine dahil etmenize olanak sağlıyor. Adil mi? Biliyorsunuz, karmaşık bir kullanıcı kurarsınız ve sonra karmaşık bir kullanıcının ne olduğunu düşünmenize gerek kalmaz, ancak o karmaşık kullanıcıyı kullanmaya devam edebilir ve iş mantığının bunun üzerine uygulandığını bilirsiniz. Bu doğru mu?

Havva: Aynen öyle. Bu yüzden bunun ön uç insanlar için gerçekten güzel olduğunu düşünüyorum çünkü buna dayanarak prototip oluşturmaya başlayabilirler. Ardından arka uç ekibi, bu işi yapmak için bu işlevleri uygulayabilir. Ve sonra, o tipin gerçekte ne olduğu ve kim oldukları konusunda bir çeşit ortak anlayış vardır ve "Bu tipteki alanlar nelerdir?" Ve her şey, GraphQL yığınının çalıştığı her yerde yapılabilir. İşte bu yüzden gerçekten bir ön uç veya arka uç teknolojisi değil. Gerçekten ikisi de ve ikisi de değil.

Drew: Görünüşe göre API'yi ve ön uç ile arka uç arasındaki ilişkiyi resmileştiriyor, bu yüzden herkes standartlaştırılmış öngörülebilir bir arayüz alıyor.

Havva: Aynen.

Drew: Tahminimce ön uç ve arka ucun farklı ekiplere ait olduğu organizasyonlarda ki bu hiç de alışılmadık bir durum değil. buna karşılık gelen değişiklikleri yapmak için arka uçta çalışan birine ihtiyaç duymadan. Yeni verilere ihtiyacınız varsa değiştirmek için herhangi bir çalışma yapmanıza gerek kalmadan bu neredeyse sınırsız özelleştirilebilir API'ye hala sahipsiniz.

Havva: Evet, kesinlikle doğru.

Drew: Yani yanıtı biçimlendirmekten GraphQL sunucusu mu sorumlu, yoksa bunu sunucu tarafı mantığınızda mı yapmanız gerekiyor?

Eve: Yani GraphQL sunucusu iki şeyi tanımlar. Sunucuda yaşayan Şemanın kendisini tanımlar ve ardından çözümleyici işlevlerini tanımlar. Bunlar, verileri olduğu yerden almaya giden işlevlerdir. Bu nedenle, GraphQL ile sarmaladığım bir REST API'm varsa, çözümleyici bu API'den alır, verileri olması gerektiği gibi dönüştürür ve ardından bu işlevde istemciye döndürür. O sunucuda da istediğiniz her türlü veritabanı işlevini kullanabilirsiniz. Dolayısıyla, bir sürü farklı yerde verileriniz varsa, bu, tüm bu verileri yerleştirmek ve tüm mantığı bir tür tasarlamak için gerçekten güzel ve uyumlu bir noktadır, “Bu veriler nereden geliyor? Nasıl dönüştürmek istiyoruz?”

Drew: İstemci, "Karmaşık bir kullanıcı istiyorum" diyor, sunucu bunu bir sorguda alıyor ve "Tamam, karmaşık kullanıcı çözümleyicisine bakacağım" diyebilir. Bu doğru mu?

Eve: Mm-hmm (olumlu).

Drew: Hangi fonksiyon ve sonra mantığınızı yazarsınız ki arka uç ekibiniz veya o fonksiyonun içindeki mantığı kim yazarsa, karmaşık bir kullanıcıyı döndürmek için ne gerekiyorsa yapın.

Havva: Evet, aynen.

Drew: Bu, diğer API'leri çağırıyor olabilir, bir veritabanını sorguluyor olabilir, önbellekte bir şeyler arıyor olabilir veya hemen hemen her şey olabilir.

Havva: Hemen hemen her şey. Ve sonra, işlevden gelen bu dönüş, Şemanın gereksinimleriyle eşleştiği, hangi alanların, hangi türlerin oraya döndüğü ile eşleştiği sürece, her şey güzel ve uyumlu bir şekilde çalışacaktır.

Drew: Sanırım size varsayılan olarak tüm API'niz genelinde tutarlı bir yanıt formatı sağlıyor. Bunun neye benzediğini tasarlamak zorunda değilsiniz. Sadece tutarlı bir sonuç elde edersiniz.

Havva: Evet, aynen.

Drew: Bence bu gerçekten büyük bir kazanç olabilir, çünkü çok çeşitli API uç noktalarında, özellikle daha büyük takımlarda tutarlılığı korumak gerçekten zor olabilir. Farklı insanlar farklı şeyler üzerinde çalışıyor. Oldukça katı bir yönetiminiz olmadığı sürece, gerçekten çok hızlı bir şekilde karmaşık hale gelebilir, değil mi?

Havva: Evet, kesinlikle. Ve bence Schema, her şeyi açıklamak için çok hoş bir küçük belge. Schema'ya sorgu göndermeye çalıştığınızda, Schema'daki tüm alanları görebilmenin otomatik avantajını elde edersiniz, çünkü iç gözlem sorguları gönderebilirsiniz ve bunun için GraphQL ve GraphQL Playground gibi her türlü güzel araç vardır. API verileriyle etkileşim kurmak için kullanabileceğiniz küçük araçlar.

Eve: Ama ayrıca, Postacı ile daha önce oynadıysan, bir REST API'sine ping atmayı seviyorsan, bunların çoğu, belgeler gerçekten mevcut değil ya da bulunması zor, ya da bunun gibi şeyler. GraphQL size gerçekten o API'nin parçası olabilecek her şeyi tanımlamanız için o güzel, uyumlu katmanı sunar.

Drew: Pratik olarak, sunucu tarafında işler nasıl gidiyor? Demek istediğim, altyapınızın bir parçası olarak bir GraphQL hizmeti çalıştırmanız gerekiyor, ancak bu nasıl bir şekil alıyor? Kendi portunda çalışan bir sunucunun tamamı mı? Yoksa mevcut Express veya Apache'nize entegre ettiğiniz bir kitaplık mı yoksa bu hizmete çözüm getiren bir rota mı var? Nasıl uygularsınız?

Eve: Evet, gerçek bir sunucu. Bu nedenle en popüler GraphQL uygulamaları Node.js sunucularıdır. Bir özellik olarak GraphQL yayınlandığında, ekip JavaScript'te bu referans uygulamasını yayınladı, ortaya çıkan diğer tüm bu sunucular için kılavuz görevi gören bir tür Düğüm sunucusu. Ama evet, bu sunucuları kendi örneklerinde çalıştırabilirsiniz. Bunları Lambda'ya koyabilirsiniz. Apollo Sunucu Ekspres var, Apollo Sunucu Lambda var; Bu şeyi gerçekten çalıştırmak için kullanabileceğiniz her türlü farklı uygulama türü.

Drew: Yani sunucunun sahip olduğu bir Şema kavramından önce kısaca bahsettiniz.

Havva: Evet.

Drew: Bu size, türlerinizi, bilirsiniz, bir çözümleyiciye bir isim eşlemekten daha katı bir şekilde tanımlama yeteneği verir. Orada daha fazla ilgili var, değil mi?

Havva: Evet. Tam bir dil var. Bu yüzden spesifikasyona atıfta bulundum ve ne olduğunu açıklamadım. GraphQL'nin kendisi, sorgu dilini ve Şema tanımlama dilini tanımlayan bir özelliktir. Yani kendi sözdizimine sahiptir. Bu türleri tanımlamak için kendi kuralları vardır.

Eve: Schema tanımlama dilini kullanırken, temelde o dilin tüm özelliklerini kullanarak API'nin parçası olan türler nelerdir? Aynı zamanda sorguları tanımladığınız yer, fiiller olan mutasyonlar, eylemler gibi, hesap girişi oluşturma, bunun gibi şeyler. Ve hatta bir başka harika şey olan GraphQL abonelikleri bile, Şema'da tam orada tanımlayabileceğiniz gerçek zamanlı GraphQL.

Eve: Yani evet, Şema gerçekten çok önemli. Ve bence bu bize tam Stack uygulamamızda bu güzel tip zorlamayı sağlıyor, çünkü bu alanlardan ve bu türlerden sapmaya başlar başlamaz hataları görmeye başlıyorsunuz, bu durumda, iyi, çünkü siz 'Şema kurallarına uyuyoruz.

Drew: Bununla TypeScript arasında bir geçiş var mı? Orada ikisi arasında bir tür sinerji var mı?

Havva: Kesinlikle. Yani GraphQL hakkında çok konuşan biriyseniz, bazen insanlar size bunun kötü olduğunu söylerler ve bunu yapabildiğiniz zaman herkesin önünde size gelirler ve GraphQL'in nasıl iyi olmadığı hakkında konuşurlar. Ama çoğu zaman tiplerden aldığınız harika şeyleri atlarlar. TypeScript ile sinerji devam ettiği sürece, kesinlikle, Schema'daki türleri kullanarak ön uç uygulamanız için türleri otomatik olarak oluşturabilirsiniz. Bu büyük bir kazanç çünkü onu yalnızca ilk seferde oluşturamazsınız, bu size ön uç uygulamanızla harika bir birlikte çalışabilirlik sağlar, aynı zamanda işler değiştikçe türleri yeniden oluşturabilir ve ardından bu değişiklikleri yansıtacak şekilde oluşturabilirsiniz. Yani evet, türler bir tür fiili kural olmaya başladığından, bu şeylerin birbirine gerçekten çok yakıştığını düşünüyorum.

Eve: … JavaScript'te bir nevi fiili kural olarak, birbirlerine çok yakışıyorlar.

Drew: TypeScript'in tasarlanma şekliyle ilgili bir tür devam eden tema gibi görünüyor… bu TypeScript değil, üzgünüm. GraphQL, ön uç ve arka uç arasındaki etkileşimi resmileştirme konusunda pek çok şey olacak şekilde tasarlanmıştır. Ve şimdiye kadar pek çok insan için dinlenme ile oldukça dağınık bir deneyim olan şeyin tutarlılık yaratması ve resmileştirilmesi arasında bir çözüm olarak geliyor. İstemci tarafı uygulamaları yazarken her zaman aklımızda tutmamız gereken bir şey, kodun incelemeye ve potansiyel olarak değişikliğe tabi olmasıdır. İstemcinin yalnızca veri isteyebileceği bir API'ye sahip olmak tehlikeli olabilir. Şimdi, hangi alanları istediğinizi belirtebilirseniz, belki bu tehlikeli olabilir. Tüm yığının neresinde, kullanıcıların yetkilendirilmesiyle ilgilenir ve verilerinizin etrafındaki iş kurallarının uygulandığından emin olur musunuz?

Eve: Bunların hepsini sunucuda halledeceksin. Yani bu çok farklı şekillerde olabilir. Tek seferlik bir strateji kullanmak zorunda değilsiniz, ancak yetkilendirmenizi çözümleyicileriniz halledecektir. Bu, Auth0 gibi bir hizmet veya kendi oluşturduğunuz bir şey gibi mevcut bir kapalı REST API'sini sarmak anlamına gelebilir. Bu, GitHub veya Facebook veya Google oturum açma gibi bir OAuth ile etkileşimde bulunmak anlamına gelebilir; bu, çözücülerle ileri geri geçiş belirteçleri içeren bu tür şeyler. Ancak çoğu zaman doğrudan Şema içine yerleştirilecektir. Yani Şema, bilmiyorum diyecek, bir oturum açma mutasyonu oluşturacağız. Ve sonra bu mutasyonu kimlik bilgimle gönderiyorum ve ardından sunucuda tüm bu kimlik bilgileri doğrulanıyor. Yani müşterinin çok fazla endişelenmesine gerek yok, belki biraz geçen jetonlar ve bunun gibi şeyler. Ancak bunların çoğu yalnızca sunucuda yerleşiktir.

Drew: Yani esasen, şu anda dinlenme uç noktalarını nasıl oluşturduğumuza kıyasla bu pek değişmiyor. Bir teknoloji olarak, aslında yetkilendirme ile de ilgilenmiyor ve sunucuda bununla ilgilenen ara katman yazılımlarımız ve şeyler var. Ve GraphQL ile aynı. Sen sadece onunla ilgilen. GraphQL topluluğunda bunu yapmak için herhangi bir sözleşme var mı? Ortak yaklaşımlar var mı yoksa insanların nasıl uygulamayı seçtikleri her yerde mi?

Eve: Dürüst olmak gerekirse her yerde. Sanırım çoğu zaman insanların Şemaya dahil olduğunu göreceksiniz ve bununla demek istediğim, bu türleri ve yetkili kullanıcıları temsil eden normal kullanıcılara karşı bu türleri Şemanın kendisinde inşa eden. Ancak, üçüncü taraf çözümleri kullanan birçok insan da göreceksiniz. Auth0'dan bahsettim. Pek çok insan, yetkilerini daha çok buna odaklanan şirketlere, özellikle daha küçük şirketlere, yeni kurulan şirketlere, bunun gibi şeylere devredecek. Ancak bunun için çözümler üretmeye başlayan daha büyük şirketler de göreceksiniz. AWS, Amazon'da GraphQL'nin tadı olan AppSync'e sahiptir ve doğrudan AppSync'te yerleşik yazar ruloları vardır. Ve bu biraz havalı, bilmiyorum, tüm bu şeyler için endişelenmeme veya en azından bununla çalışmak için bir arayüz sağlamama gerek yok. Bu ekosistem araçlarının birçoğunda var, bence yetkilendirme GraphQL'de çok büyük bir konu. Grafikte yetkilendirmeyi işlemek için bir tür ihtiyaç, yetkilendirme çözümleri talebi ve standart yaklaşımlar gördüler.

Drew: Sanırım orada bir çeşit yetki gerektirmeyen bir uygulama neredeyse yok. Yani evet, oldukça yaygın bir gereklilik olacak. Hepimiz, özellikle React ve View öğelerini ve neye sahip olduğunuzu kullandığımızda, giderek daha fazla bileşenli uygulamalar geliştiriyoruz. Ve gevşek bağlantı ilkesi, bizi, etraflarındaki sayfada başka nelerin çalıştığını bilmeyen pek çok bileşenle baş başa bırakıyor. Bunun sonucunda, aynı verileri sorgulayan ve birden çok istekte bulunan çok sayıda bileşenle karşılaşma tehlikesi var mı? Yoksa bunun için çözmeniz gereken uygulamanızdaki mimari bir sorun mu? Bununla başa çıkmak için iyi bilinen çözümler var mı?

Eve: Sanırım, çünkü çoğunlukla GraphQL, çözümlerin %100'ü değil, ama hemen hemen her GraphQL sorgusu HTTP üzerinden gönderiliyor. Bu nedenle, bu çoklu isteklerin nerede gerçekleştiğini izlemek istiyorsanız, uygulamaları için dinlenme verilerini kullanan kişiler için muhtemelen oldukça tanıdık bir sorundur. Bu nedenle, "Neler oluyor? Bu sayfada hangi sorgular var?” Bu size neler olduğuna dair gerçekten net bilgiler verir. Bununla ilgili birkaç düşünce okulu var. Sayfanın tüm verileri için büyük, devasa bir sorgu mu oluşturuyoruz? Yoksa uygulamanın farklı bölümleri için veri yüklemek için daha küçük sorgular mı oluşturuyoruz? Her ikisinin de hayal edebileceğiniz gibi, kendi dezavantajları vardır, çünkü büyük bir sorgunuz varsa, daha fazla alan bekliyorsunuzdur.

Eve: Daha küçük sorgularınız varsa, ihtiyaç duyduğunuz veriler arasında çakışmalar olabilir. Ama bence çok fazla teğet geçmemek lazım ama ben zaten oradayım. Yani GraphQL spesifikasyonuna Ertelenmiş Yönerge adı verilen bir şey geliyor ve Ertelenmiş Yönerge, içeriğin ikincil olarak yüklenmesine yardımcı olacak. Diyelim ki sayfanın üst kısmında bir miktar içeriğiniz var, ilk olarak yüklemek istediğiniz çok önemli içerik. Bunu sorgunuza eklerseniz ve sonraki tüm alanlar bununla ilgili ertelenmiş yönergeyi alır. Bu, bir alana ekleyeceğiniz küçük bir dekoratördür, ardından "Tamam, önce önemli verileri yükleyin, ardından bekleyin ve ikinci verileri yükleyin" diyecektir. Ve size bir nevi bunu veriyor, ön ucunuza bir tür veri akışı görünümü veriyor, böylece algılanan performans var, etkileşim var. İnsanlar, sayfa için her bir alanın yüklenmesini beklemek yerine verileri hemen görüyorlar, ki bu bir sorun olabilir.

Duru: Evet. Sanırım bu, her şeyin … görünüm alanı hakkında çok fazla konuşmayı sevmediğimiz, ancak ekranın üst kısmındaki her şey olduğu, önceliklendirebilir, bu yükü içeri alabilir ve ardından ikincil olarak her şeyi daha da yükleyebilirsiniz. aşağı. Bu yüzden, veri sorgulama hakkında çok konuştuk. Bir API'nin ana işlerinden biri, kalıcılık için yeni ve değiştirilmiş verileri sunucuya geri göndermektir. Daha önce kısaca mutasyonlardan bahsettiniz. GraphQL'nin sunucuya veri yazmak için kullandığı terminoloji bu mu?

Havva: Aynen. Yani verilerde yapmak istediğimiz her türlü değişiklik, sunucuya geri yazmak istediğimiz herhangi bir şey, bunlar mutasyonlardır ve bunların hepsi tıpkı sorgular gibidir, sunucuda yaşayan adlandırılmış işlemlerdir. Kullanıcılarımızın yapabilmelerini istediğimiz şeylerin neler olduğunu düşünebilirsiniz. Mutasyonları olanları temsil edin. Ve sonra tekrar sunucuya, bu şeyleri çalıştıran tüm fonksiyonları yazın.

Drew: Peki bu, verileri sorgulamak kadar basit mi? Mutasyon aramak bu kadar kolay mı?

Havva: Evet. Sorgu dilinin bir parçasıdır. Hemen hemen aynı görünüyor. Tek fark, sanırım sorgular filtreleri alıyor. Böylece mutasyonlar, sorgunun kendisinde filtre gibi görünen şeyleri aldı. Ancak bunlar aslında verileri değiştirmekten sorumludur. Bir mutasyonla bir e-posta ve parola gönderilebilir ve ardından sunucu bunu toplar ve ardından kullanıcıyı yetkilendirmek için kullanır.

Drew: Yani, daha önce olduğu gibi, bununla başa çıkmak ve yapılması gereken her şeyi yapmak için arka uçta bir çözümleyici yaratıyorsunuz. Veri yazarken sık görülen bir durum, değişikliklerinizi taahhüt etmek ve ardından mevcut durumunu elde etmek için yeniden sorgulamak istemenizdir. GraphQL bunun için iyi bir iş akışına sahip mi?

Eve: Bir nevi mutasyonun kendisinde yaşıyor. Bu nedenle, çoğu zaman Şemanızı oluştururken mutasyon işlemini yaratacaksınız. Giriş yapmaya devam edeceğim, e-postayı ve şifreyi alacağım. Ve mutasyonun kendisi bir şey döndürdü. Yani Boole gibi basit bir şey döndürebilir, bu iyi gitti veya bu kötü gitti veya gerçek bir tür döndürebilir. Bu yüzden çoğu zaman mutasyonu oturum açma mutasyonu gibi görürsünüz, belki bir kullanıcı döndürür. Böylece, oturum açtıklarında kullanıcıyla ilgili tüm bilgileri alırsınız. Veya size o kullanıcıyı artı kullanıcının ne zaman oturum açtığını ve belki de dönüş nesnesindeki bu işlemle ilgili biraz daha fazla meta veriyi veren özel bir nesne türü oluşturabilirsiniz. . Yani yine, bunu tasarlamak biraz size kalmış, ancak bu model gerçekten GraphQL'de pişirilir.

Drew: Bunların hepsi kulağa harika geliyor, ancak her teknik seçim, ödünleşimler içeriyor. GraphQL kullanmanın dezavantajları nelerdir? Gerçekten kötü bir seçim olacağı herhangi bir senaryo var mı?

Eve: Bence bir GraphQL'nin zorlanabileceği yer, bire bir harita oluşturmak-

Eve: … mücadele, tablo halindeki verilerin bire bir haritasını oluşturmaktır. Diyelim ki, bilmiyorum, her türden farklı alana sahip bir veritabanı tablosu düşünün ve bilmiyorum, belirli bir türde binlerce alan, bunun gibi şeyler, bu tür veriler güzel bir şekilde temsil edilebilir. GraphQL ile, ancak bazen bu veriler üzerinde bir Şema oluşturmak için bir süreç çalıştırdığınızda, bir Şemada, veritabanında yaşadığınız problemlerin aynısı ile kalırsınız, ki bu belki de istemcinin ötesine geçen çok fazla veridir. aslında gerektirir. Bence bu yerler potansiyel olarak problemler. Verilerine dayanarak otomatik olarak Şemalar oluşturan insanlarla konuştum ve bu bir milyon satır uzunluğunda Şema veya bunun gibi bir şey oldu, sadece binlerce ve binlerce satır Şema kodu oldu. İşte bu noktada işler biraz zorlaşıyor, örneğin bu insan tarafından okunabilen bir belge olarak ne kadar faydalı?

Havva: Evet. Bu nedenle, bir müşteriyle uğraştığınız her türlü durum, her farklı veri türünü modellemek için gerçekten güzel bir uyumdur, veri kaynaklarınız çok büyükse biraz zorlaşır.

Drew: Yani, sahadaki tepkileri dikkatlice seçeceğiniz ve daha fazlasını elle yapacağınız herhangi bir yerde gerçekten güçlü sonuçlar elde edebilirsiniz. Ancak, büyük bir Şemanız olduğu için otomatik olarak bir şeyler üretiyorsanız, o zaman belki biraz hantal hale gelir.

Havva: Evet. Ve bence insanlar beni dinliyor ve bu konuda benimle aynı fikirde değiller çünkü bunun için de iyi araçlar var. Ama bence GraphQL'in gerçekten parladığı yer, mantığı sunucuya soyutlama, ön uç geliştiricilere bileşenlerini veya ön uç veri gereksinimlerini tanımlama özgürlüğü verme ve Şemayı bir ekip olarak gerçekten yönetme adımıdır.

Drew: Sonuçların sayfalandırılmasıyla başa çıkmak için sorgu dilinde yerleşik bir şey var mı, yoksa bu, gerektiği gibi özel bir uygulamaya mı bağlı?

Havva: Evet. Sayfalandırma, önce Şema'yı oluşturursunuz, böylece bunun için sayfalandırmayı tanımlayabilirsiniz. Toplulukta bir şekilde ortaya çıkan birçok yönerge var. GraphQL'de daha yeni olup olmadığınıza bakmak için iyi bir örnek, buna her zaman bakıyorum, GitHub GraphQL API'sidir. Temelde GraphQL kullanarak halka açık API'lerinin v4'ü için API'lerini yeniden oluşturdular. Bu, gerçek bir büyük şirketin bunu ölçekte nasıl kullandığına bakmak için iyi bir nokta. Pek çok kişinin çalışan büyük API'leri vardır, ancak bunu herkese açık hale getirmezler. Bu nedenle, sayfalandırma bu API'ye gerçekten güzel bir şekilde yerleştirilmiştir ve şimdiye kadar oluşturduğunuz ilk 50 depoyu, bilmiyorum, döndürebilirsiniz veya verilerinizdeki fikirlere dayalı kayıtları döndürmek için imleç tabanlı sayfalandırmayı da kullanabilirsiniz. İmleç tabanlı sayfalama ve ilk, son kayıtlar gibi konumsal sayfalandırma, genellikle insanlar buna böyle yaklaşıyor, ancak birçok teknik var.

Drew: GraphQL'i kullanırken bilmemiz gereken önemli noktalar var mı? Diyelim ki kuruluşum için yeni bir GraphQL kurulumu dağıtmak üzereyim, bundan sonra tüm yeni API uç noktalarımızı GraphQL kullanarak oluşturacağız. Ne bilmeliyim? Çalılarda gizlenen bir şey var mı?

Eve: Her zaman teknolojiyle çalıların arasında gizlenmek, değil mi? Bence GraphQL'de yerleşik olmayan, ancak çok fazla güçlük çekmeden uygulanabilen şeylerden biri API güvenliğidir. Örneğin, büyük bir sorgum olup olmadığını söylediniz, bunu yetki ile konuştuk, ancak birinin iç içe büyük bir sorgu gönderebileceği bir API açmak da korkutucu, arkadaşların arkadaşları, arkadaşların arkadaşları, arkadaşların arkadaşları , aşağı ve aşağı zincir. Ve sonra temelde insanların bu devasa sorgularla sizi DDoS yapmasına izin veriyorsunuz. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. Kesinlikle.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. Ayrılık sözleriniz var mı?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. I appreciate it.