Perşembe, 18 Ekim 2018

SPFx Ninjas Serisi #3 : Neden SPFx?

Merhabalar,

Geçtiğimiz makalemizde SPFx e giriş yapmış ve özelliklerinden bahsetmiştik.Bu yazımızda neden SPFx’i tercih etmemiz gerektiğini yazıyor olacağım.O halde başlıyoruz.
Neden SPFx ?

Neden SPFx sorusunun cevabı SharePoint uygulama geliştirme tarihinde saklıdır.Neden böyle bir ihtiyaç doğdu? Neden eski geliştirme alışkanlıkları bir anda kenara itilip SPFx tercih edildi? gibi yanıt bekleyen birçok soru mevcut.Tüm bu sorulara bu yazımızda cevap veriyor olacağım.

Sunucu Taraflı Model

SharePoint’in ilk piyasaya çıkışından itibaren geliştiriciler XML tabanlı konfig dosyaları ve sunucu taraflı kodlama yöntemini kullanarak geliştirmeler yapmaktaydı.Sunucu tabanlı yapılan geliştirmelerde sunucuya erişim yetkisi olan hesaplar üzerinden geliştirmeler yapılıp, yine sunucu üzerinde yazılan çözümler sunucu üzerinde paketlenerek SharePoint’e yüklenmekteydi.

On-Premise sistemleri açısından baktığımızda sunucu tabanlı/taraflı model’de herhangi bir sorun görünmemekte, lâkin bulut tabanlı mimariler geliştikçe ve talep/tercih edildikçe, sunucu tabanlı geliştirmelerde popülerlik yavaş yavaş istemci tabanlı/taraflı modellere kaymaya başladı ki istemci tabanlı/taraflı modeller her 2 platform(On-Premise ve Bulut) çalışmaktaydı.

Sunucu tabanlı/taraflı model bulut sistemine ragmen On-Premise mimarisinde yaşamını sürdürmektedir.Özellikle Türkiye açısından baktığımızda; Bankalar ve Devlet Kurumlarının Portalleri başta olmak üzere birçok sistem On-Premise üzerine inşaa edilmiş vaziyettedir.

İstemci Taraflı Model

Web Teknolojileri geliştikçe -özellikle Betik dillerinde- sunucu tabanlı modellerin kullanımında gerilemeye sebep olmuştur.Bunun birçok sebebi mevcuttur.

1-Dağıtılabilirlik

Javascript ile yazılmış uygulamaların dağıtımı sunucu modeline nispeten daha kolaydır.Ne bir yüklemeye ihtiyaç duyar,ne dll kullanır, ne de aktive edilmesi gereken bir bileşendir.Dağıtımı kolay olan bir model, müşterilerine hizmet/fayda satan yazılım evleri/danışmanlar için bir nimet niteliğindedir.İstemci taraflı model adını verdiğimiz betik enjekte modeli de bunu fazlasıyla sağlamaktadır.

2-Sunucu tabanlı/taraflı görevlerin bir kısmını yapabilme yeteneği

Özellikle de sunucu tabanlı/taraflı sistemlerde yazılım geliştirenler iyi bilir,bu sistemlerde görevlerin büyük bir çoğunluğu verilerin liste/kütüphanelerden çekilmesi veya liste/kütüphanelere yazılması işlemidir.Betik dillerini kullanarak günümüzde bu görevleri de kolaylıkla gerçekleştirebilmektesiniz.

Örneğin; sunucu tabanlı C# kodu ile yazılan bir Listeden veri okuma işlemini betik dilleri ile sharepoint webservisi’ne veya REST API’ye Ajax GET/POST talepleri göndererek ve gelen sonucu da parse(inceleyerek) ederek ekrana basabiliyorsunuz.

Lâkin,istemci taraflı model asla Sunucu taraflı modelin yerini alması beklenen bir model değildir.Gelişen web teknolojilerine ayak uydurabilmek/ön ayak olabilmek adına Microsoft tarafından geliştirilen yardımcı geliştirme yöntemidir.

 

İstemci tabanlı/taraflı betik modelinin dezavantajı, özellikle son kullanıcının sayfaları düzenlemek istediğinde meydana gelen betik uygulamalarının bozulması gibi “NoScript” aktive edilen sitelerde de çalışmaması idi.

SharePoint-Apps Modeli

Bu modelimiz ise farklı bir context üzerinde çalışan veya diğer bir deyişle “iFrame” kullanması sebebiyle Client Side development açısından kolaylıklar sağlamaktaydı.

Özellikle de dağıtılabilirlik noktasında,App olarak geliştirdiğiniz paketleri SharePoint Marketplace üzerinden müşterilerinize satışını gerçekleştirebilmekteydiniz.

Lâkin bu sistemin de dezavantajı farklı bir DOM arabiriminde çalışmaası sebebiyle yavaş kalmasıydı. İstemci betik yükleme modeline göre daha yavaş çalışacaktı.

Örneğin,diyelim ki;
Bir istemci uygulaması 3 sn içerisinde açılıp çalışıyorsa, app modeli’nde bu uygulamanın çalışması 2+ saniye daha fazla sürecekti.App modelinin “iFrame” kullanmasının dezavantajlarından biridir.

iFrame kullanımının en büyük dezavantajlarından birisi de mobil uyumluluğunun çok zor bir şekilde uygulanmasıdır.

Ve App modelini de deneyen geliştirici bu modeli test/tecrübe ettikten sonra, artık ne kullansam,hangi durumda hangi modeli tercih etmeliyim gibi ikilemlere düşmeye başladı.

Neyse ki Node.js kullanımının revaçta olması dolayısıyla popülerliği de baz alındığında SharePoint için de plugin geliştirmenin önü açıldığında ister daha önce SharePoint geliştiriciliği yapmış bir yazılım uzmanı olun isterseniz de full stack geliştirici olun,SPFx en güncel web teknolojilerini birarada kullanmanıza olanak sağlayan muhteşem bir uygulama geliştirme modelidir.

Not: SharePoint İstemci Modeli ve SPFx arasında bir de PnP modeli mevcuttur.Bu model aslında full trust sunucu paketlerini SharePoint Apps yöntemine taşımak için gerekli yönlendirmeler,işin hileleri/bilinmeyenlerinin anlatıldığı bir açık kaynaklı projedir.PnP bu serinin konusu olmadığı için üzerinde fazla durmayacağız ama PnP’nin SPFx’de nasıl kullanılacağına dönük bir adet küçük uygulama demomuz olacaktır. PnP test etmek isterseniz: https://github.com/SharePoint/PnP adresinden incelemenizi yapabilirsiniz.

Ve SPFx!

SPFx istemci taraflı modeli bir adım ileriye götüren, en güncel web teknolojilerine açık kaynak araçlar ile birlikte kullanmanıza olanak sağlayan bir sayfa ve webpart geliştirme modelidir.

SPFx modelinin bu kadar popüler olmasının ana sebeplerinden birisi de iFrame kullanmadan, direkt sayfanın içine betiklerin eklenmesi, aynı DOM üzerinde çalışılması ve de kontrollerin mobil uyumlu olması.Kullandığınız kütüphaneler en son web teknolojileri olacağından ötürü artık standart hâlini almış mobil uyumluluk konusu bir sorun teşkil etmeyecektir.

Diğer güzel tarafı yerel bilgisayarınıza kurduğunuz geliştirme ortamı ile bile SharePoint’e webpart geliştirebiliyor olmanız.Yerel bilgisayardan SharePoint Liste/Kütüphanelerine erişmek hâtta aynı şekilde bu verileri yazabiliyor olmanız da desteklenmektedir.

Performans konusunda en güzel havadis ise Javascript Injection yönteminden daha hızlı çalıştığıdır.Javascript Injection diye tabir ettiğimiz Client Side WebPart’ların gelişmiş bir versiyonu – sanırım biraz hafif bir terim oldu bu,daha kapsamlı/detaylı diye düzelteyim – ile karşı karşıyayız.İstemci tabanlı geliştirilen kodlar zaten olduğu gibi SPFx’e hangi web teknolojisini kullanıyorsanız aktarılıyor olacaktır ancak sunucu tabanlı kodlama yapmaya alışmış yazılımcılar da TypeScript öğrenerek varolan C# kodlarını SPFx modeline dönüştürebilirler.SPFx projeleri workbench adını verdiğimiz geliştirici sayfasında çalışır.workbench sayfası gulp ile açıldığında yerel makinanız üzerinden çalışmaktadır.

Şimdi gelelim Geleneksel Geliştirme Modeli ile Web Teknolojilerini karşılaştırmaya ve denk teknolojilerini bulmaya.

SPFx’de sunucu tabanlı her işin bir karşılığı mevcuttur.

 

SPFx SharePoint Online ‘da ve Feature Pack 2 kurulumu ile de SharePoint Server(On-Premise) üzerinde çalışmaktadır.Global Availability sürümü yayınlanalı birkaç ay olmakla birlikte şu anda canlı ortamlar için SPFx modelinden faydalanabilmektesiniz.

Bu makalemizde SPFx’I neden tercih etmeniz gerektiğini,SPFx’e geçmenin ne gibi kolaylıklar sağlayacağını, denk teknolojileri ile eşleştirerek hangi web stack teknolojiyi yatırım yapmanız gerektiğini anlatmış olduk

Bir sonraki makalemiz ile birlikte SPFx ortamımızı kurmaya “Node.js Kurulumu” ile başlıyor olacağız.

Okuduğunuz için Teşekkür ederim

 

 

 

CTO @ Araf Global - C# Corner MVP(2010'dan beri) - C# Corner ve UnifyTurkiye Yazarı

1 Comment

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

This site uses Akismet to reduce spam. Learn how your comment data is processed.