Meteor.js Serisi : 1- Meteor.js Nedir ? Mimari olarak genel bakış

Meteor.js ile uygulama geliştirme 1 :

 Connected Client & Isomorphic APIs – Meteor.js ve yeni nesil gerçek zamanlı  web mimarisi.

Son 2-3 yıldır çok yaygın olarak kullandığımız, Rest-ful tabanlı mimari ile eskiye göre çok daha fazla iş yükü üstlenen istemci taraflı uygulamaları (çoğunlukla tarayıcılar) ve birçok Javascript freamework ün yükseldiğini gördük.(Angular, Ember vs.)  Bu süreç, uygulama mimarimizi de çok ciddi anlamda değiştirdi.

İstemci tarafında çok şey değişti, kendi logic yapısını barındıran, routing / yetkilendirme vs. gibi önceden sadece back-end mimariyle anılan yapıları, istemci tarafına taşıdık, sonrasında; artık nerdeyse “sadece data-access layer / veri erişim katmanı “olarak kullanmaya/tasarlamaya başladığımız sunucu taraflı mimari  surecine girdik.

“webrtc, websockets” gibi yeni protokollerinde uygulama geliştirme sürecine girmesiyle, eskiden daha zor ve bazen nerdeyse “bir alternatifi var mı” diye hiç düşünmediğimiz “veriyi takas etme” yöntemlerimizin değişmesinden, istemcilerin sunucuyla iletişime birçok yeni yöntem ve standardı görmeye başladık.

Bu değişiklikler sadece, teknik anlamda ya da dil/platform/yeni protokoller bağlamında da değildi üstelik. Kullanıcıların da “uygulama ile etkileşim” beklentileri ciddi anlamda değişiyordu. Facebook dan Gmail den edindikleri “gerçek zamanlı, reactive yapıları”  bizim geliştirdiğimiz sistemlerden de bekler oldu kullanıcılarımız.

Bu süreç, Facebook, Google, Microsoft gibi büyük firmaların bazı ürünlerinde, klasik istemci/sunucu mimarisi ve rest-ful yapı ya ek olarak , “connected clients” olarak anılmaya başlayan bir yapıyı beraberinde getirdi.

Diğer taraftan, klasik istemci kavramı (istek yap ve cevap bekle den) , bazen ya da bazı işler için  gerçek zamanlı yapıya sonrasında ise,  istemcinin sunucuya sürekli bağlı olduğu(offline da çalışabilen) yapılara geldik(connected clients ve ya always alive and connected).

Özellikle finans alanında, verinin real-time/gerçek zamanlı aktarım süreci; verinin istemci veya sunucu tarafından “gerçek zamanlı” olarak işlenmesi beklentisinide karşımıza çıkardı. Üstelik, her geçen gün daha fazla istemci bu gerçek zamanlı – connected yapıya dahil oluyordu.

Verinin, gerçek zamanlı olarak aktarılması, işlenmesi, istemcilerin(özellikle tarayıcılar ve mobil cihazlar) ın gelen gerçek zamanlı veriyi kabul edilibilir bir şekilde “reactive olarak” yonetebilmesi gibi temel ihtiyaçlar, ve bu sürecin, özellikle “ölçeklenebilir, dağıtık servisler oluşturulması”  gibi öncelikleriyle birlikte tamamı için kullanabilecğimiz bir kavram “Connected Clients”.

Connected Clients – Bağlı istemciler yapısı; Reactive Programing kavramını, pratik de bir mimari gereksinim olarak karşımıza çıkardı. “Connected clients” mimari için önemli bir gereksinim olan reactivity, facebook, microsoft gibi firmalar için bile “ciddi insan kaynaklarına rağmen” zorlu bir süreç olarak geliştiği aşikâr(ciddi insan kaynağı ve maliyetler bilgi birikimi vs.).  Sadece, facebook tarafından bakacak olursak, React, Flux, GraphQL, Delay vs. bir sürü framework ve mimari tasarım ortaya cikti bu sorunu çözmek için.

Genel yapı olarak reactive programing. 

Reactive UI, Reactive Connection, Reactive DB, WebSocket protokollerinin yönetimi vs. gibi bir kaç alt parçadan oluşacak bir reactivity sistemini geliştirip, connected client mimariyi kendi başımıza oluşturmak hiç de kolay bir süreç değil maalesef.

Bir karşılaştırmayı da .NET dünyası için sanırım şöyle yapabiliriz.

  1. Http protokolü ve statik dosyalarımız için ASP.NET MVC
  2. Rest için WEB.API
  3. Gerçek Zamanlı iletişim için Owin{SignalR}
  4. Güçlü bir Messaging ya da Pub/Sub alt yapısı, Rabbit MQ veya Akka.Net/Orleans
  5. Veri tabanı ve ORM; SQL Server / EF
  6. Reactive UI ; Angular/Ember/React
  7. Merkezi bir Yetkilendirme sistemi; SSO / Identiy Server

Yukarıdaki listede, Ölçeklenebilirlik, Reactivity yi yönetecek merkezi bir sistem vs. gibi birçok şeyinde  eksik kaldığını görmekteyiz.

Birçok framework u birçok mimari yapıyla düzgün bir şekilde adapte edip kullanmak, maliyet, insan kaynağı ve üretkenlik açısından da başkaca bir sıkıntılı süreç.

Meteor.js için, bazıları adına sadece “İyi bir real-time / gerçek zamanlı ” iletişim sunan node.js freamework ü” diye yanlış ve eksik bir bakış açısı olsa da, esasında meteor geliştiricilerinin de ifade ettiği gibi, hem bireysel hem kurumsal uygulamalar geliştirmek adına Javascript dünyası için geliştirilmiş “Connected Clients” mimarisini temel alan komple ve “Reactive” bir platform.

Bir kullanıcının bir button u tıklaması ile başlayan; reactivity, UI -> , Local Bellek -> Soketler-> Sunucu -> DB,  ye ulasan, sonrasında gerekiyorsa; Sunucu -> diğer istemciler ile biten bir süreç.

Meteor. js  iste tam burada devreye girerek, bu sorunları(connected clients mimarinin sorunlarını ve reactivity i), all-in-one olarak tek başına çözmeyi vaat eden bir platform.

Kısaca Meteor platformunun parçalarını listeleyecek olursak,

  1. Node.js ile sunucu yapısını,
  2. MongoDB(+Oplog)  ile Reactive DB yapısını (Mongo db resmi olarak meteor tarafından destekleniyor, Mongo dışında diğer DB ler içinde çözümler mevcut)
  3. Pup/Sub ve DDP ile Reactive Connection mimarisini(web soketler üzerinden)
  4. Blaze ve tracker sistemi ile Reactive UI sistemini
  5. MiniMongo ile istemci taraflı veri yönetimi ile offline çalışma modelini

Sağlayarak, ready-to-go / hazır bir uygulama yapısı sunuyor.

Yukarıdaki listeye bir kaç ek daha yaparak devam edecek olursak.

“Isomorphic Javascript ve Isomorphic APIs” kavramı da önemli bir artı Meteor.js için.  Hem istemci tarafında, hem sunucu tarafında tek bir dil Javascript” i ve istemci / sunucu tarafından hemen hemen ayni alt yapı kullanmayı (Meteorun bize sunduğu API yeteneklerini) sağlayan bir platform Meteor.

Dâhili build system / inşa araçları, büyük bir eklenti ve paket eko sistemini de unutmamak gerek.

Bir meteor uygulaması yukarıdaki saydığımız maddeleri, 3 ana başlık altında toplayıp yönetebileceğimiz bir yapıdan oluşuyor da diyebiliriz. (the server/sunucu, the communication channel/iletişim kanalı, and the client / istemci.)

Simdi sistemin temel parçalarına biraz daha detaylı bakarak devam edelim. (Bu alt başlıkları ileriki yazılarda yeri geldikçe detaylı olarak ele alacağız, burada genel bir bakış açısıyla değinmiş olduk.)

The Server – Sunucu

Ana sunucumuz . Node.js

Hem http istekleri için hem DDP ile WebSocket yönetiminin ana alt yapısı. Asyncronous yapısı ve event-loop / lib-uv gibi iç sistemleri ile ölçeklenebilirlik adına çok iyi bir başlangıç noktası sunmakta. Kolayca yatay ve dikey ölçeklenebilme imkânı sunmakta.

Database / Veri Tabanı

Meteor.js varsayılan olarak MongoDB ile birlikte gelmekte. MongoDB de tıpkı Node.js gibi hem yatay hem dikey ölçeklenebilirlik adına kolaylıklar vadediyor. Sharding & Replica setler gibi kolayca kullanılabilecek bir alt yapı sunuyor ölçeklenebilirlik adına.

MongoDB, kendi içinde bir trigger ya da transaction desteği sunmasa da, OpLog ile meteorun Reactive DB mimarisine kolay ca adapte edilmiş.

Diğer veri tabanlarını da Meteor dünyası içinde kullanmak gayet kolay. Fakat, meteorun MongoDB için sunduğu Reactive DB alt yapısı, diger veri tabanlari icin standart olarak sunulmamakta. Diğer DB(MySQL, Rethink vs.) ler için çok karmaşık ve zor olmayan bir kaç ara adim ile Reactive DB uyarlamasını gerçeklemek de mümkün.

Meteor diğer bir kaç meşhur SQL ve NoSql db içinde tıpkı mongo ya sağladığı desteği  2016 da sağlayacağını açıkladı. Ayrıca topluluk tarafından geliştirilen ve bugün production da kullanılan paketler de mevcut.

PUBLISH/SUBSCRIBE – Abonelikler ve Dağıtımlar

Meteor.js in en önemli parçalarından biri Publish/Subscribe mekanizması diyebiliriz. İstemcinin, ihtiyacı olan verileri yayınlayan kanallara abone olması ve verinin istemci sunucu arasında dolaşımını sağlayan alt yapı.

Burada bir şeyi belirtmekte fayda var, klasik Pub/sub modelinin çok daha üzerinde bir model olduğunu ve klasik anlamda, broker / ya da messaging / ya da bir kanala abone olmaktan farklı olarak, UI – DDP – Sunucu – Veri Tabanının sizin ekstradan bir işlem yapmadan bir birinden haberi olmasını da sağlayan bir model.

Communication channel – Bağlantı Katmanı

Distributed Data Protocol (DDP) – Web socket veri transfer protokolü

DDP Meteor.js için geliştirilmiş ve web socket iletişimine bir standart kazandırmayı amaçlayan bir protokol. Başarılı bir süreç den sonra hem Meteor.js için, hem de diğer sistemlerle birlikte kullanabileceğimiz bir protokol haline dönüşmüş durum da. Klasik web uygulamalarımız da veriyi genellikle http protokolü üzerinde taşırken, Meteor.js Web socket ler üzerinden bu iletişimi sağlamakta.

DDP için, bir yönüyle ; “Rest over Websockets”  / Rest protokolünün web soket uyarlaması diyebiliriz. Fazladan isin içine “Dublex  / “İki yönlü bir yapıyı kattığını belirtelim. Ayrıca istemci ya da sunucun fazladan bir şey yapmadan, istemcinin gerek gördüğün de sunucudaki veriyi güncelleyebildiği ve ya sunucu ile kıyas yapabilen bir yapı. Rest için defakto standart haline gelen JSON, DDP içinde kullanılan veri türü.

Meteor.js ile HTTP protokolü veya Rest-ful mimariyi de kullanabilsek de, Meteorun gerçek gücünü kullanabilmek için  web soketler ve DDP’yi ilk  seçenek olarak düşünmek de fayda var.  Ayrıca, DDP vasıtasıyla, bir den fazla sistemin bir birleriyle iletişimini de kolayca sağlayabilme imkânımız var. Micro Service benzeri yapılar içinde kolay bir altyapı ve kaliteli bir standart olarak karsımız da.

 

Client – İstemci

Meteor.js in istemci tarafı için bize sağladığı bazı ekstra özellikler mevcut;

MINIMONGO

İstemci tarafında (bir tarayıcı, mobil cihaz vs.) in-memory / örneğin tarayıcı hafızasın da / ram de tutabileceğimiz bir cache / bellek. MiniMongo olarak adlandırılmasının sebebi, klasik bir javascript nesnesi olsa da, Mongo DB sorgu sentaksı ile istemci tarafında sorgular yapabilmemizi sağlamakta. Burada, minimongo yu, sadece cache / ara bellek gibi düşünmek hata olacaktır, mini mongo, istemcideki kopya ile sunucudaki kopyayı sync – güncel tutma yeteneğine de sahip. Böylece Offline çalışma imkânlarından, Reactive  – ui a kadar birçok imkânı bize sağlamak da.

 

BLAZE

Meteor.js in varsayılan / default  HTML motoru/view engine.  .NET dünyasındaki @Razor, Javascript dünyasından handlebars, Laravel den Blade in yaptığı isi meteor için yapmakta. Fakat Reactive UI için ekstra yeteneklerde sahip. Mini mongo üzerindeki verinin değişimi ile kendi kendini güncelleyebilme yeteneğine sahip. Handlebar kullandıysanız kolayca adapte olabileceğiniz bir yapı.

Meteor 1.2 surumu ile birlikte, Angular.js ve React.js i de resmi olarak desteklemeye başladı. Bu iki freamework u de uygulamalarınız da kullanabilirsiniz. Blaze in yeni sürümünün 2016 yaz aylarında yayınlanması planlanıyor, bu yeni yapı ile react a benzer bir yapıya kavuşacağı ama react dan daha kolay olacak yeni bir sürüm olması bekleniyor.    [Güncelleme : bu konuyla ilgili yeni bir gelişme var.  Yeni Blaze, eski yapısını  koruyacak(react benzeri yada react üzerine kurulacak) bir yapı olarak geliştirilmesinden vazgeçilmiş. "Bence çok da isabetli bir karar olmuş, blaze kullanımı çok kolay bir yapı, üstelik react yada angular kullanmak isteyenler için zaten bu seçenek mevcut”]

TRACKER

Blaze için state yöneticisi. Angular 1.x deki $scope a , react daki this.state e benzetebiliriz. UI üzerinde ki tüm değişiklikleri takip eden küçük ara bir katman.

Bu yazıda genel olarak Meteor.js i ve meteorun connected client mimariyi nasıl gerçekleştirdiğine bakmaya çalıştık. Üstelik ciddi bir kolaylık olan Isomorphic yapıya ya da mobil uygulama geliştirme imkânlarına da değinemedik.

Javascript dünyasında kendine şimdiden ciddi bir yer edinmeyi başaran bu Reactive Platform adından daha sıkça söz ettireceğe benziyor.

Bir sonraki yazıda örnek uygulama ile biraz daha detaylara bakalım.

Kaynaklar :

https://www.meteor.com/projects

http://guide.meteor.com/

View story at Medium.com

http://www.angular-meteor.com/

https://kadira.io/

http://info.meteor.com/blog

5 thoughts on “Meteor.js Serisi : 1- Meteor.js Nedir ? Mimari olarak genel bakış

  1. Hocam meteor.js sayende iyi bir ivme yakaladim ancak elimde bir proje var bununla ilgili bir sorum olucak.personel giris cikis kayitlarini tutan ayni zamanda turnike sistemini yetki durumuna gore acip kapatacak hem ip veya seriport uzerinden veriyi alip gerekli sorgulari yaptiktan sonra giris izni verilecekk..bunu meteor.js ile yapmam mumkunmu cok fazla engelle karsilarmiyimm..

    1. Merhaba.
      Boyle bir proje meteor ile yapılabilir ama turnike ile meteor uygulamasının arasındaki iletişimin nasıl sağlanacağı önemli. Bire bir aynı olmasada, buna benzer bir projede node.js ve socket.io kullanımım olmuştu. Sonuçta meteor node.js üzerinde çalışacağı için, Meteor un eksik kaldığı yerlerde Node.js ekosistemini kullanabilirsin.

      Ama tekrar belirtmekte fayda var, kurmak istediğiniz sistem hakkında bu kadar bilgi ile sorun olmaz yada sorun olur demek doğru olmaz. Yanlış yönlendrimek istemem.

      Kolay Gelsin.

  2. Oncelikle cevap icin tesekurler.turnike sistemi ile node server arasinda seriport veya belli ip ler uzerinden veri alis verisi olucak bu tur sistemler hakkinda bilginiz vardir diye dusunuyorum.kart okuyucu karti okuduktan sonra ip uzerinden veya seri porttan kartin id numarasini gonderir alinan id numarasi veri tabanindan gerekli sorgular yapildiktan sonra tekrar ayni protokolle turnikeye open talimati verilir.bu seneryoya gore meteor yeterlimi veya dediginiz gibi node.js ekosistemi boyle bir uygulamaya icin yeterlimi

    1. Bana göre yeterli. SIkıntı olabilecek durum, turnike sistemin eski olması yada gerekli iletişim API ları vs in yeni standartları desteklememesi gibi durumlar olabilir. Ama artık node dünyasında 3 aşağı 5 yukarı hemen hemen herşeyi bulmak mümkün.

      Kolay Gelsin.

Leave a Reply

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