2017-05-15 51 views
9

Şirketimde yeni bir proje için bir mikro hizmet mimarisine karar verdik. GraphQL'e bir göz attık ve tek API son noktamız olarak kullanmanın potansiyelini ve avantajlarını fark ettik.GraphQL ve Microservices

Ne katılıyorum, iletişimin GraphQL ve her bir mikro hizmet arasında nasıl yapılması gerektiği. Bazıları REST için tartışıyor, diğerleri de her hizmet için bir grafiksel son noktaya sahip olmamız gerektiğini söylüyor.

Her birinin artıları ve eksileri neler olduğunu merak ediyordum. Örneğin, her hizmette şema bölümlerini çoğaltacağımızdan, graphQL'deki her şeye sahip olmak biraz gereksiz görünüyor. Diğer yandan, bazı REST tuzaklarını önlemek için GraphQL kullanıyoruz. REST uç noktalarının gQL'den elde edilen avantajları geçersiz kılmasından korkuyoruz.

Benzer bir ikilemle karşılaşan var mı? Hiçbirimiz GraphQL ile deneyimlenmiyor, bu yüzden eksik olan bir pro pro ve con var mı?

Şimdiden teşekkürler!

cevap

13

Harika soru! Mimarinizi GraphQL ve microservices için nasıl ayarlayacağınızı soruyorsunuz ve neden.

Arkaplan

Bence en iyisi kullanım durumu temiz bir şekilde veri kaynaklarını birleştirmek ve tek standart API yoluyla size tüm bu verilerin açığa çıkarmaktır beri GraphQL kullanarak öneriyoruz. Kapak tarafında, mikro servislerin kullanılmasıyla ilgili temel sorunlardan biri, sahip olabileceğiniz tüm farklı işlevleri karıştırmanın zor olmasıdır. Ve uygulamanız büyüdükçe, tüm bu mikro-servis işlevlerinin birleştirilmesinde büyük bir sorun haline gelir.

Bu teknolojileri kullanmanın yararları muazzamdır, çünkü temelde tek bir monolitik uygulama gibi sanki mikroişlemcilerinize erişebilmenizi sağlayan bir GraphQL API ağ geçidine sahip olmanız gerekir, ancak aynı zamanda mikro servisler kullanmanın birçok faydasını da elde edersiniz. performans ve verimlilik açısından.

Mimarlık

yüzden öneriyoruz mimari senin microservices önünde oturan bir GraphQL vekil sahip olmaktır, ve GraphQL sorgu ve mutasyon Çözümleyiciler içinde, gerekli verileri almak için gereken işleve sesleniyorum .

Aslında, REST uç noktalarının önünde GraphQL ağ geçitlerinin veya GraphQL ağ geçidinin önünde GraphQL ağ geçidine sahip olmanın gerçekten önemi yok, ancak aslında mikro işlevlerinizi REST olarak göstermek daha kolay olurdu. Son nokta, her fonksiyonun teorik olarak sadece bir amaca hizmet etmelidir. Bu durumda fazladan ilişkisel mantığın olmaması gerektiğinden, bu durumda GraphQL'in ekstra yüküne ve karmaşıklığına ihtiyacınız olmayacaktır.

Eğer microservice sağlayıcılar arıyorsanız gördüğüm en iyi olanlar AWS Lambda, Webtask, Azure Functions ve Google Cloud Functions bulunmaktadır. Ve bu microservice işlevlerini yönetmek ve dağıtmak için Serverless'u kullanabilirsiniz.

Örneğin

:

import request from 'request'; 

// GraphQL resolver to get authors 
const resolverMap = { 
    Query: { 
    author(obj, args, context, info) { 
     // GET request to fetch authors from my microservice 
     return request.get('https://example.com/my-authors-microservice'); 
    }, 
    }, 
}; 

GraphQL Hizmet

Bu size yönetmenize yardımcı olmak için bir hizmet güvenmek istiyorum biz durumda hem Scaphold de keşfetmek oldum şeydir bu iş akışı. Öncelikle GraphQL'i birkaç dakika içinde kullanmaya başlamanıza yardımcı olan bir GraphQL arka uç hizmeti sunuyoruz ve daha sonra fonksiyonlarınızın bir bileşimi olarak GraphQL API'nize kendi microservices'inizi (yani, özel mantığı) eklemenize izin verin. Temelde, size mikro servislerinize nasıl çağrı yapacağınız konusunda esneklik ve kontrol sağlayan en gelişmiş webhook sistemidir.

Bölgede :) bu yardımcı

Umut iseniz ayrıca sf Serverless GraphQL Meetup katılmak için çekinmeyin!

+0

Oldukça ayrıntılı ve açık bir cevap için teşekkür ederiz! – tiansivive

+0

H1 başlıkları ve çoklu bölümlerin kullanımını davet ediyor gibi görünen GraphQL ve yazılım mimarisi hakkında sorularınız var. Bu daveti yanıtladığımı biliyorum :-) –

+0

sorusuyla ilgili çok fazla araştırma yapıyorum ve merak uyandıran şey, eğer graphql ile bir çeşit ağ geçidi gibi davranan bir servisimiz varsa, bunu senkron servis Yoksa grafql hizmetinin yalnızca halka açık olan hizmetlerle eşzamanlı olarak bağlanması gerektiğini mi söylüyorsunuz? – RicardoDuarte