İnternetin Təkamülü və Müasir Tətbiqlərin Təməl Daşları — Web 1.0-dan Kvant Hesablamalarına Doğru

İnternetin Təkamülü və Müasir Tətbiqlərin Təməl Daşları: Web 1.0-dan Kvant Hesablamalarına Doğru

Salam, kod dünyasının cəngavərləri! Bu gün sıradan bir mövzuya toxunmayacağıq. Çayınızı və ya qəhvənizi hazırlayın, çünki bu gün bizi bura gətirən yolun, yəni İnternetin təkamülünün dərinliklərinə baş vuracağıq. Statik HTML səhifələrindən tutmuş, bu gün qarşılıqlı əlaqədə olduğumuz mürəkkəb, real-time tətbiqlərə qədər uzanan bu səyahət, müasir proqramlaşdırmanın təməl prinsiplərini anlamaq üçün kritik əhəmiyyət kəsb edir. Hazırsınızsa, başlayaq!

Web 1.0-dan Web 3.0-a Keçid: Statik, Dinamik və Semantik Veb

İnternetin həyatımıza daxil olduğu ilk günləri xatırlayanlar (və ya bu barədə oxuyanlar) bilir ki, hər şey çox fərqli idi. Bu təkamülü 3 əsas mərhələyə bölmək olar:

Web 1.0: "Read-Only" Veb (Təxminən 1991-2004)

Xarakteristikası: Əsasən statik HTML səhifələrindən ibarət idi. Məzmun yaradıcıları az, istehlakçıları isə çox idi. Veb saytlar daha çox rəqəmsal broşuralara bənzəyirdi.
Texnologiyalar: Sadə HTML, bəsit CSS, <table> əsaslı layoutlar. Server tərəfində CGI (Common Gateway Interface) scriptləri istifadə olunsa da, dinamiklik çox məhdud idi.
İstifadəçi Təcrübəsi: İnteraktivlik demək olar ki, yox idi. İstifadəçilər əsasən məlumat oxuyurdular. "Guestbook"lar və sadə formalar ilk interaktivlik cəhdləri idi.
Nəticə: İnformasiyaya çıxış imkanı yarandı, amma birtərəfli idi. Biz buna informasiya magistralının ilkin dövrü deyə bilərik.

Web 2.0: İnteraktiv və Sosial Veb (Təxminən 2004-cü ildən bu günə)

Xarakteristikası: İstifadəçi tərəfindən yaradılan məzmun (User-Generated Content), sosial şəbəkələr, bloglar, vikilər ön plana çıxdı. Veb tətbiqləri (Web Applications) masaüstü tətbiqləri ilə rəqabət aparmağa başladı.
Texnologiyalar: Dinamik HTML (DHTML), JavaScript frameworkləri (jQuery, sonra Angular, React, Vue), AJAX (Asynchronous JavaScript and XML) sayəsində səhifəni yeniləmədən serverlə əlaqə, güclü backend dilləri (PHP, Python, Ruby, Java, Node.js) və frameworklər (Laravel, Django, Rails, Spring, Express), Rich Internet Applications (RIA).
İstifadəçi Təcrübəsi: Veb "oxumaq"la yanaşı, "yazmaq" və "paylaşmaq" platformasına çevrildi. İnteraktivlik və real-time kommunikasiya normaya çevrildi.
Nəticə: Veb sosiallaşdı, dinamikləşdi və tətbiq platformasına çevrildi. Biz indi də əsasən Web 2.0 dövrünün yetkin mərhələsində yaşayırıq.

Web 3.0: Semantik və Mərkəzləşdirilməmiş Veb (İnkişaf etməkdədir)

Xarakteristikası: Məlumatların maşınlar tərəfindən daha yaxşı anlaşılması (Semantic Web), süni intellekt (AI) və maşın öyrənməsi (ML) inteqrasiyası, mərkəzləşdirilməmiş texnologiyalar (Blockchain, dApps - Decentralized Applications), Əşyaların İnterneti (IoT) ilə sıx inteqrasiya.
Texnologiyalar: Blockchain platformaları (Ethereum, Solana), Smart Contracts, IPFS (InterPlanetary File System), AI/ML alqoritmləri, GraphQL (daha çevik data sorğuları üçün), VR/AR texnologiyaları.
İstifadəçi Təcrübəsi: Daha fərdiləşdirilmiş, ağıllı və kontekstə uyğun təcrübələr. Verilənlər üzərində daha çox nəzarət və şəffaflıq (idealda). Fiziki və rəqəmsal dünyaların qovuşması.
Nəticə: Veb daha "ağıllı", mərkəzləşdirilməmiş və immersiv olmağa doğru gedir. Bu, hələ tam formalaşmamış, lakin potensialı böyük bir dövrdür.

Web Versiyalarının Müqayisəsi

Xüsusiyyət	Web 1.0	Web 2.0	Web 3.0 (Gözlənilən)
Əsas Fokus	Məlumat Yayımı	İnteraktivlik, Sosiallaşma	Semantika, Mərkəzsizləşmə, Zəka
Məzmun Yaradıcısı	Az sayda vebmasterlar	Hər kəs (Bloglar, Sosial Media)	AI, İstifadəçılar, Mərkəzsiz Şəbəkələr
Əsas Texnologiya	HTML, HTTP	JavaScript, AJAX, Backend Frameworks	Blockchain, AI/ML, Semantic Tech
Arxitektura	Client-Server (Sadə)	Client-Server (Mürəkkəb), API-lər	Peer-to-Peer (P2P), Mərkəzsiz
Verilənlər	Statik, Strukturlaşmamış	Dinamik, İstifadəçi Mərkəzli	Bağlı (Linked), Semantik, Portativ

HTTP-nin Vətəndaşlığı Olmayan Strukturu (Statelessness) və Müasir Təhlil Strategiyaları

Webin əsas daşıyıcı protokolu olan HTTP (Hypertext Transfer Protocol), dizayn etibarilə stateless, yəni "vətəndaşlığı olmayan" bir protokoldur.

HTTP: The Stateless Protocol

Bu nə deməkdir? Hər bir HTTP request (istək) əvvəlki və ya sonrakı istəklərdən tamamilə müstəqildir. Server hər istəyi heç bir kontekst olmadan, sanki ilk dəfə gəlirmiş kimi qəbul edir və emal edir. Əvvəlki istəkdə kim olduğunuzu və ya nə etdiyinizi "xatırlamır".

Niyə Stateless?

Sadəlik: Protokolun dizaynını və implementasiyasını asanlaşdırır.
Scalability: Serverlər hər hansı bir istəyi emal edə bilər, çünki istəklər arasında session state saxlamaq məcburiyyəti yoxdur. Bu, load balancing və sistemin üfüqi genişlənməsini (horizontal scaling) çox asanlaşdırır. Düşünün, əgər hər server hər istifadəçinin vəziyyətini yadda saxlamalı olsaydı, bu nə qədər mürəkkəblik yaradardı.

➡️ State Management Strategiyaları

Bəs biz necə olur ki, saytlara login ola bilir, səbətimizdə məhsulları saxlaya bilirik? Çünki stateless HTTP üzərində stateful (vəziyyəti yadda saxlayan) təcrübələr qurmaq üçün müxtəlif strategiyalar istifadə edirik:

Cookies: Server tərəfindən brauzerə göndərilən kiçik məlumat parçalarıdır. Brauzer sonrakı hər istəkdə bu cookie-ləri serverə geri göndərir. Session ID-lərini saxlamaq üçün geniş istifadə olunur.
Server-side Sessions: Server hər bir istifadəçi üçün unikal bir Session ID yaradır (adətən cookie ilə göndərilir) və istifadəçiyə aid məlumatları (məsələn, login statusu, səbət məlumatı) serverdə bu ID ilə əlaqəli bir yerdə (yaddaş, database, cache) saxlayır.
Tokens (xüsusilə JWT - JSON Web Tokens): Stateless autentifikasiya üçün populyar metod. Login zamanı server istifadəçiyə imzalanmış bir token verir. Client sonrakı hər qorunan istəkdə bu token-i (adətən Authorization header-ində) göndərir. Server token-in imzasını yoxlayaraq istifadəçini tanıyır və session məlumatını serverdə saxlamağa ehtiyac qalmır. Bu, xüsusilə microservices arxitekturaları üçün əlverişlidir.
Client-side Storage (localStorage, sessionStorage): Brauzerin təqdim etdiyi yaddaş sahələridir. Qeyri-həssas məlumatları (UI state, bəzi preferences) saxlamaq üçün istifadə edilə bilər. localStorage brauzer bağlanıb açılanda belə qalır, sessionStorage isə tab bağlananda silinir.

⚠️ Unutmayın ki, hər strategiyanın öz üstünlükləri, çatışmazlıqları və təhlükəsizlik aspektləri var. Seçim, tətbiqin tələblərinə və arxitekturasına görə dəyişir.

Müştəri-Server Arxitekturası (Client-Server), REST və RPC Modelləri

Müasir veb tətbiqlərinin böyük əksəriyyəti Client-Server arxitekturasına əsaslanır.

Client-Server Modeli: Əsaslar

Client (Müştəri): Resursları tələb edən tərəfdir. Adətən istifadəçinin qarşılıqlı əlaqədə olduğu interfeysdir (veb brauzer, mobil tətbiq, masaüstü proqram). Məsuliyyəti: İstifadəçi interfeysi, istək göndərmək, cavabı emal etmək.
Server: Resursları təmin edən və ya xidmətləri təqdim edən tərəfdir. Arxada işləyən güclü kompüterlər və proqram təminatıdır. Məsuliyyəti: İstəkləri qəbul etmək, biznes məntiqini icra etmək, verilənlər bazası ilə əlaqə qurmaq, cavab hazırlamaq və göndərmək.
Bu model, məsuliyyətlərin bölünməsinə (separation of concerns) imkan verir, scalability və idarəetməni asanlaşdırır.

Client və Server arasında əlaqəni təşkil etmək üçün müxtəlif kommunikasiya modelləri mövcuddur. Ən populyarları REST və RPC-dir.

REST (Representational State Transfer)

Bu, bir arxitektura stilidir, protokol deyil. Vebin özünün işləmə prinsipinə (HTTP) çox yaxındır.

Əsas Prinsiplər:
- Stateless: Hər istək müstəqildir (HTTP-nin stateless təbiətini miras alır).
- Client-Server: Məsuliyyətlər aydın şəkildə ayrılıb.
- Cacheable: Cavablar cache-lənə bilər olmalıdır.
- Uniform Interface: Ən vacib prinsipdir. Resursların standart şəkildə (URI vasitəsilə) identifikasiyası, resurslarla manipulyasiya üçün standart HTTP metodlarının (GET, POST, PUT, DELETE, PATCH) istifadəsi, cavabların özünü təsvir edən (self-descriptive) olması (məsələn, Content-Type header-i) və HATEOAS (Hypermedia as the Engine of Application State - cavabların növbəti mümkün addımları göstərən linklər ehtiva etməsi) kimi alt prinsipləri var.
- Layered System: Arxitektura qatlı ola bilər (proxy, load balancer və s.), client birbaşa end server ilə danışdığını bilməyə bilər.
Fokus: Resurslar (/users, /products/123) və onlarla edilən əməliyyatlar (HTTP methods).

RPC (Remote Procedure Call)

Daha köhnə, lakin hələ də aktual olan bir modeldir.

Əsas İdeya: Bir şəbəkə üzərindəki başqa bir kompüterdə (serverdə) olan bir funksiyanı (proseduru) sanki lokal olaraq çağırırsınız.
Fokus: Əməliyyatlar, funksiya çağırışları (getUser(userId: 123), createOrder(items: [...])).
Implementasiyalar:
- XML-RPC, JSON-RPC: Sadə formatlar üzərində qurulub.
- gRPC (Google RPC): Müasir, yüksək performanslı RPC framework-üdür. HTTP/2, Protocol Buffers (effektiv serialization formatı) istifadə edir. Xüsusilə microservices arasında sürətli və effektiv əlaqə üçün çox populyardır.

REST vs. RPC Müqayisəsi

Xüsusiyyət	REST	RPC (xüsusilə gRPC)
Əsas Konsept	Resurslar (Nouns)	Əməliyyatlar/Funksiyalar (Verbs)
Protokol	Adətən HTTP/1.1, HTTP/2 üzərində	Müxtəlif (TCP, HTTP/2 - gRPC)
Data Formatı	Çox vaxt JSON, həmçinin XML, HTML, text...	Binary (Protocol Buffers - gRPC), JSON, XML
Standart Metodlar	`GET`, `POST`, `PUT`, `DELETE`, `PATCH`...	Metodlar API tərəfindən təyin edilir
Caching	HTTP caching mexanizmlərindən yararlanır	Daha mürəkkəb, standart deyil
Interface Definition	OpenAPI/Swagger (populyar, amma tələb deyil)	IDL (.proto faylları - gRPC üçün)
Əsas İstifadə Sahəsi	Public API-lər, Veb tətbiqləri, Sadə Microservices	Daxili Microservice kommunikasiyası, Yüksək performans tələb edən sistemlər

💡 Nə Zaman Hansını Seçməli?

Əgər standart CRUD (Create, Read, Update, Delete) əməliyyatları ilə işləyən, brauzerlər və müxtəlif client-lər tərəfindən asanlıqla istifadə edilə bilən, caching-dən faydalanan bir API lazımdırsa, REST adətən yaxşı seçimdir. Public API-lər üçün demək olar ki, standartdır.
Əgər microservices arasında aşağı gecikməli (low latency), yüksək sürətli (high throughput) əlaqəyə ehtiyac varsa, əməliyyatlar daha mürəkkəb və resurs-yönümlü deyilsə, gRPC (müasir RPC implementasiyası kimi) daha effektiv ola bilər. Streaming (bidirectional streaming) kimi xüsusiyyətləri də güclü tərəfidir.

Veb Serverlər: Apache, Nginx, Tomcat

Client-dən gələn HTTP istəklərini qarşılayan və cavablandıran əsas komponentlərdən biri də veb serverdir. Ən populyar veb serverlərdən bəzilərinə nəzər salaq:

Veb Serverin Rolu:

HTTP(S) istəklərini qəbul etmək və emal etmək.
Statik faylları (HTML, CSS, JS, şəkillər) birbaşa təqdim etmək.
Dinamik məzmun tələb olunduqda, istəyi application server-ə (məsələn, PHP-FPM, Gunicorn, uWSGI, Tomcat) yönləndirmək və cavabı client-ə ötürmək.
Reverse Proxy kimi fəaliyyət göstərmək (istəkləri arxadakı serverlərə yönləndirmək).
Load Balancing (yükü bir neçə server arasında bölüşdürmək).
SSL/TLS şifrələməsini idarə etmək (HTTPS).
Caching, compression (gzip/brotli) kimi optimizasiyaları həyata keçirmək.

Apache HTTP Server (httpd):

Uzun müddət ən populyar veb server olub. Çox köklü və geniş sənədləşməyə malikdir.
Ənənəvi olaraq process-based və ya thread-based modeldə işləyir (MPMs - Multi-Processing Modules: prefork, worker, event). Hər connection üçün bir process və ya thread ayırması yüksək yüklənmə altında performans problemləri yarada bilər (C10k problemi).
Konfiqurasiyası çox çevikdir, .htaccess faylları vasitəsilə direktoriyalar üzrə konfiqurasiya imkanı güclü tərəfidir (lakin performans təsiri də ola bilər).
Modul sistemi çox zəngindir.

Nginx:

Performans və scalability məqsədilə yaradılıb. Apache-nin C10k probleminə cavab olaraq meydana çıxıb.
Event-driven, asynchronous, non-blocking arxitekturaya əsaslanır. Az sayda worker process ilə minlərlə connection-ı effektiv şəkildə idarə edə bilir. Bu, yaddaş sərfiyyatını azaldır və yüksək yüklənmə altında daha stabil işləməsini təmin edir.
Statik faylların təqdim edilməsində çox sürətlidir.
Reverse Proxy, Load Balancer və Cache Server kimi funksiyalarda çox güclüdür və geniş istifadə olunur.
Konfiqurasiyası Apache-dən fərqlidir, daha sadə və performans yönümlü hesab edilir. .htaccess dəstəyi yoxdur.

Apache Tomcat:

Tomcat tam olaraq klassik veb server deyil, əsasən bir Java Servlet Container və JavaServer Pages (JSP) implementatorudur. Yəni, Java ilə yazılmış veb tətbiqlərini (Servlets, JSPs) işə salmaq üçün nəzərdə tutulub.
Eyni zamanda sadə HTTP server funksiyalarını da yerinə yetirə bilir (statik faylları təqdim etmək).
Çox vaxt Nginx və ya Apache ilə birlikdə istifadə olunur: Nginx/Apache client-dən gələn istəkləri qəbul edir, statik faylları özü verir, dinamik Java tətbiqi istəklərini isə arxadakı Tomcat server(lər)inə yönləndirir (reverse proxy).
Java ekosistemində çox geniş istifadə olunur.

Veb Serverlərin Müqayisəsi

Xüsusiyyət	Apache HTTP Server	Nginx	Apache Tomcat
Əsas Arxitektura	Process/Thread-based (MPMs)	Event-driven, Asynchronous	Thread-based (Java Threads)
Performans (Yüksək Yük)	Orta (C10k problemi ola bilər)	Yüksək	Orta (Java tətbiqinə bağlı)
Statik Fayl Servisi	Yaxşı	Çox Yüksək	Orta (Əsas işi deyil)
Reverse Proxy/LB	Mümkündür (mod_proxy)	Çox Güclü və Populyar	Mümkündür, amma geniş istifadə edilmir
Konfiqurasiya	Çevik, .htaccess dəstəyi	Sadə, Performanslı, .htaccess yox	XML əsaslı (server.xml, web.xml)
Əsas İstifadə Sahəsi	Hostinq, Çevik Konfiqurasiya	Yüksək Performans, Reverse Proxy, LB	Java Veb Tətbiqləri (Servlet/JSP)

Şirkətlər öz daxili funksionallıqlarını və ya verilənlərini idarə olunan API-lər vasitəsilə xarici developerlərə və ya tərəfdaşlara açırlar.
Bu, yeni biznes modellərinin yaranmasına, innovasiyanın sürətlənməsinə və tətbiqlər arasında dəyərli inteqrasiyaların qurulmasına imkan verir. Stripe (ödəniş), Twilio (kommunikasiya), Google Maps kimi şirkətlər API iqtisadiyyatının güclü nümunələridir. API-lər artıq bir məhsuldur!

BaaS (Backend as a Service):

Mobil və veb tətbiqlərin backend tərəfində təkrarlanan və standartlaşmış funksionallıqları (autentifikasiya, verilənlər bazası, fayl saxlanması, push notifications, cloud functions) hazır xidmətlər şəklində təqdim edən cloud platformalarıdır.
Developerlər bu hazır komponentlərdən istifadə edərək backend infrastrukturunu sıfırdan qurmaq və idarə etmək əvəzinə, daha çox frontend və biznes məntiqinə fokuslana bilirlər.
Nümunələr: Firebase (Google), AWS Amplify, Supabase (Open Source alternativ), Parse, Appwrite.

BaaS: Üstünlüklər və Çatışmazlıqlar

👍 Üstünlüklər:
- Sürətli İnkişaf (Rapid Development): Tətbiqi bazara daha tez çıxarmağa imkan verir.
- Azalan Backend Məsrəfləri: Server idarəetməsi, scaling, təmir kimi məsələlərlə daha az məşğul olursunuz.
- Scalability: Platforma adətən avtomatik scaling təmin edir.
- Hazır Funksionallıq: Autentifikasiya, DB kimi mürəkkəb mövzular üçün hazır həllər.
👎 Çatışmazlıqlar:
- Məhdud Çeviklik: Platformanın təqdim etdiyi imkanlarla məhdudlaşa bilərsiniz. Xüsusi backend məntiqi tələb olunduqda çətinliklər yarana bilər.
- Vendor Lock-in: Bir BaaS platformasından digərinə keçmək çətin və məsrəfli ola bilər.
- Qiymət: Kiçik layihələr üçün sərfəli olsa da, böyük həcmdə istifadə zamanı qiymət arta bilər və proqnozlaşdırmaq çətinləşə bilər.
- Nəzarətin Azlığı: İnfrastruktur və verilənlər üzərində tam nəzarətiniz olmur.

İnternetin Təkamülü və Müasir Tətbiqlərin Təməl Daşları — Web 1.0-dan Kvant Hesablamalarına Doğru