Yapay zekadan makale özeti
- Kısa
- Ayrıntılı
- Bu video, Ankara Üniversitesi Bilgisayar Mühendisliği mezunu bir front-end geliştiricisinin Opsie şirketindeki kariyeri ve teknolojik gelişim süreci hakkında yaptığı bir teknik sunum ve ardından soru-cevap oturumudur.
- Sunum, konuşmacının kendi tanıtımı, Opsie'deki teknolojik değişimler, front-end yapısının tarihsel gelişimi ve AWS web yapılandırması olmak üzere dört ana başlıkta yapılandırılmıştır. Konuşmacı, 2015'ten günümüze kadar Opsie'de kullandıkları teknolojileri (Java, AngularJS, ReactJS, TypeScript) ve Amazon Web Servisleri (AWS) kullanarak front-end yapısına nasıl adapte olduklarını anlatmaktadır.
- Soru-cevap bölümünde, Mustafa, İlker, Tanrı, Arif ve Selçuk gibi katılımcılar, farklı frontend framework'lerinin (Angular, React, Vue) kullanımı, TypeScript'in avantajları, statik dosyaların S3 üzerinde yönetimi, frontend ve backend entegrasyonu, test stratejileri ve cloud platform kullanımı gibi konulara değinmektedir. Konuşmacılar ayrıca CORS sorunları, CloudFront CDN çözümü, API Gateway kullanımı ve farklı domainler için yapılandırma zorlukları gibi teknik konuları da ele almaktadır.
- 00:01Sunum Planı
- Konuşmacı, sunumun sonunda soru-cevap kısmına 20 dakika ayırdığını belirtiyor.
- Konuşmacı, kendinden bahseden bir başlangıçtan sonra 2015'ten günümüze kadar Opsı'daki büyük değişiklikleri anlatacağını söylüyor.
- Amazon Web Servisleri kullanarak front-end'in geçirdiği süreç, yaşadığı problemler ve bulunan çözümler hakkında konuşacağını belirtiyor.
- 01:04Konuşmacının Kariyeri
- Konuşmacı, Ankara Üniversitesi'nden 2014 yılında bilgisayar mühendisliği mezunu olarak, okul döneminden beri full stack web geliştirme projeleri yaptığını belirtiyor.
- Front-end developer kariyeri Opsı ile başladı ve Opsı'da daha çok full stack eğilimden ayrılıp sadece front-end'e odaklanmaya başladı.
- 2016 yılından beri Tegev'de gönüllülük yapıyor ve mezun olduktan sonra iş hayatına başladıktan sonra manevi boşluğu doldurmak için gönüllülük hayatına geri dönmüş.
- 03:18Opsı'nın Front-End Yapısı Tarihçesi
- 2015'te Opsı'da Java tabanlı Jack kullanan bir uygulama vardı ve AngularJS'e geçiş yapmaya başlamışlardı.
- Uygulama temel özelliklerinden biri serverside render kullanıyordu ve her sayfanın ihtiyaç duyduğu verilerle beraber back-end hazırlanıp HTML client'a veriliyordu.
- 2017'de tamamen AngularJS uygulamasına geçildi ancak performans sorunları yaşanmaya başladı, özellikle büyük veri sayfalarında donma sorunları yaşandı.
- 05:59Teknolojik Geçişler
- Performans sorunları nedeniyle VGS (Virtual Grid System) dahil edildi ve AngularJS'in steks'e yakın olması ve öğrenmesi kolay olması sayesinde büyük veri sayfalarındaki problem çözüldü.
- 2018'in sonlarında Opsı, Atlas Opsı tarafından satın alındı ve Atlas ailesinin bir üyesi haline geldi.
- Atlas Design Guide (ADG) global bir tasarım sistemi olduğu için Jira ve diğer ürünlerinde React kullanıldığı için React komponentlerinin bir kısmı hazır olarak Opsı'ya dahil edildi.
- 07:22Gelecek Planları
- 2019'da uygulama tamamen bir single page application haline getirildi ve Webpack dahil edildi.
- 2020'de React kullanım oranı arttı ve projeyi React'e geçirmek için bir paket sistemi oluşturuldu.
- 2021'e gelindiğinde tamamen React uygulaması olmayı hedefliyorlar ve aynı zamanda TypeScript'i de projeye eklediler.
- 09:35AWS Yapısı
- Opsı'nın 2015'te olduğu gibi benzer bir AWS yapısı vardı.
- Amazon'un DNS sunucusu olan Route 53, gelen domain'in hangi Amazon servisine gideceğini belirliyor.
- CloudFront, Amazon'un CDN çözümü olarak dünya çapında en hızlı ve güvenli şekilde veriyi sunan bir servis.
- EC2, Amazon'un sanal sunucusu olarak çalışmakta ve üzerinde bir Apache server çalışıyor.
- 12:07Amazon Yapı Değişikliği Sorumluluğu
- Konuşmacı, önce sadece statik to sözlerinin update'in geliştirmesinden sorumluken, şimdi yapıyı değiştirmek için yeni bir sorumluluk aldığını belirtiyor.
- Yapıyı değiştirmek için önce Amazon'un genel yapısını anlamak ve eğitime gitmek zorunda kaldığını ifade ediyor.
- Yapıyı değiştirmek istese de, dışarıya paylaşılan resimlerin üzerindeki logoların hepsinin resource domain ile paylaşıldığı bir engelle karşılaşıldığını açıklıyor.
- 13:02Resource Domain Ayırma Çözümü
- Paylaşılan linklerin yapısını değiştiremeyecekleri için, resource domainini ayrı bir yapıda takılacak ve web application'a bulaşmayacak şekilde devam edecek.
- Amazon'un Cloud Sound ve SR çözümlerinden faydalanarak resource domainini ayırmaya karar verdiklerini belirtiyor.
- Amazon'un Simple Storage Service (S3) servisini kullanarak, dışarıya paylaşılan resimlerin aynılarını S3'nin altına koyacaklar ve resource domain'i kendi başına Amazon üzerinde çalışsın diyorlar.
- 14:29CloudFront ve CDN Kullanımı
- CloudFront, CDN (Content Delivery Network) açmak için kullanılıyor.
- S3 bucket global bir yerde (Amerika'da) duruyor ve client isteği geldiğinde CloudFront'a geliyor.
- CloudFront'un dünya üzerinde farklı lokasyonlarda 162 tane edge'i var ve en yakın olan Atina'daki edge'e bakıyor, dosya varsa oradan alıyor, yoksa alıp oraya koyuyor.
- 15:19Yeni Domain İhtiyacı
- Resource domain'i ayırdıklarında, app içindeki JavaScript, CSS ve statik dosyalar için yeni bir domain ihtiyacına düşüyorlar.
- Geçici bir domain olarak resource v2 kullanmak zorunda kaldıklarını belirtiyorlar.
- Yeni yapıda epopsi.com ve resource v2 olacak şekilde iki domain olacak ve resource v2'den gelen isteklerde statik dosyaları buradan alacaklar.
- 16:03Sistemdeki Temel Sorunlar
- Tek bir CloudFront'ta iki domain'in ayrı ayrı CDN'lerini açamıyorlar, çünkü epopsi.com da resource v2'e geliyor.
- CDN'i açarlarsa, epopsi.com da CDN üzerinden aktif olmaya başlayacak ve bazı HTML sayfalarının CloudFront'da cache'de kalması anlamına gelecek.
- Backend ile aynı server üzerinde oldukları için, release ve deploy sayfaları da backend ile beraber oluyor ve sıraya giriyorlar.
- 17:43Webpack ve Dosya Değişikliği Sorunu
- Webpack ile dosyaları alıyorlar ve yeni versiyonda kaldırılan bir özellik veya dosya isminin değişmesi durumunda, client browser'ın keşfettiği versiyonda yeni dosya istendiğinde hata veriyor.
- Eski versiyonda olan client için sayfaya refresh etmesi gerekiyor, yeni versiyonu çekmesi gibi sıkıntılar oluşturuyor.
- Bu sorunları çözmek için yeni bir frontend station'a geçmeye karar verdiklerini belirtiyorlar.
- 18:26Single Page Application Çözümü
- Amazon üzerinde single page application nasıl seyredileceği konusunda araştırma yapınca, bir CloudFront ve bir S3 pocket kullanarak dosyaları oraya atıp servet edebilirsiniz diye bir çözüm buldular.
- CloudFront'un error page ayarı yapıldığında, dosya bulunamadığında 404 dönüyor ve bunu yakalayıp index.html'i S3'ten alıp client'e veriyor.
- Bu çözümde çok kompleks bir yapı veya kompresyon yok, sadece synd routing olarak single page application çalışıyor.
- 20:19Multi Page Application Sorunları
- Epopsi.com domainleri için her custom için oluşturdukları bir sub domain var ve oradan servet ediyorlar.
- Uygulama tamamen bir single page application değil, history kısmında aynı webpack ile boyut olan ama single page application'a girmeyen dışarıda servet edilen sayfalar var.
- Jira'nın içinde bir iframe içinde react komponenti çalışıyor ve bu iframe ops üzerinden servet ediliyor.
- 21:19Çözüm Alternatifleri
- Multi page olan uygulamaları servet etmek için tek bir CloudFront yeterli gelmiyor.
- İlk denedikleri çözümde, her multi-page için ekstra bir CloudFront ekleyip hata sayfasında hangi index'i bulması gerektiğini belirtiyorlardı.
- Bu çözümde üç tane CloudFront kullanıyorlardı ancak yönetimi zor olmaya başlıyordu ve customlar için sundukları farklı sub domain isimleriyle aynı dosyaları servet etmek de CloudFront'da büyük olmaya başladı.
- 22:16CORS Sorunu ve Çözümü
- Sub domainlerden eposi.com'a ulaşıldığında CORS açmak gerekiyor, ancak CORS açıldığında tüm uygulamaya açılmış oluyor ve herhangi bir yerden erişilebiliyor.
- Çözüm olarak yeni bir domain olan statik.option.com kullanıldı, bu domain sadece CDN çözümünü sunuyor.
- Statik.eposi.com'da CloudFront kullanılarak CDN açıldı ve burada CORS açılarak apps.com korunmuş oldu.
- 23:47Web App ve Multi-Page Application Sorunu
- Web app artık sadece bir API gibi davranıyor, HTML dönmüyor sadece JSON cevap veriyor.
- Multi-page application olmaktan dolayı farklı URL'ler için farklı index dosyaları almak gerekiyor.
- Önceki yapıda Tomcat dosyaları dönerken güvenlik header'ları ekliyordu, ancak CloudFront ve S3 kullanarak bu headerları ekleyemiyorduk.
- 25:33Lambda Function Kullanımı
- Lambda function, Amazon'un sunduğu bir kod bloğunun çalıştırmasını sağlayan, ayrı server veya konfigürasyon gerektirmeyen bir servis.
- Lambda function CloudFront'un edge'lerinde çalıştırılıyor ve ekstra legend seçmek ve konfigürasyon yapmak gerekmiyor.
- İki lambda function kullanıldı: biri alarm sayfası için doğru indexi S3'den istiyor, diğeri HTML döndürürken gerekli header'ları ekliyor.
- 27:15Lambda Function'ın Sorunları
- İki lambda function çalıştırılması sayesinde security header'ları eklenebiliyor ancak cashleme sorunu yaşanıyor.
- HTML sayfalarını cashlemek istenmiyor, her zaman yeni versiyonu S3'ten almak gerekiyor.
- Aynı HTML'i farklı URL'ler için farklı header'larla döndürme sorunu yaşanıyor çünkü edge function sadece dosyayı biliyor, hangi URL'ye atıldığını bilmiyor.
- 29:29API Gateway Çözümü
- Amazon support, farklı URL'lere göre farklı indexler döndürme ve response header'larını değiştirmek için API Gateway önerdi.
- API Gateway ile tek bir servis kullanılarak, gelen requestlere göre doğru index döndürme ve header eklemesi yapılabildi.
- API Gateway, gelen requestleri karşılayıp response'ları ayarlayabilir, Lambda function'ları bağlayıp client'a response dönebilir ve response'ları düzenleyebilir.
- 31:05S3 ve CDN Avantajları
- S3, Amazon'un güçlü servislerinden biri olup dosyalara her zaman ulaşabiliyoruz ve ekstra server ayağa kaldırmak gerekmiyor.
- CDN kullanımı sayesinde dünya genelinde sayfa load time'ı 8-9 saniyeden maksimum 3 saniyeye düşürüldü.
- Backend application artık HTML sayfalarını seyretmek zorunda değil, sadece AJAX isteklerine cevap veren bir API gibi davranıyor.
- 33:21Teknoloji Seçenekleri ve Zorluklar
- Atlas platformu neden tüm ürünlerde aynı teknolojiyi kullanmak istiyor, bu da ortak bir dizayn ve framework oluşturmayı amaçlıyor.
- Angular, React ve Vue üç farklı teknolojiyi aynı anda kullanmak zorluklar yaratıyor, özellikle iki yönlü iletişim kurulduğunda kaotik durumlar yaşanabiliyor.
- Angular 1.x versiyonundan Angular 2.x'e geçiş yapıldı ve şu anda Angular ile React arasında geçiş sürecinde bulunuluyor.
- 38:47Teknoloji Seçimleri ve Deneyimler
- Angular ve React arasında kişisel tercihler var; Angular kullanıcıları için React öğrenmesi daha kolay olabilirken, React kullanıcıları için Angular öğrenmesi zor olabilir.
- Angular kullanıcıları için React'e geçiş daha kolay olabilir, ancak React'ın öğrenme eğrisi daha yüksektir.
- Angular 1.x versiyonundan Angular 2.x'e geçiş yapıldı ve şu anda Angular ile React arasında geçiş sürecinde bulunuluyor.
- 40:47TypeScript Kullanımı ve Avantajları
- TypeScript, özellikle DTO (Data Transfer Object) değişikliklerinde undefine obje hatalarını önleyerek düzen sağlıyor.
- Java arka planlı kullanıcılar için TypeScript daha rahat kullanılabiliyor, ancak JavaScript dünyasından gelen kullanıcılar için öğrenme eşiği var.
- TypeScript öğrenmek için ekstra zaman gerekiyor ve takım olarak bu süreci aşmaya çalışıyorlar.
- 43:03Statik Dosyaların Versiyonlanması
- Statik dosyalar S3'de tutuluyor ve her gün yaklaşık 5-6 dil için yeni versiyonlar oluşturuluyor.
- Şu an için versiyonlama konusunda sorun yaşanmıyor, client eski versiyonları S3'den alabiliyor.
- Gelecekte çok fazla dosya biriktiğinde geriye doğru silme işlemi yapılabilir.
- 44:02Backend ve Frontend İlişkisi
- Backend ve frontend arasındaki anlaşmazlıklar olabilir, ancak mümkün olduğunca ortak noktalarda buluşmaya çalışılıyor.
- İki taraf arasında anlaşmayı önceden yapmaya çalışıyorlar.
- Büyük firmalarda genellikle internal dökümantasyon ve API kullanımı için belirli kurallar vardır.
- 45:59Test Stratejileri
- 2015'te internet test şeklinde başlamışlar, ancak feature isteği artması nedeniyle test kısmını bir dönem aksatmışlar.
- React geçişi sırasında tekrar unit test ve integration test'e ağırlık vermeye başlamışlar.
- Testleri çok fazla uygulamamışlar, ancak tekrar hayata geçirmek istiyorlar.
- 47:04AWS ve Edge Fonksiyonları
- Lambda yavaş olduğu için API Gateway kullanmaya başlamışlar, bu çözüm maliyetli ama Lambda'ya göre daha performanslı çalışıyor.
- Farklı castler için farklı indeks ihtiyaçları nedeniyle edge fonksiyonlara ihtiyaç duymuşlar.
- 48:02Uygulamalar Arası Haberleşme
- Uygulamalar arasında haberleşme için olabildiğince kaçınıyorlar, kendi işlerinde kalmalarını sağlamaya çalışıyorlar.
- Angular'ın broadcast function'larını kullanarak haberleşme sağlıyorlar.
- 49:35Tasarım ve Otomasyon
- İlk başta Bootstrap kullanıyorlardı, ancak designer ekipleri ve Atlas'ın tasarım ekibi ile çalışınca kendi tasarımlarını yapıyorlar.
- Otomasyon için önce Jenkins kullanıyorlardı, sonra farklı bir çözüm kullanmaya başlamışlar.
- 53:13Cloud Avantajları
- Cloud servisleri, uygulamayı geliştirmeye odaklanırken diğer sorunlardan kurtulmayı sağlıyor.
- S3 gibi servisleri kullanırken sadece API ve S3'ü öğrenmek yeterli, diğer teknik detaylardan kurtuluyorlar.
- Cloud'un en büyük avantajı, ilgilenmediği kısımları servis sağlayıcısına bırakıp, işine yarayacak servisleri kullanabilmektir.