GraphQL and Relay 1 – Relay framework

GraphQL ile ilgili ilk yazımızda bu mimarıye genel olarak bakmaya çalışmış ve bu mimariyi uygulamalarımız da gerçekleyebilmek adına kullanabileceğimiz bazı kütüphanelerden/frameworklerden de genel olarak bahsetmiştik.

Bu yazımızda, Facebook tarafından geliştirilen ve React ile kullanılan Relay e bakarak devam etmeye çalışacağız. Öncelikle anlam kargaşası olmaması için, eğer GraphQL ve Relay ı ilk defa duyuyorsanız bu serinin ilk yazısını okumanızı tavsiye ederim.

Öncelike, Relay facebook tarafından React ile kullanım için geliştirilmiş bir GraphQL istemci framework u . Yani, eğer react kullanmayı düşünmüyorsanız, bu yazıyı geçip bir sonraki yazıda ele alacağımız apollo stack yazısına bakmanız gerekecek. Relay in aksine Apollo stack ın React yada başka bir framework e bağımlılığı bulunmamakta. Dilerseniz React veya Angular 2 ile yada hiç bir framework kullanmadan tek başına Apollo yu GraphQL mimarisini gerçeklemek adına kullanabilirsiniz.

Bu yazı, React developer lar için yazılsada, “react” kullanmasanızda genel olarak GraphQL mimarisini anlamak adına okunabilir.

Bu yazida Relay ve React i beraber kullanarak bir GraphQL server uygulamasina bağlanacağız.  Relay ı daha iyi anlamak adına, hazır bır GraphQL sunucusu kullanalım. Bir sonraki yazıda kendi GraphQL sunucumuzu Apollo ile yazacağımız için sunucu ile ilgili detayları o yazıya bırakacağım. Böylece bu yazıda Relay ve React a odaklanabiliriz.

Bir başka hatırlatmada, Relay ile her hangi bir dilde yazılmış GraphQL sunucusuna bağlanıp uygulamamızı rahatlıkla geliştirebiliriz. .NET, Java, Ruby yada node.js ile oluşturulmuş GraphQL sunucumuz tüm GraphQL istemcileriyle sorunsuz çalışacaktır.

Setting up a GraphQL server : Since GraphQL is a specification for a server runtime, we can use any language to create a GraphQL schema and build an interface around it.

Relay facebook tarafindan geliştirildiği için tıpkı React gibi “opinionated / dik kafalı bir framework.  Opinionated olarak sınıflandırılan framework lerin en belirgin özelliği, bir çok şeye sizin yerinize kendilerinin karar vermesi ve size belirli bir standart içinde uygulama geliştirmeyi dayatması diyebiliriz.

Bu yüzden “dik kafalı” tabirini kullandım. Facebook , hem React için hem de Relay için “kendi iç sisteminde kullandığı standartları framework e aktarmış ” diyebiliriz. Bu yüzden, “her yiğidiğin yoğurt yiyişi ayrıdır” hesabı, hem React için hemde Relay için “opinionated ” kavramını aklınızda tutun. ve çözmeye çalıştığınız sorunu franeworkün kendi tavsiye ettiği yöntemle çözmeye çalışın(Maximum verim için).

Bir diğer önemli konuda, hem GraphQL hem Relay özellikle “data-driven applications / veriyle şekillenen” uygulamalar için çok ideal, uygulamanızda ana hattı veri oluşturmuyorsa, GraphQL ve Relay yerine muhtemelen daha basit sade çözümlerle çalışmak daha kolay olacaktır.(React/ Redux gibi.)

Başka bir kıyaslamayıda şu şekilde yapabiliriz (son 4-5 seneden bu güne ) RESTful APIs ve adhoc HTTP APIs ile geliştirilen ve kullanılan web uygulamalarımızın 3 aşağı 5 yukarı hemen hemen hepsini GraphQL mimariye taşıyabiliriz. Hem RESTful API lar olsun hem adhoc tarzı API lar genelde birden farklı client yapısına veri sağlayan ve verinin ana oyuncu olduğu sistemler, bu yüzden GraphQL ve Relay e dönüşüm için en olası adaylar diyebiliriz.

declarative data communication – neye nasıl ve hangi formatta ihtiyacı olduğunu kendi belirleyen istemciler için restful mimariden çok ama çok daha ideal bir mimari GraphQL.

Relay ve Çözmeye Çalışacağımız Sorunlar

Aslına bakarsanız, ister React kullanın ister Angular veya her hangi başkaca bir Frontend Framework , belli bir zaman sonra karşınıza çıkacak ilk sorun, “Apllication State Management / Uygulamanın Kendi durumu ve değişen veriye göre vereceği tepkilerin yönetiminin”  git gide zorlaşması diyebiliriz. İster Angular olsun, ister React, component mimari içinde “component level” kontrol ile sorunlarımızın bazıları çözülsede;

  1. componentler arası iletişim,
  2. Uygulama seviyesindeki “state/durumu”
  3. Hem uygulamamızın çalışma zamanında ürettiği veri hemde dış dünyadan aldığımız veririnin uygulamamız içinde doğru dolaşımı

gibi sorunlara uygulamanız büyüdükçe ve kompleksitesi arttıkça farklı çözümler aramaya başlayacağız. Örneğin;

  • componentler arası iletişim için : Observable Pattern
  • Uygulama seviyesindeki “state/durum” için : Redux yada ngrx
  • Veri dağıtımı ve yönetimi için Observable + Redux

gibi. Relay ilk olarak yukarıdaki sorunları çözmek için bir alternatif, diğer taraftan ileride değineceğimiz bazı başka problemleride çözmeye aday.

Ayrıca, Relay bir  GraphQL istemcisi olduğu için, veriye erişimde de yeni bir model/alternatif demiştik. Şimdi veri tarafından bazı sorunlarımıza bakalım;

  • İhtiyacımız olan veriye ulaşmak (Restfull, adhoc APIs , websockets veya GraphQL ile)
    • Performans ve optimizasyon sorunlarımız var mı? Gereksiz veri transferi söz konusumu?
    • İletişim hatalarında(örneğin bir Ajax request/isteğinin başarısız olması) durumunda senaryomuz nedir?
  • Kullanıcı etkileşimi ile değişen yada yeni eklenen verinin ve veriye bağlı olarak UI ın yönetimi
    • veri değişimlerinin uygulama seviyesinde ihtiyacımız olan her alanda düzgün bir şekilde yansıtılması.
    • Pagination ve ya caching gibi ihtiyaçlar
  • Verinin, farklı istemci türlerinde aynı şekilde etkili bir şekilde transferi , yönetimi ve greçek zamanlılık
    • günümüz şartları gereği, mobil uygulamalar, web uygulamalarımız ve hatta IOT device lar gibi yeni nesil istemciler veriyi senkronize olarak taşıyıp yönetebilmektemi?

İşte Relay ın bir başka kullanım alanı ve amacı da genel olarak, Data /Veri iletişimi ve yönetimi diyebiliriz.

Relay ın 3 önemli parçası.

  1. STORAGE AND CACHING / İstemci Taraflı veri deposu, state/durum ve önbellek mekanizması
  2. OBJECT IDENTIFICATION / Relay akıllı nesne yönetim ve diffing algoritmasının uygulandığı kısım
  3. CONNECTION MODEL / Ön tanımlı bağlantı modelleri(sayfalama ve sıralama da dahil)

Bu 3 önemli kavramı sırayla iyi anlamak önemli, aslında sadece GraphQL mimari ve relay kullanımı adına değil, genel olarak modern web uygulamalarınızda da yeni dönemde sıkça karşılaşacağımız kavarmlar olarak da düşünebiliriz.

STORAGE AND CACHING

Relay, istemci tarafında , akıllı”client-side data store” şeklinde ve “Relay Store” diye adlandırılan akıllı bir in-memory hafıza sistemi barındırmakta. Bu yapıyı eğer, Meteor.js ile çalışma fırsatınız olduysa, meteorun kullandığı, istemci tarafında “smart storage/caching” mekanizması “minimongo” ile kıyaslayabilirsiniz.

Relay Store Minimongodan çok daha akıllı ve yetenekli bir model” . Tarayıcılar tarafından bakacak olursak, Relay tarayıcımıza yüklendiğinde, uygulamanın ihtiyacı olan tüm veriyi buraya yükleyecek ve her bir kayıt için “state/durum” yönetimini yapacaktır. (Tahmin edeceğiniz gibi, verinin değişmesi ile React componentimiz otomatik oalrak haberdar edilecek ve React UI ı güncelleyecektir.)

Ayrıca, kullanıcın anında tepki alabilmesi için, Relay Storun önünde, Queue Store olarak adlandırılan bir listemiz olacak. (Verinin gerçek anlamda güncellenmesi için sunucu iletişimi gerektiği durumları düşünün, yeni bir kayıt eklediğimizde bu kayıt tarayıcından sunucuya ordan a veri tabanımıza kayıt olduğu ve işlemin başarılı olduğuna dair cevabın istemciye döndürüldüğü süreç gibi)

Uygulamızın tüm state/durum kontrolünü Relay Store ile yönetmiş olacağız.

 

OBJECT IDENTIFICATION

Relay ın en güçlü yönlerinden bir olan bu yapı sayesinde, relay uygulamamızdaki her bir veriyi tekil olarak takip edebilecek. Bu takip sadece verinin değişimi ile sınırlı da değil, verinin sunucudan tekrar çekilip çekilmeyeceği, çekilecekse kullandığı “diffing / karşılaştırma” algoritması ile olabildiğince verimli data fetching/veri çekme işlemi yapmasınıda kapsamakda.

Örneğin, eğer bir yerde kullanıcı adı ve soyadı zaten çekilmişse, bir başka yerde bu veriyi tekrar çekmek yerine hali hazırdaki veriyi kullanabilecek kadar  akıllı bir algoritmaya sahip.

Mesela, kişi login olduğu zaman sunucudan, ad soyad bilgilerini istemciye aktardığımızı düşünün, kullanıcı sistemde fatura bilgilerine bakmaya çalışsın, fatura ekranı için Relay “Object Identification” ile , ad soyad bilgisine sahip olacağı için sunucuya göndereceğimiz sorgudan bu iki alanı çıkaracaktır. Böylece veri trafiği hep minimize edilip kontrol altında tutulmuş olmakta.

CONNECTION MODEL

Ön tanımlı bağlantı modelleri de Relayın bize sağladığı kolaylıklardan biri. Özellikle, sayafalama sıralama gibi işlemlerde çok kullanışlı olan bir model sunmakta relay.

Örneğin; bir ürün kataloğunda  “kırmızı ve manisa yapımı halılardan fiyatı 100 ile 250 TL arasındaki ilk 20” kaydı aradığımızı düşünün.

İstemciden sunucuya relay ile bu isteği  gönderdiğimizi var sayalım, dönen sonuç relay tarafından edges ve nodes diye adlandırılan bir veri yapısı ile tutulacak, Relay bize arama, sıralama ve sonraki 20 ürünü çağırmak için çok kolay bir bir alt yapı sunacak.

Sonraki yazı ile ilk örneğimizi yazıp, Relay in pratikdeki kullanıma bakarak devam edelim.

Kaynaklar

https://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html

https://www.reindex.io/blog/redux-and-relay/

 

Leave a Reply

Your email address will not be published. Required fields are marked *