DEV Community: Fırat Oltulu

React mı VueJs mi Hangisini Kullanmalıyım ?

Fırat Oltulu — Thu, 09 Apr 2020 12:41:08 +0000

Hikaye’me nereden başlamalıyım bilemedim, herşey yeni bir uygulama projesi ile başladı.
Herkes gibi bende trend olan teknolojileri araştırmak ile işe başladım. Tabi sadece ben değil, projedeki ekip arkadaşlarım da, araştırmaya başladı. Proje toplantıları, sunumları gözden geçirme derken. ReactJS kurumsal hayatta daha çok tercih edildiğinden bahsedilmeye başlandı. Çünkü arkasında Facebook var. Kurumsal hayatta bu felsefe çok önemli bir uygulama veya bir framework seçer iseniz mutlaka kurumsal desteği olmalı. Tabi ki Frontend teknolojilerinde böyle kurumsal destek, daha çok ücretli satılan paketler de geçerli oluyor. ReactJS ve VueJS için bunu söylemek pek doğru değil, ikisinde desteği sadece topluluk olarak var. (stackoverflow vb.)

Proje toplantıların da gerekse birebirler de ben vuejs kullanma taraftarı olduğumu basa basa söylüyordum, aslında kendimce sebebim çok açıktı.

Öğrenmesi çok kolay.
Yapısal anlamda KnockoutJS, Angular benzer.

Internet de epey araştırmalarım neticesinde iyi bir sonuç alamadım, zira kimse ReactJS, VueJS den daha iyi veya daha kötü diyemez iddia da edemez.

İşi daha karışık hale getirmeden en iyi sonuç ihtiyacınız olan proje için bir POC yapmak. Bende öyle yaptım, önce vueJS ile bir tane temasatın aldım ( https://themeforest.net/item/vuexy-vuejs-html-laravel-admin-dashboard-template/23328599 ), Hızlıca istediğim şekilde düzenlemeye başladım. çünkü anlaşılırdı, gerek bir sayfa kodlarken, Template, Script, Style notasyon kullanımı çok rahat ve bildiğimiz HTML standartdı.

Ayrıca Routing, Vuex yapısı kullanımı çok rahat. ReactJS’deki gibi declarative değil. Diğer konulara pek girmeye gerek yok zira internette bir çok karşılaştırma yazıları bulabilirsiniz.

Gelelim ReactJS’e
Başlar da çok itici geliyordu, çünkü daha öncede angularJS ve knockoutJS kodlama tecrübemiz olduğu için bilinen dışında bir kodlama biçimine sahip. ReactJS ile de POC ( https://themeforest.net/item/air-ui-multi-concept-admin-template/24434456) yapmak gerekliydi. Bu temayı satın alarak yola devam ettim. Düzenledikçe zorlukları fark ettim.

Öğrenmesi epey meşakatli
Yapısal anlamda bilinenlere benzemiyor
Herşey Declaratif
SPA’ya uygun değil ( Şahsi Fikrim )

HOOK ile birşeyleri düzeltmeye kolaylaştırmaya çalıştırmışlar, evet biraz ilerleme kaydetmişler gayet de güzel olmuş.

Redux, Routing yapısılarıda öğrenmek de biraz zaman alıyor.

Sonuç

Her ikisi içinde yeteri kadar dökümantasyon var. Hatta VueJs bu konu da daha iyi
Her ikisi içinde UI kütüphaneleri tatmin edici seviyede
Her ikisinde de gün sonunda aynı etkiyi verebilirsiniz ( Müşteri arkaplanda ne çalıştığını bilmeyeceği için sorun yok :) )
Her ikisininde toplulukları gayet makul düzeyler de

Projeler de temel sorun, zaman baskısıdır. eğer yeterli kadar zamanınız varsa. POC yapın ve size kolay gelen ile yola koyulun.
15 yıllık tecrübem şunu bana gösterdi, trendler değişebilir. değişmeyen tek şey ZAMAN BASKISI

# Windows ortamında NodeJS Javascript Out of Memory Problemi

Fırat Oltulu — Thu, 09 Apr 2020 12:38:58 +0000

ReactJS ile yazmaya devam ettiğimiz bir UI kütüphanesi projesi için, dökümantasyon yazma gereği hissedik ve bunun için https://www.docz.site/ kullanmaya karar verdik.

Harika bir kütüphane, https://www.gatsbyjs.org/ alt yapısını kullarak, hızlı bir şekilde bir websitesi hazırlayabiliyorsunuz.

Gelelim problemimize, yaklaşık 65 sayfa döküman oluşturduk. GatsbyJS SSR ile siteyi oluşturduğu için bir süre sonra Javascript Out Of Memory ( Heap Memory ) almaya başladık. İnternetdeki aramalarımızda, developerların sıkça aldığını gördük. Biz geliştirmeyi windows ortamında yaptığımız için, hali ile internetteki verilen çözümlerde OS belirtilmiyor genelde.

Bu problemi aşağıdaki şekilde çözebilirsiniz.

node_modules/bin klasörü içinde yer alan docz.cmd ve gatsby.cmd dosyalarını açın ve "%_prog%" ifadesinin yanına "--max_old_space_size=8192" aşağıda olduğu gibi.

@ECHO  off
SETLOCAL

CALL :find_dp0
IF  EXIST  "%dp0%\node.exe"  (
  SET  "_prog=%dp0%\node.exe"
)  ELSE  (
  SET  "_prog=node"
  SET  PATHEXT=%PATHEXT:;.JS;=;%
)

"%_prog%"  "--max_old_space_size=8192" "%dp0%\..\docz\bin\index.js" %*

ENDLOCAL
EXIT /b %errorlevel%
:find_dp0
SET  dp0=%~dp0
EXIT /b

Eğer direk node index.js gibi bir ifade ile nodejs modulunüzü çalıştırıyorsanız node index.js --max_old_space_size=8192 şeklinde değiştirmeniz yeterli olacaktır

# ElasticSearch 1.7 versiyonun'dan 7.5 versiyonuna geçiş hikayemiz.

Fırat Oltulu — Thu, 09 Apr 2020 12:37:57 +0000

Merhabalar,

Edindiğimiz tecrübeyi yazıya aktarmak genel'de zor oluyor, fakat tecrübe ve bilgi paylaştıkça daha anlamlı oluyor.

Turkcell içinde müşteri şikayetleri ve diğer süreçleri yönettiğimiz Onedesk adında bir uygulamaz var.

Bu uygulama %100 türk mühendislerinin emekleri ile yazılmış bir BPM alt yapısı üzerinde koşmaktadır. Alt yapı üzerinde koşan tüm uygulamalar ve o uygulamalara ait veriler üzerinde arama ve sıralama işlemleri ElasticSearch alt yapısı kullanılarak çalışmaktadır. Biraz rakamlar ile açıklayacak olursak.

Yaklaşık 600 milyon döküman üzerinde anlık 1500+ kullanıcı ile arama işlemleri yapılmaktadır.
Sistemin bel kemiğini oluşturmaktadır.
- 10 Node üzerinde *5 Primary ve Replica * olacak şekilde bir konfügürasyonu ile çalışmaktadır.
- Ortalama sorgu ve sıralama işlemlerinde ElasticSearch üzerinden dönüş sürelerimiz 5sn altındadır.

Neden version yükseltmeye ihtiyaç duyduk

Yaşam ömrünü tamamlamış bir sürümden dolayı, sıkıntı çektiğimiz durumlarda çözümler genelde yeni sürümler ile sunuluyordu.

ElasticSearch 1.7 sürümünden beri bir çok konuda mesafe kat etti ve çözümler sundu.

Özellikle 7.5 sürümünde bellek, disk ve cluster iyileştirmelerinde bize katkı sunacağını düşündük.

Geçiş Hazırlıkları

ElasticSearch 1.7 versiyonunda type kullanımı vardı, Indexin altında type ile verilerimizi kategorize edebiliyorduk. Fakat 6.8 versiyonundan sonra type kaldırıldığını öğrendik bu bizim için çok büyük bir süpriz oldu.
Çünkü 1 alt yapı üzerinde koşan 12 farklı uygulama var. Sadece değişiklik type ile sınırlı değildi arama ve DSL yapısında değişiklikler söz konusuydu.

Neler yapacağımızı aşağıdaki gibi planladık.

Tüm verilerimizi tekrar indexleyecektik, fakat tüm verileri veritabanından çekip indexlemek çok uzun bir süre olacağı için, Çözüm olarak ES 1.7 ortamından alıp, 7.5 versiyon şemasına uygun hale getirip indexlemeye karar verdik.

Bir aktarım aracı yazdık. Kısaca bahsetmek gerekirse, verileri 1.7 versiyonundan alıp, https://redis.io/ üzerinde muhafa ettik.

Redis üzerinde dosyaya kaydetme işlemini kapattık, Verileri sadece in-memory tutacak şekilde konfügüre ettik.
Aktarımlar sırasında gördük ki, veri boyutu artıkça, redis anlık görüntüyü kayderderken ciddi problemler yaşıyor.

Bunu yapmamızın sebebi önce veriyi alıp, daha sonra başka bir uygulama vasıtası ile 7.5 uygun desene çevirmek olacaktı.

Yaklaşık 2 aylık bir süre veriyi toplayıp ve dönüştürmek ile vakit geçirdik.

Bu süre sonunda, yaklaşık 240 binlik indexlememiz gereken veriyi yaklaşık 6 saatte aktarabilir hale geldik.

Test Süreçleri

Yaklaşık 4 aylık bir test süreci geçirdik. Sürenin bu kadar uzun olmasının ana sebeplerinden biri kullanıcı deneyimlerinde herhangi bir kayıp yaşatmak istemedik, 1.7 sürümünde veri tipleri sınırlı olduğu için özellikle Text alanlarda çok fazla lucene syntax kullanmıştık.
7.5 sürümü ile text ve keyword gibi iki ayrım olduğu için ona göre kullanıcı deneyimlerimde iyileştirmeler yaptık. daha akıllı aramalar seçenekler sunduk.

Preprod test süreci

Canlıda çalışan ElasticSearch topolojisinin birebir uyguladık. ve ek olarak burada 7.5 sürümü ile gelen awareness ayarlamasını yaptık.
Kısaca bahsetmek gerekirse 2 farklı lokasyonda veri tutuyorsanız, replica shard ile primary shardlar kesinlikle ayrı lokasyonda olması kuralını koyduk.
Herhangi bir lokasyonda çıkacak problemde veri kaybı yaşamamak için çok güzel bir özellik. 2 farklı lokasyonda 2 master node olacak şekilde konfigüre ettik.

Preprod testlerimizde başarılı sonuçlar alınca canlı geçişi için hazır hale geldik.

Devreye Alım

PROD devreye alımından sonra, bir süre sistemi izledik, Geçişten 2 gün sonra TCP Keep Alive ile ilgili bir sorun yaşadık, ElasticSearch süresiz bir bağlantı açıyor ( long-lived TCP connections ) fakat şirket prensipleri gereği, bu sürenin bizde sınırlı olduğunu öğrendik, Windows yaptığımız konfügürasyon ile bu probleminde üstesinden geldik.