Bulut bilişimin altın çağında yaşıyoruz. Tüketiciler için bu bir mucize. Geliştiriciler için bu tam ve mutlak bir karmaşa.
Monolitik uygulama mimarileriyle ilgili tüm problemler için (ve birçoğu vardır), bunlar nispeten basittir: Bir uygulama sunucusu ve veritabanı alın ve bunları bir tarayıcı arayüzüne bağlayın. Basit! Buna karşılık, günümüz uygulamaları, sürekli değişen bir dizi arka uç mikro hizmete, birinci taraf ve üçüncü taraf API’lere, veritabanlarına vb. bağlıdır ve bu veriler için çeşitli ön uç giriş bölgeleri (tarayıcı, set üstü) box, mobil uygulama vb.) React ve diğer ön uç çerçeveleri ön uç geliştirmeyi kolaylaştırsa da, bazen şaşırtıcı arka uç karmaşıklığını bu ön uç deneyimine bağlamak zorlaştı.
GraphQL için bir teşekkür duası edin.
Facebook tarafından 2015 yılında piyasaya sürülen GraphQL, API’ler için esnek bir sorgulama dili olarak hizmet veriyor. İlişkisel bir veritabanını sorgulamak için kullanacağınız SQL’den farklı olarak GraphQL, bir geliştiricinin çok çeşitli veri kaynaklarını sorgulamasına olanak tanır. ayrıştırma istemcisi (ön uç geliştirme) sunucudan (arka uç geliştirme). Ancak GraphQL ne kadar havalı olursa olsun, bir süpergraf olmadan eksiktir. Olarak Apollo GraphQL CTO ve kurucu ortak Matt DeBergalis yazıyor, supergraph “birleşik bir ağdır bir şirketin tüm organizasyon için ‘bileşim katmanı’ olarak hizmet eden verileri, mikro hizmetleri ve dijital yetenekleri.
CEO ve kurucu ortak Geoff Schmidt bir röportajda bunu şöyle ifade etti: “Süpergraf yaşayan, nefes alan bir şeydir” ve bu da işletmelerin altyapılarını sürekli değişen gereksinimlere aşamalı olarak uyarlamalarını sağlar. Oh, ve bu yeni altyapıyı eski altyapıya bağlamak, çünkü “yeşil alan diye bir şey yok”.
Süper grafikler ve sıfırdan alan mitleri
Bir dakika ne? Elbette bir startup veya bireysel geliştirici, teknik borçla, yerleşik bir şirketin yaptığı gibi uğraşmak zorunda değildir ve sıfırdan kalkınmaya odaklanabilir mi? “Teknik borç” biraz yüklü bir terim olabilir, ancak bunu RedMonk analisti James Governor’ın yaptığı gibi ifade edelim. son bir röportajda:
İster bireysel geliştirici olun [and] becerileri öğrendiniz… ve şimdi yeni bir çerçeve öğrenmek için bu beceriyi geliştirmeye çalışıyorsunuz veya küçük bir işletme olsanız da belirli bir veri altyapısı oluşturmuş ve bazı analizlerin nasıl oluşturulacağını anlamaya çalışıyorsunuz. ya da insanları işe almakta zorluk çeken ve gerçekten sahip olduğunuz becerilerin üzerine inşa etmek isteyen büyük bir kuruluş olsanız da, … değişmez olan şu ki, yeni teknoloji ortaya çıkarken, mevcut becerilerle birlikte var olması ve bunların üzerine inşa edilmesi gerektiğidir. mevcut teknoloji yığınları.
Schmidt bunu zor yoldan öğrendi.
Schmidt ve DeBergalis ortak kurdu Meteor Schmidt, “yeni uygulamalar oluşturmak için gerçekten büyülü bir platform” olan uçtan uca bir JavaScript çerçevesi sağlamak için 2010’ların başında. Geliştiriciler aynı fikirde görünüyordu. Zamanında, MeteorJS GitHub’daki en popüler projelerden biriydi ve sağlıklı bir topluluğu 100’den fazla düzenli buluşmaya çekti. Schmidt’in anlattığı gibi sorun, Meteor’un kötü bir varsayımdan yola çıkmış olmasıydı. “Meteor’u işletmeye getirmeye çalıştığımızda, Meteor yeşil alan gelişimi için tasarlandı [but] girişimde hiçbir şeyin yeşil alan olmadığını gördük.”
Devam ediyor: “Yapmak isteyeceğiniz herhangi bir uygulamanın birçok farklı hizmetten ve birçok yerden gelen veri kaynaklarından yararlandığı bir dünyada yaşıyoruz. Uygulamayı değerli kılan da bu. Buluttaki her şeyi, sahip olabileceğiniz bir deneyimde sentezler.” Yine, bireysel bir geliştirici, küçük bir başlangıç veya bir Fortune 500 devi olun, güvenlik duvarınızın dışında çok çeşitli hizmetlere bağımlısınız ve tüm bu hizmetler geliştirmeyi karmaşık hale getiriyor.
Aslında, bu pek doğru değil. Schmidt’in işaret ettiği gibi, onun ve DeBergalis’in sahip olduğu temel görüş, kuruluşun giderek daha güçlü ön uç çerçevelerini (MeteorJS veya React gibi) giderek daha güçlü ancak karmaşık arka uç hizmetlerine bağlamak için daha iyi bir yola ihtiyaç duyduğuydu. “Meteor’u işletmeye sokmanın ne kadar zor olduğunu görünce, Meteor 2 veri sistemini kurmaya başladık,” diye hatırlıyor, “Apollo olarak adlandırıldı ve ondan öğrenilen tüm derslere dayanıyordu. [helping] işletmeler … Meteor teknolojisinin karmaşık heterojen kurumsal ortamlarda çalışmasını sağlar.” Apollo süpergrafları için bir sorgu diline ihtiyaçları vardı ve GraphQL’yi seçtiler.
Bütün bunlar harika. Ama neden yapmalı sen bakım?
Süperşarj GraphQL
İster bireysel geliştirici olarak ister büyük bir kuruluş için uygulamalar oluşturuyorsanız, geliştirme hiç de kolaylaşmıyor. İleriye giden yol, mikro hizmetler aracılığıyla artan karmaşıklığa doğru oldukça açık bir şekilde ilerliyor. Geliştiriciler bu karmaşıklığı benimsiyorlar çünkü bu yaklaşımdan artırılmış çeviklik gibi kazanılacak çok şey var. O geleceği istiyorlar.
Ancak bu geleceğe ulaşmak zor olabilir.
GraphQL bile tüm potansiyeline rağmen birçok geliştirici tarafından bireysel hizmetleri bir araya getirmek için kullanılmıştır. Apollon’un inmeye çalıştığı şey, adeta bir grafik grafiğidir. Gittikçe daha fazla atomize olan bir altyapıyı bir araya getirmek için grafikleri kullanmak iyidir, ancak bir meta-grafik veya bir süpergraf eklemek, geliştiricilerin yaşamlarını önemli ölçüde iyileştirme potansiyeline sahiptir. Neden? Niye? Schmidt, “belirli bir Oracle veritabanına veya belirli bir mikro hizmete bu derin, doğrudan, kırılgan bağlantıları oluşturmak veya birinin bakımını yapması gereken tamamen yeni bir REST uç noktası oluşturmak” zorunda kalmadan farklı veri kaynaklarından yararlanmanın en kolay yolu olduğunu söylüyor. .
Daha da önemlisi, süpergraf yaklaşımı doğada parça parça olabilir. Örneğin Walmart, anlamak zorundaydım mağazalarını çalıştıran ana bilgisayarları, çevrimiçi yerine getirmelerini çalıştıran mikro hizmetlerle nasıl bütünleştireceklerini. Müşteriler bu altyapı sorununu bilmiyorlardı ve Walmart’ın çevrimiçi alışveriş için bir web sitesi ve mağazadan teslim almak için bir web sitesi olduğunu fark etmemiş bile olabilirler. Ancak, çevrimiçi olarak sunulan incelemelerin mağazadan teslim için görünmediğini kesinlikle fark ettiler. Ve her sistemde barındırılan farklı ürün katalogları yüzünden hüsrana uğrarlardı. Walmart, ana bilgisayarlarını kapatmayı göze alamazdı, bu yüzden iki sistemi esasen birleştirmek için Apollo süpergrafını kullandı.
Schmidt, süpergraf yaklaşımının “dünyayı durduran bir şelale değişikliği gerektirmediğini” söylüyor. Kuruluşların eski sistemlerini yeni sistemleriyle sorunsuz bir şekilde bağlamasına yardımcı olur. Walmart söz konusu olduğunda, bu, bir ön uç geliştiricinin “Bana bir ürün hakkındaki incelemeleri göster” diyebileceği ve bu incelemeleri nerede olurlarsa olsunlar, ana bilgisayarları da dahil olmak üzere bulabilecekleri anlamına geliyordu. Daha sonra bu ana bilgisayarı mikro hizmet tabanlı bir mimariye yeniden düzenlerlerse, ön uçta hiçbir şeyin değişmesi gerekmez.
Bulutu birlikte seçme
Tüm bunlardan ortaya çıkan ilginç bir şey var: Bulutlar her şeyi daha iyi hale getirmiyor. Örneğin AWS, bir uygulama geliştiricisinin DynamoDB’den veri çekmesi ve bunları mobil uygulamasında göstermesi için harika bir yol olan AppSync’i sunar. Peki ya DynamoDB’den veri çekmek, bazı Azure sunucusuz işlevlerinden yararlanmak, anabilgisayarınızdaki bazı verileri çağırmak ve bir veya iki Google Cloud hizmetinden verilere erişmek istiyorsanız? GraphQL ve Apollo benzeri bir süpergrafın tüm vaadi, heterojen ortamları evcilleştirmektir ve bu yeni heterojenlik, farklı bulutları içerir. Herhangi bir bulutun gereken merkezi yönlendirmeyi sağlaması zor olacak.
Geliştiricilerin kurumsal BT’nin oluşturduğu karmaşayı ehlileştirmelerine yardımcı olmak için bildirimsel, soyut bir katmana veya bir süpergrafa ihtiyacımız vardı. Bir süreliğine, bulutun sorunu çözeceğini düşünerek kendimizi kandırdık. Olmadı. Kurumsal BT’yi genişletti ve daha da karmaşık hale getirdi. Bir süpergrafın yardımcı olabileceği düşünceler ve dualar. Sadece olabilir.
Telif Hakkı © 2022 IDG Communications, Inc.
Kaynak : https://www.infoworld.com/article/3662752/cloud-complicates-development-but-graphql-and-supergraphs-offer-hope.html#tk.rss_all