Backend Web Development Üzerine Herşey…
Girizgâh
Burada değineceğimiz tüm konuların başlıkları backend, yani arka uç geliştirmeye istinaden en anlaşılabilir biçimde olup, yazıyı sonuna kadar okuduğunuzda hiçbir bilgi sahibi olmasanız dahi bu konuyla ilgili olan hemen hemen her teknoloji ve terimleri ile de ilgili bilgiye sahip olacağınızdan emin olabilirsiniz.
Özellikle işin frontend, yani ön uç tarafında olup, fullstack olarak çalışmak isteyen ya da frontend kısmından backend’e geçmek isteyen arkadaşlarımız için bir nebze dahi olsa bilgi sahibi olabilmeleri için bu yola açıklık getirmek istedim. Malum hali hazırda çok fazla sayıda İngilizce dökümantasyon, video, makale vb. kaynaklar olsa da işin henüz başında olan arkadaşlarımız için anlaşılabilir olamamakla beraber motivasyon kaybı ya da bilinmeyen konulara dair bazen obsesif bir yaklaşıma neden olabilmektedir. Bu sebepten mütevellit bu yazımı Türkçe olarak yazıp yayınlamak istedim.Hiç merak etmeyin, backend ile alakalı tüm karanlık noktalara ışık tutacağız…
Bahse konu olacak bilgileri internetten (İngilizce kaynaklardan) ulaşıp kendimce özümsedikten sonra alıntılar yaparak ve bildiklerimle harmanlayarak size şu başlıklar altında toplamaya çalışacağım:
- Backend Programlama Dilleri
- Backend Web Frameworks (Arka Uç Web Çatıları)
- Databases (Veritabanları)
- APIs (Application Programming Interface)-(Uygulama Programlama Arayüzü)
- REST APIs (Representational State Transfer)-(Temsili Durum Transferi)
- Cloud Computing (Bulut Bilişim)
Frontend vs Backend
Biz girdiğimiz her web sayfasını frontend ve backend olarak iki istisnai bölüme ayırabiliriz.
Basitçe, frontend bizim sitedeki gördüğümüz tüm görsel öğeler ile ilgili olup, backend ise işin veriyi işleyip kayıt eden ve yöneten kısmı ile ilgilenir.
Örnek olarak Amazon’u vereceğim.
Amazon’ da yaptığımız alışveriş sonucunda satın alma geçmişi, oluşturduğumuz profilimiz ve arama sonuçlarımız ve buna benzer diğer veriler backend tarafından kaydedilir ve yönetilir. Şimdi bu konuyu daha detaylıca ele alalım…
Server (Sunucu) Nedir?
Yine Amazon örneğinden devam edelim. Varsayalım ki siz Amazondan ürünü satın al butonuna bastınız. Bu esnada arka planda sizce nasıl bir işlemler silsilesi meydana geliyor?
İnternete bağlı herhangi bir bilgisayar, yine internete bağlı herhangi bir bilgisayara internet üzerinden veri gönderebilir. Şimdi bunu yukarıdaki örneğimize uyarladığımızda, biz Amazonda satın al butonuna bastığımızda aslında bilgisayarımızdan Amazon’un ofisindeki herhangi bir bilgisayara siparişimizi internet üzerinden veri olarak yolluyoruz.
İşte tam bu durumda bizim bilgisayarımız “Client (İstemci)”, Amazon’un ofisindeki bilgisayar ise “Server (Sunucu)” oluyor. Peki bu durum olmadan önce bilgisayarlar nasıl veri alabiliyor ve o veriyi işleyebiliyor? Her bilgisayar varsayılan olarak internet üzerinden gelen veriyi hemen öylece alıp işleyemez. Bunun gerçekleşmesi için bazı koşulların sağlanması lazım.İlk olarak bu bilgisayarı buna göre programlamamız gerek, peki ama nasıl? Backend Programming Languages (Arka Uç Programlama Dilleri) burada devreye giriyor.
Backend Programming Languages (Arka Uç Programlama Dilleri)
Dediğimiz üzre bilgisayarımızı bir server’a yani bir sunucuya dönüştürmek için bazı programlama dillerine ihtiyacımız var. Bunlardan popüler olanlarını aşağıdaki resimde görebilirsiniz.
Lakin bu işi sadece bu programlama dillerini yalın olarak kullanarak yapmak zor ve meşakkatli olmakla beraber tonlarca satır kod yazmamızı da gerektirir. Debug etmeyi komplike bir hale getirmekle beraber, hata ayıklamak veya tespit etmek bir hayli zaman alır, hatta bazen işler içinden çıkılamaz hale bile gelebilir. İşte bu sorunun önüne geçmek için tamda burda önemli 2 adet tool devreye girer. Bunlardan ilki Backend Framework (Arka Uç Yazılım İskeleti), ikincisi ise Package Manager (Paket Yöneticisi)’dır.
Backend Framework (Arka Uç Yazılım İskeleti)
Backend Framework’lerini kullanarak server(sunucu)’ımızı daha hızlı ve daha az satır kod yazarak güvenlice oluşturabiliriz. Her Programlama Dili’nin kendine has Backend Framework’ü bulunur. Bunlardan herhangi birini tercih ederek hepsinin farklı şekilde ama aslında aynı işi yaptığını ön görerek bu yola devam edebilirsiniz. Bu Framework’lerden sıkça kullanılanlar aşağıdaki fotoğraftaki gibidir.
Packages (Paketler)
Backend tarafında kodlama yaparken biz aslında arka planda başkalarınında yazdığı ya da hali hazırda kalıplaşmış bir çok kodu da kullanıyoruz, kendi kodlarımıza bir şekilde dahil ediyoruz ve buna paketler diyoruz.
Bu bağlamda ortak olan tüm görevleri yerine getirirken, hesaplama, veritabanı ile iletişim kurma, login ve authentication işlemlerinde paketlerden yardım alıyoruz. Bu paketlere nerden ulaşıyoruz ve bilgisayarımıza kuruyoruz? Bunu package manager (paket yöneticisi) sayesinde yapıyoruz. Backend gibi her programlama dilinin kendine özgü package managerları bulunur. Örneğin Javascript için NPM, Python için pip, Ruby için bundler ve Java için ise Maven.
Kendi backend server’ımızı kurmamız için gereken tüm teknolojileri gördük ve bunları genel olarak şöyle sıralayabiliriz. Bundan sonraki kısımlarda Türkçe anlamlandırdığımız kısımları kafamızda kalması ve dilimize de pelesenk olması açısından İngilizce yazarak devam edeceğim.
- Backend Programming Language
- Backend Framework
- Package Manager
Bu aşamalardan sonra karşılaşacağımız problem ise websitemizdeki verileri nereye ve nasıl depolayacağımız olacaktır.
Database (Veritabanı)
Veriden (data) kastımız yine Amazon’ dan örnek vermek gerekirse; kullanıcıya ait olan giriş bilgileri, sipariş geçmişi ve durumu, sitede bulunan ve satılan tüm ürünlerden, ürünlere ait olan yorumlardan, açıklamalardan ve puanlamasından ibarettir.
Bu tarz verileri saklayıp yönetmek için elzem olan yegâne şey bir database’ dir. Bunu başka bir bilgisayarda çalışan bir yazılım parçacığı olarak düşünebilirsiniz.
Şimdi ise backend server’ ımızın database ile iletişime geçmesini sağlamamız gerek. Bundan önce size popüler olarak kullanılan bazı database örneklerini aşağıdaki resimde göstermek istiyorum.
Database’ lerde kendi aralarında sınıflandırılmıştır. Bunlar RDBMS ve DBMS olarak iki kategoriye ayrılır. Yani Relational Database Management Systems (İlişkisel Veri Tabanı Yönetim Sistemleri) ve Database Management Systems (İlişkisel Olmayan Veri Tabanı Yönetim Sistemleri). RDBMS örnek olarak MySQL, PostgreSQL DBMS örnek olarak NoSQL olarak da bilinen MongoDB örnek verebiliriz. Bu konuyla ilgili daha detaylı bir makaleyi ayrı olarak yazacağım. Şimdilik bu kadarını bilmemiz yeterli.
Request-Response Cycle (İstek-Cevap Döngüsü)
Biraz önce database ile iletişimin nasıl olacağına değinmemiş ve database çeşitleri ve sınıflarından birkaç örnek vermiştik. Başlıktan da anlaşılacağı üzere bu konuyu client’ dan gönderilen request’ e dönülen response döngüsü altında inceleyip, açığa kavuşturacağız.
Yukarıdaki resme bakıp Amazon örneğini zihninizde canlandırın. Frontend üzerinden sipariş detaylarını oluşturup, backend’ e gönderdiğimizi varsayalım. Backend bu durumda siparişi database’ e kaydeder ve siparişin başarı ile oluştuğuna dair frontend’ e mesaj gönderir. Burada önemli olan şey; frontend tarafından backend’ e yollanan mesajın (sipariş) request, backend tarafından geri frontend kısmına yollanan mesajın (‘sipariş başarı ile oluşturuldu’) response olduğunu unutmamak… Ve böylece tekrar eden bu yapıya da request-response cycle denir. Genel olarak tüm Web Applications’ lar böyle çalışır. (Web Uygulamaları)
Web Apps demişken… Bir Web Sitesi ve Web Uygulaması (Web Application) arasındaki fark nedir, velev ki biz bir siteye girdiğimizde bunun bir Websitesi mi yoksa bir Web App mi olduğunu nasıl anlarız ?
Aslında çok basit, konumuzla da alakalı olarak aleni bir şekilde anlayabiliriz. Bir websitesi verileri database’ e kaydetmez, o verileri herhangi bir şekilde yönetmez veya manipüle edemez. Peki ama bir Web App bu durumda nasıl davranır? Verileri kaydeder ve işleyip yönetebilir. Kısacası bir websitesinde şu 3 öğeden en az biri varsa bu onu bir Web App yapar:
- Authentication (Kimlik Doğrulama İşlemi)
- Integration (Entegrasyon)
- Interaction (Etkileşim)
Bu maddelerin de detaylarına girip konuyu dağıtmadan devam edelim, zira bu kadarını bile bilmek sizi karşı karşıya kaldığınız bu teknolojiyi daha verimli bir şekilde anlayıp kullanmanız için pek âlâ yeterli olacaktır.
Peki bu client tarafından frontend kullanılarak gönderilen request sadece bir sipariş oluşturma mesajından mı ibarettir? Eğer öyle ise nasıl bir yapıda olup backend’ imiz tarafından anlaşılır ve database’ e işlenir? Gelin bir sonraki başlığımızda bunu etraflıca inceleyelim.
API (Application Programming Interface-Uygulama Programlama Arayüzü)
Bu kısımda biraz daha derinlere inip request’ in içinde neler olduğuna ve yapısına bakalım. Amazon örneğindeki sipariş detaylarının request’ ini inceleyelim.
Yukarıdaki resme dikkatlice baktığımızda aslında kolayca anlaşılan bir yapıda olduğunu, siparişimizle ilgili nasıl bilgilere sahip olduğunu ve ödeme ve adres kısımlarını kolayca anlayabilirsiniz.
En üstte yer alan POST https://amazon.com/orders ise POST kısmının request’ imizin tipi, devamında yer alan amazon.com domain adı, /orders kısmının ise URL path (Uniform Resource Locator) olduğunu ve bu request’ in nereye gittiğini görüyoruz. Burada dikkat etmemiz gereken iki yer var:
1- Request Type ( İstek Tipi)
2- URL Path (URL Yolu)
Bu örneğimizde gördüğümüz gibi bu /orders kısmına yapılan bir POST Request’ tir. Backend tarafında yaptığımız kodlamalar sayesinde biz bu requestler ile nasıl başa çıkacağımızı ve hangi tip requestlere izin vereceğimizi belirtip programlayabiliriz.
Örneğin /orders kısmına yapılacak bir POST request’ e izin verirsek bu path’ e gelen POST requesti (bu durumda siparişi) programlama dilimizi kullanarak database’ imize kaydedebiliriz.
Ya da aynı URL path’ e ( /orders ) yapılacak GET request’ e izin verirsek bu sefer database’ imize işleyip kayıt ettiğimiz data’ yı bu GET request’ e karşılık Response olarak geri döndürmemiz gerekir.
Aynı URL path’ e DELETE request’ de gelebilir. Bu durumda database’ e kayıtlı sipariş verisi silinerek sipariş iptal edilir.
Bu farklı tiplerdeki backend tarafından izin verilen request çeşitlerinden oluşan listeye API denir ve Backend Programming kısmının bel kemiğini oluşturup en önemli ve en çetrefilli konseptlerinden bir tanesidir.
Bu arada bir URL Path’ e API tarafından izin verilmeyen bir request gönderirsek, backend tarafı bir hata dönecektir.
REST API
API’ lar hakkında yüzeysel olsa da biraz bilgi sahibi olduğumuzu varsayıyorum.
REST mimarisine gelecek olursak, evet mimari dedim çünkü REST dağıtık sistemler tasarlamak için kullanılan bir mimari tarzdır ki client-server arasındaki haberleşmeyi HTTP protokolü üzerinden yapar.
REST, web servis yönelimli mimari üzerine oluşturulan ve yazılımlar arası veri aktarımını sağlayarak uygulamaların birbirleri ile haberleşmesini de sağlar.
Aktarılan verinin formatı HTML, JSON, XML ya da farklı bir tipte olabilir. REST, bu konuda bir kısıtlama getirmez. Aktarılan verinin tipi ve özellikleri istemci ve sunucu tarafından HTTP protokolünde yer alan İngilizce: content-type (içerik tipi) ve benzeri metaveri ile tanımlanır.
Bu mimariyi kullanan API’ lara ise REST API denilir veya hiçbir farkı olmayan, REST içerisinde yer alan kısıtlamalara uyan API manasına gelen RESTful API da denilebilir.
Create -> POST Request -> NOT Idempotent
Read -> GET Request -> Idempotent
Update -> PUT Request -> Idempotent
Delete -> Delete Request -> Idempotent
Endpoint yani URL Path’ lere yapacağımız request tipine göre bu HTTP metodlarından hangisinin birden fazla kez tekrarlanırsa sonucunun aynı olduğunu (idempotent) veya olmadığını ( not idempotent) öngörebiliriz.
Resimdeki Amazon örneğinde gördüğünüz üzere https://amazon.com websitesinin /orders endpoint’ ine bir idempotent olmayan request gönderiliyor yani tarafımızdan belirlenen sipariş detayları ile oluşturulan veri, veri tabanına kaydediliyor ve bunun karşılığında bize bu durumun başarı ile veya başarısız bir şekilde sonuçlandığına dair bir durum kodu (HTTP Status Code) içeren mesaj response ediliyor.
Bu kodları ve anlamlarını kısaca şöyle genelleyebiliriz.
- 1XX ile başlayan kodlar bilgi amaçlı kodlardır. (INFORMAL)
- 2XX ile başlayan kodlar başarı kodlarıdır. (SUCCESS)
- 3XX ile başlayan kodlar yönlendirme kodlarıdır. (REDIRECTION)
- 4XX ile başlayan kodlar ise client (istemci) hatası kodlarıdır. (CLIENT ERROR)
- 5XX ile başlayan kodlar ise server( sunucu) hatası kodlarıdır. (SERVER ERROR)
Infrastructure (Altyapı)
Günümüzde şirketler kendi bilgisayarlarını satın alıp websitelerini bu bilgisayarlarda çalıştırmak yerine bulut bilişim şirketlerinden (Cloud Computing) bu bilgisayarları kiralayarak bu işlevi yerine getiriyorlar.
Bu Cloud Computing Companies’ lerden en büyükleri ve en çok bilinenleri şu şekilde :
Cloud Computing’ in temel anlayışını bu şirketlerden kiralayabileceğimiz altyapıların bütünü yani IaaS ( Infrastucture as a Service-Servis olarak Altyapı) diye de bilmemizde fayda var.
AWS’ i örnek alacak olursak, perde arkasında AWS çok güçlü ve büyük bir bilgisayara sahiptir ve bu bilgisayarın içerisinde bir software, bu software içerisinde birden fazla daha küçük bilgisayarlar vardır ve biz aslında bunlardan birini kiralarız. Bu bilgisayarlar bir software içerisinde olduğu için biz bunlara VM (Virtual Machine — Sanal Makine) deriz.
Büyük resme bu perspektiften bakacak olursak bu sefer olanları şöyle izah edebiliriz:
Cloud Computing Şirketinden backend’ imizi barındırmak için bir VM ve database’ imiz için bir VM satın alıp websitemizi burada çalıştırabiliriz. Ancak bizim websitemizin popüleritesi artar ve yoğun bir trafik çekmeye başlarsa işte o zaman server’ ımız requestlerle başa çıkamaz hale gelir.
Bu durumda Cloud Computing üzerinde aynı backend kodumuzu birden fazla VM içerisinde run edebiliriz ve bu VM’ lerin önüne daha özel bir VM set edebilir (Load Balancer-Yük Dengeleyici) ve bunun üzerinden gelen tüm requestleri eşit bir şekilde backend kodumuzu barındıran VM lerimize dağıtabiliriz.
Yoğunluğun azalma durumuna göre VM sayımızı istersek tekrar bir adet ile sınırlı tutup aksi durumda tekrar arttırabiliriz. Bu durum bize fiziki olarak bilgisayarlar satın almaktan ziyade Cloud Computing ile bu sorunun birkaç tıklama ve ayar ile çözüleceğinin aleni ispatıdır. Lakin bir sorunumuz daha var…
PaaS (Platform as a Service — Platform olarak Altyapı)
Her seferinde sayısı daha da artabilen ve yoğunluk geçtiğinde azalan VM’leri set etmek, fiziki makinalar satın alıp kurmaktan daha basit olsada bu işlemde fazla zaman ve özveri ister. İşte burda PaaS devreye girerek bu duruma çare olur.
PaaS bize backend kodumuzu kendine yüklememize izin vererek LB (Load Balancer — Yük Dengeleyicisi) dahil tüm VM leri kendisi kurarak set eder ve gerekli tüm entegrasyonları kendisi yapar. Yine size 3 adet popüler PaaS hizmeti veren şirketleri aşağıdaki resimde isimleri ile sıralayayım:
Microservices (Mikroservisler)
Konuyu Amazon örneğimiz ile ve birkaç görsel ile açıklayayım.
Bildiğimiz gibi bu örnekte, backend’ imiz içinde bulunan kodlar sayesinde siparişi database’ e kaydediyor, kredi kartı üzerinden ödeme işlemini alıyor ve siparişin başarı ile oluşturulduğuna ya da doğrulamaya ilişkin e-mail atabiliyordu. Gerçek hayatta böyle bir projeyi oluşturup, idame edebilmemiz için milyonlarca kod satırı gerekebilir. Bu tarz bir projeyi daha birbirinden bağımsız, amacına odaklı ve modüler olarak ayırabilir, işleri daha da kolaylaştırabiliriz.Biz bu projeyi temelde 3 gruba ayırıp kodları (codebase) toparlayabiliriz.
Her codebase’ imiz kendine ait bir backend server, load balancer ve bazen database’ den oluşabilir. Kendi backendimizi böyle ayrı backend’ lere bölerek aslında biz Mikroservis’ imizi oluşturmuş oluyoruz.
Böylece codebase’ imizi daha modüler, küçük ve sadece kendi işine fokuslanacak şekilde ayırmış oluyoruz ve en önemlisi her codebase kendine ait farklı programlama dili ve farklı veritabanı kullanabiliyor. Birisi backend için JavaScript, database için MongoDB kullanırken diğeri Python ve MySQL kullanabilir.
SaaS (Software as a Service-Yazılım olarak Altyapı)
Yukarıdaki Mikroservis örneğini modüler olarak amacına odaklı bir şekilde ayırdıktan sonra bazı adımları istersek daha da kolaylaştırabiliriz. Bu tarz otomatize hazır hizmetler veren binlerce şirketten birisi olan Twilio bize tekerleği yeniden icat ettirmiyor. Yani daha Twilio tarafından zaten inşa edilmiş hali hazırda olan bir e-mail servisi.
Twilio mail gönderimi için bir backend ve API desteği sağlar. Dediğimiz gibi bizim e-mail mikroservisi kurmamız yerine Twilio’ u kullanabiliriz. Böylelikle kendi backendimiz Twilio’ nun backendine bir request gönderir.
Ne zaman bir şirket bizim için ve dışarıdaki herhangi bir uygulama için bir backend ve bir API hizmeti sağlayabiliyorsa biz buna SaaS (Software as a Service-Yazılım olarak Altyapı veya Hizmet olarak Yazılım) deriz.
Eğer mikroservis olarak ayırdığımız bir backendin kodlaması ve değişikliklerin implemente edilmesi karmaşık bir hal alıyorsa ya da zamandan kazanmak istiyorsak işte o zaman şunu bilmekte fayda var. Dışarıda bir yerde zaten bizim için bu işi yapabilecek bir SaaS var.
Bu konuyuda gördükten sonra Cloud Computing (Bulut Bilişim) üzerine şunu rahatlıkla söyleyebiliriz. Cloud Computing 3 temel yapı taşı üzerine inşa edilmiştir ve siz bunları biliyorsunuz…
Bu günlerde çoğu firma veya şirket fiziki server satın alıp yönetmek yerine Cloud Computing altyapısını kendi sistemlerine entegre olarak kullanarak backendlerini burada çalıştırıyorlar.
İlave Teknolojiler (Backend Tarafı)
Bu başlık altında backend kısmında görmeniz muhtemel başka konulara da dokunacağız. Veritabanı kısmında da bahsettiğimiz MySQL, PostgreSQL ve MongoDB gibi veritabanlarına bazen primary database de denildiğine şahit olabilirsiniz. Bu sizi yanıltmasın çünkü burda söylenmek istenen şey bu veritabanının web uygulamamızın kullandığı ana veritabanı olduğunu belirtmektir. Genel olarak biz bir backendimizi server ve primary database olarak oluşturabiliyor ve ihtiyacımız varsa ilave teknolojileri de entegre edebiliyorduk.
Eğer biz backendimizde kullanıcıya database’ imize fotoğraf upload etmesine izin vermiş isek primary database’ imiz fotoğraf saklamak için iyi bir seçenek olmayabilir. Bunun yerine Blob Storage (AWS S3) veya CDN (Content Delivery Network — AWS Cloudfront) kullanarak bu işlemi daha yüksüz ve hızlı halde çözüme kavuşturabiliriz.
Ve biz backendimizde kullanıcıya Text Search (metin arama) izni vermiş isek yine primary database’ imiz buna tam manası ile uygun değildir. Amacımız hız ise bu işlem için biçilmiş bir kaftan vardır. Elasticsearch.
Varsayalım ki sitemiz üzerinde çok fazla trafik var ve biz bu stresi ve yükü primary database’ imiz üzerinden azaltmak istiyorsak bir Cache mekanizması ekleyebiliriz. Burda devreye Redis giriyor.
Eğer Data Science testleri yapmak istiyorsak bu durumda data analizini kendi primary database’ imiz üzerinden yapmak istemeyiz. Çünkü bu database bizim hali hazırda olan sitemizi yürütmekle yükümlüdür. İşte bu durumda biz data science testleri için çok uygun olan Snowflake (Analytical Database) kullanarak bu işlemi rahatça gerçekleştirebiliriz.
Eğer bir görevi zamanlamak istersek; örneğin Amazon üyeliği bitmeye yaklaşan kullanıcılara e-mail atmak gibi bir işi belli bir zamana uygun olarak gelecekte execute etmek için bir job queue olan RabbitMQ kullanabiliriz.
Bu gibi teknolojilere benzeyen, belli bir sorunu çözmek için geliştirilmiş binlerce teknoloji oralarda biryerlerde keşfedilmeyi beklerken, bunların herbirini tek tek öğrenmek yerine sistemi anlayıp büyük fotoğrafa bakmak bizim için herşeyi daha karmaşık halden kolay hale getirecektir.
Buraya kadar sabırlıca okuyup, uzaktan bakıldığında belki zor gözüken bu konu ile ilgili az da olsa bilgi sahibi olabildiyseniz emeğinize sağlık, bu yazı amacına ulaşmış demektir.
Başka yazılarımda görüşmek üzere hoşça kalın…
Unutmayın, destek vermek isterseniz 50 kez alkış butonuna basabilirsiniz. Teşekkürler…
