Modern Uygulama MimarisiFramework · API · Sistem Entegrasyonu
Başlangıç
UYGULAMA MİMARİSİ / 2026

ModernUygulamaMimarisi

Framework seçimi, API tasarımı ve sistem entegrasyonu

Bu eğitim; modern web ve servis uygulamalarında kullanılan framework’leri, API iletişim modellerini ve entegrasyon katmanlarını aynı mimari çerçevede ele alır. Teknoloji seçeneklerini ürün gereksinimleriyle ilişkilendirmeyi ve alınan kararları güvenlik, performans, bakım ve işletim ölçütleriyle doğrulamayı öğretir.

SÜRÜM 1.010 DERS30 KAVRAM5 İNTERAKTİF LAB

Kaynak kontrolü: 2 Eylül 2026 · Framework davranışları ve API standartları resmi dokümantasyon üzerinden yeniden doğrulandı.

Derse başla Teknoloji seçici Resmi kaynaklar
MİMARİ AKIŞ / 00UÇTAN UCA SÖZLEŞME
Kullanıcı arayüzüWeb · mobil · masaüstü
İSTEK
Uygulama framework’üYönlendirme · yaşam döngüsü
SÖZLEŞME
API katmanıŞema · yetki · hata modeli
VERİ / OLAY
Uygulama servisleriVeritabanı · kuyruk · dış servis

Kullanıcı isteği framework’ün yaşam döngüsünden geçer; açık bir API sözleşmesiyle veri ve servis katmanlarına güvenli biçimde iletilir.

Framework’ün sorumluluğuUygulama akışını yönetmekYönlendirme, render, veri erişimi ve yaşam döngüsünü ortak düzende yürütür.
API’nin sorumluluğuSistem sınırlarını tanımlamakİstek, yanıt, yetki, hata ve sürüm davranışını açık bir sözleşmeye bağlar.
EĞİTİM PLANI

Kapsam ve öğrenme sırası

Eğitim; temel kavramları tanımlar, framework ve API seçeneklerini karşılaştırır, karar ölçütlerini uygular ve üretime hazır bir entegrasyon süreciyle tamamlanır.

01 / Kavramları ve sorumlulukları tanımlaMİMARİ TEMELLER
KONTROL AKIŞI LABORATUVARI / 01

Kütüphane ve framework arasındaki kontrol farkı

Bu karşılaştırma, yürütme kontrolünün uygulama kodunda mı yoksa framework yaşam döngüsünde mi olduğunu gösterir.

Uygulama koduRoute ve bileşenleri tanımlar
→
FRAMEWORK ÇAĞIRIRLifecycle, render ve veri akışını yürütür
Framework ana yürütme akışını yönetir; uygulama kodu tanımlanan genişletme noktalarında çalışır.KONTROL FRAMEWORK’TE
LIBRARY

Kütüphane

Belirli bir işi yapan araç setidir. Ne zaman ve nasıl çalışacağına uygulama kodu karar verir.

Örnek: veri doğrulama, tarih biçimleme
RUNTIME

Çalışma zamanı

Kodun yürüdüğü ortamdır; dil özelliklerini ve sistem API’lerini sağlar.

Örnek: browser, Node.js, Deno
FRAMEWORK

Uygulama iskeleti

Routing, render, data flow, build ve lifecycle kararlarını bir araya getirir.

Örnek: Next.js, Nuxt, Angular
PLATFORM

İşletim yüzeyi

Dağıtım, ölçekleme, gözlem ve yönetilen servisleri birlikte sunar.

Örnek: cloud ve edge platformları
FRAMEWORK KARŞILAŞTIRMASI / 02

Seçeneklerin kullanım alanları ve teknik sınırları

RESMİ BELGELERLE DOĞRULANDI
NE ZAMAN?

Next.js

React ekibiyle SSR, Server Components, route ve backend-for-frontend yeteneklerini tek ürün çatısında toplamak istediğinizde.

NEDEN?

React ekosistemi, güçlü routing ve farklı render stratejilerini aynı uygulamada kullanabilme.

DİKKAT

Basit bir statik sayfa için gereksiz sunucu ve cache karmaşıklığı oluşturmayın.

Resmi dokümantasyon ↗
Mimari not:

Frontend ve backend framework’leri aynı teknoloji ailesinden seçilmek zorunda değildir. İçerik yüzeyi Astro, ürün paneli Next.js ve yapay zekâ servisi FastAPI ile geliştirilebilir; bu katmanlar açık ve sürümlenebilir API sözleşmeleriyle birbirine bağlanır.

KARAR MATRİSİ / 03

Ürün gereksinimlerine göre başlangıç mimarisi

BAŞLANGIÇ ÖNERİSİ

Next.js + OpenAPI sözleşmesi

React/TypeScript ekibi için ürün yüzeyi, routing ve sunucu tarafı ihtiyaçlarını tek yerde toplar. Dış tüketiciler varsa API sözleşmesini UI’dan ayırın.

Next.js→OpenAPI→PostgreSQL
01

Ürün davranışı

SSR, SEO, offline, realtime, içerik yoğunluğu, cihazlar.

02

Ekip uyumu

Dil, debugging alışkanlığı, işe alım ve ortak sahiplik.

03

Operasyon maliyeti

Hosting modeli, cache, deploy, gözlem ve on-call yükü.

04

Çıkış maliyeti

Framework’e özel kod, veri taşınabilirliği ve sözleşme sınırı.

02 / Sistem sınırlarını sözleşmeyle tanımlaAPI VE ENTEGRASYON
HTTP İSTEK LABORATUVARI / 04

Bir HTTP isteğinin bileşenleri

REQUESTGET /v1/orders/ord_2048Authorization: Bearer ••••
Accept: application/json
HTTPS
RESPONSE200 OK{ "id": "ord_2048", "status": "ready" }
İstek; yöntem, adres, başlıklar ve gerektiğinde gövde verisi taşır.HAZIR
METHOD

İşlem amacı

GET okuma, POST oluşturma veya işleme, PATCH kısmi değişiklik, DELETE ise kaldırma amacını belirtir.

PATH

Kaynak

/v1/orders/{id} iş alanını ve kimliği görünür kılar.

SCHEMA

Şekil

Alan, tür, zorunluluk ve doğrulama kuralları sözleşmedir.

STATUS

Sonuç

2xx başarı, 4xx istemci/sözleşme, 5xx servis hatası ailesidir.

AUTH

Yetki

Kimlik kadar bu aktörün bu kaynağa erişip erişemeyeceği önemlidir.

ERROR

Hata modeli

Makinece okunur kod, anlaşılır açıklama, iz kimliği ve alan bazlı ihlal bilgisi üretir.

İLETİŞİM MODELİ KARŞILAŞTIRMASI / 05

Kullanım senaryosuna uygun API modeli

KAYNAK API’Sİ

REST

HTTP semantiği ve kaynak odaklı endpoint’lerle geniş uyumluluk sağlar.

Tercih et

Genel web/mobile API’leri, public API’ler, cache edilebilir kaynaklar.

Kaçın

İstemcinin çok değişken veri şekilleri istediği veya düşük gecikmeli servis içi streaming gereken akışlar.

Sözleşme

OpenAPI + JSON Schema

İhtiyaçİlk adayNeden
Public CRUD APIRESTHTTP uyumu, anlaşılır kaynak modeli, güçlü tooling
Çok farklı ekran veri şekliGraphQLİstemci alan seçer; tek şema üzerinden keşif
Servisler arası typed iletişimgRPCProtobuf, code generation, streaming
“Olay olduğunda haber ver”Webhook / EventPolling yerine push; gevşek bağlı iş akışı
Çift yönlü canlı kanalWebSocketUzun yaşayan, iki yönlü bağlantı
Sunucudan tarayıcıya akışSSEHTTP üstünde basit tek yönlü event stream
GÜVEN SINIRLARI / 06

İsteğin geçtiği entegrasyon katmanları

01TarayıcıOturum ve arayüz durumu
→
02Web framework’üSunucu render’ı ve route işleyicisi
→
03Alan API’siŞema ve yetkilendirme
→
04Veritabanıİşlem ve indeks yönetimi
TLSOIDC / SessionSchema validationLeast privilegeTrace ID
KULLANICI OTURUMU

OAuth 2.0 + OpenID Connect

Yetkilendirme ile kimlik doğrulama katmanlarını ayırır. Tarayıcı ve mobil uygulama girişlerinde Authorization Code + PKCE akışı temel seçimdir.

SERVİSLER ARASI

Kısa ömürlü kimlik bilgileri

Statik anahtarlar yerine iş yükü kimliği veya kısa ömürlü ve dar kapsamlı erişim belirteçleri tercih edilmelidir.

SUNUCU ENTEGRASYONU

API anahtarı ve imzalı webhook

API anahtarları güvenli bir sır deposunda tutulmalı; webhook gövdesi zaman damgası ve imza bilgisiyle doğrulanmalıdır.

TARAYICI SINIRI

CORS erişim yetkisi sağlamaz

CORS, tarayıcının kaynaklar arası yanıt okuma politikasını yönetir. Gerçek yetkilendirme her istekte sunucu tarafından uygulanmalıdır.

03 / Üretim koşullarını ölç ve doğrulaGÜVENİLİRLİK VE YAYIN
DAYANIKLILIK LABORATUVARI / 07

Bağlantı korumalarının kapsamını ölçün

2 / 6
Temel sınır korumaları etkin; tekrarlı yazma ve zincirleme hata riskleri henüz yönetilmiyor.EKSİK KORUMA
429

İstek sınırı

Retry-After bilgisi izlenmeli; istemci ve kiracı kotaları ayrı yönetilmelidir.

503

Geçici servis hatası

Yalnızca güvenli veya idempotent işlemler sınırlı üstel bekleme politikasıyla yeniden denenmelidir.

409

Durum çakışması

İyimser eşzamanlılık, sürüm alanı veya ETag kullanılarak kayıp güncelleme önlenmelidir.

422

Geçersiz veri

Alan bazlı ihlal listesi ve kararlı hata kodu, tüketicinin hatayı doğru işlemesini sağlar.

SÖZLEŞME ÖNCELİKLİ GELİŞTİRME / 08

Sipariş API’si için üretim adımları

  1. 01
    İş kabiliyeti“Sipariş oluştur” sonucunu ve sınırı yaz.
  2. 02
    Kaynak modeliOrder, line item, money, status.
  3. 03
    HTTP semantiğiPOST /v1/orders · 201 Created.
  4. 04
    ŞemaZorunlu alan, tür, format, limit.
  5. 05
    YetkiActor, scope ve object-level authorization.
  6. 06
    Hata modeliProblem Details + stabil hata kodu.
  7. 07
    Test ve örnekHappy path, boundary, auth, replay.
  8. 08
    Gözlem ve yayınTrace, SLO, version, deprecation.
Sözleşme, uygulama kodundan önce ekipler arasında ortak teknik referans oluşturur.HAZIR
openapi.yaml
paths:
  /v1/orders:
    post:
      operationId: createOrder
      security: [{ oauth2: [orders:write] }]
      requestBody:
        required: true
        content:
          application/json:
            schema: { $ref: '#/components/schemas/CreateOrder' }
      responses:
        '201': { description: Order created }
        '409': { description: Idempotency conflict }
        '422': { description: Validation failed }
YAYIN DOĞRULAMASI / 09

API yayın ölçütleri

0 / 6
YAYIN KAPALI

Altı kanıt tamamlandığında release açılır.

GERİYE UYUMLU

Yeni alan eklemek

Çoğu JSON tüketicisinde güvenlidir; yine de katı istemci ve şema davranışı sözleşme testleriyle doğrulanmalıdır.

UYUMSUZ DEĞİŞİKLİK

Alan silmek veya tür değiştirmek

Yeni sürüm, kullanımdan kaldırma takvimi ve tüketici geçiş planı gerektirir.

DAVRANIŞ DEĞİŞİKLİĞİ

Alan anlamını değiştirmek

Şema aynı kalsa bile sözleşme bozulabilir. Davranış odaklı sözleşme testi eklenmelidir.

DERS / 10

Uygulama mimarisi karar süreci

Bu değerlendirme sırası, yeni bir ürün veya entegrasyonda teknik kararların gerekçeli ve tekrarlanabilir biçimde alınmasını sağlar.

01

İş problemini teknoloji adlarından bağımsız tanımlayın.

Kullanıcı, veri, işlem, gecikme ve başarı ölçütlerini açıkça belirtin.

02

Sunum ve istemci modelini belirleyin.

Arama görünürlüğü, etkileşim, çevrimdışı çalışma ve cihaz gereksinimlerini ayrı değerlendirin.

03

Framework bağımlılığını sınırlandırın.

Alan kurallarını framework yaşam döngüsünden ve altyapı ayrıntılarından ayrıştırın.

04

API tüketicilerini tanımlayın.

Web, mobil, iş ortağı, servis ve ajan gereksinimlerini görünür hâle getirin.

05

İletişim modelini veri akışına göre seçin.

Kaynak, sorgu, RPC, olay veya gerçek zamanlı iletişim tercihinin gerekçesini belgeleyin.

06

Sözleşmeyi uygulamadan önce örnekleyin.

İstek, yanıt, hata, yetki ve sürüm davranışını çalıştırılabilir örneklerle doğrulayın.

07

Güven ve yetki sınırlarını test edin.

Kimlik doğrulamadan sonra nesne düzeyi yetkiyi ve kiracı ayrımını sınayın.

08

Hata senaryolarını tanımlayın.

Zaman aşımı, yeniden deneme, idempotency, kuyruk ve kısmi hata davranışlarını belirleyin.

09

Aday mimarileri dikey dilimle karşılaştırın.

Seçenekleri gerçek veri, dağıtım yolu ve işletim ölçümleri üzerinde değerlendirin.

10

Yayın kararını ölçülebilir kanıtlara bağlayın.

Sözleşme testlerini, izleri, servis hedeflerini, geçiş takvimini ve geri dönüş planını kaydedin.

TEKNİK REFERANS

Uygulama mimarisi terimleri

Bu sözlük, framework, API ve entegrasyon kararlarında kullanılan 30 temel kavramı ortak ve uygulanabilir tanımlarla açıklar.

Framework

Uygulama akışını ve extension point’lerini belirleyen iskelet.

Library

Kodunuzun çağırdığı, belirli sorunu çözen araç seti.

Runtime

Kodun yürüdüğü ve sistem yeteneklerine eriştiği ortam.

Inversion of Control

Ana akışın sizin kodunuz yerine framework tarafından yönetilmesi.

API

İki yazılım sınırı arasındaki davranış ve veri sözleşmesi.

Endpoint

Belirli kaynak veya operasyon için adreslenebilir API yüzeyi.

Contract

Girdi, çıktı, hata, yetki ve uyumluluk kuralları.

Schema

Verinin alan, tür, format ve doğrulama tanımı.

REST

HTTP semantiği ve kaynak temsilleri üzerine kurulu stil.

GraphQL

Typed schema üzerinden istemcinin alan seçtiği query dili.

gRPC

Protocol Buffers ve RPC tabanlı typed iletişim sistemi.

Webhook

Bir olay oluştuğunda başka sisteme gönderilen HTTP bildirimi.

WebSocket

Uzun yaşayan, çift yönlü istemci-sunucu kanalı.

SSE

Sunucudan istemciye HTTP tabanlı tek yönlü event akışı.

OpenAPI

HTTP API sözleşmesini makinece okunur tanımlayan standart.

AsyncAPI

Mesaj ve event odaklı API’ler için sözleşme formatı.

API Gateway

Routing, auth, limit ve politika uygulayan giriş katmanı.

BFF

Belirli frontend’in ihtiyaçlarına göre şekillenen backend sınırı.

OAuth 2.0

Bir istemciye sınırlı kaynak erişimi verme çerçevesi.

OpenID Connect

OAuth 2.0 üstünde kimlik doğrulama katmanı.

CORS

Tarayıcıların origin’ler arası response okuma politikası.

Idempotency

Aynı işlemin tekrarının ek yan etki üretmemesi.

Rate limit

Tüketici veya tenant başına istek bütçesi.

Circuit breaker

Arızalı bağımlılığa çağrıyı geçici olarak kesen koruma.

Backoff + jitter

Tekrar aralığını büyüten ve istemcileri dağıtan bekleme.

Trace ID

Bir isteği servis sınırları boyunca takip eden kimlik.

SLO

Gecikme ve kullanılabilirlik için ölçülebilir servis hedefi.

Versioning

Sözleşme evrimini tüketicilerle uyumlu yönetme yaklaşımı.

Deprecation

Eski davranışın kaldırılmadan önce ilan edilen geçiş dönemi.

Contract test

Üretici ve tüketicinin aynı sözleşmeye uyduğunu doğrulayan test.

KAYNAK TABANI / 2 EYLÜL 2026

Teknik kararları resmi kaynaklarla doğrulayın.

Framework davranışları ve standart ayrıntıları sürümler arasında değişebilir. Bu bölüm, eğitimde kullanılan resmi dokümantasyona ve açık standartlara doğrudan erişim sağlar.

FRAMEWORK REHBERİ

React · Creating a React App

Yeni React uygulamalarında framework ile başlama yaklaşımı.

 FULL-STACK REACT

Next.js Docs

App Router, rendering, data ve deployment davranışları.

 FULL-STACK VUE

Nuxt Docs

Vue tabanlı full-stack uygulama modeli ve convention’lar.

 WEB PLATFORMU

Angular Overview

Entegre framework özellikleri, tooling ve ölçek yaklaşımı.

 SVELTE FRAMEWORK

SvelteKit Docs

Routing, rendering ve adapter tabanlı deployment modeli.

 CONTENT-DRIVEN

Why Astro?

Server-first rendering ve islands yaklaşımı.

 PYTHON API

FastAPI Docs

Type hints, validation, OpenAPI ve async API geliştirme.

 NODE.JS BACKEND

NestJS Docs

Module, provider, dependency injection ve server architecture.

 PYTHON WEB

Django Overview

ORM, auth, admin ve güvenli web geliştirme yaklaşımı.

 AÇIK STANDART

OpenAPI Specification

HTTP API’lerini makinece okunur tanımlama standardı.

 QUERY API

GraphQL Learn

Schema, types, queries, mutations ve execution modeli.

 TYPED RPC

gRPC Introduction

Protocol Buffers, stubs ve streaming RPC yaklaşımı.

 EVENT CONTRACT

AsyncAPI Document

Message-driven sistemlerde kanal ve mesaj sözleşmeleri.

 INTERNET STANDARD

HTTP Semantics · RFC 9110

Method, status, cache ve HTTP anlamının normatif temeli.

 ERROR STANDARD

Problem Details · RFC 9457

HTTP API hata response’ları için ortak model.

 AUTH SECURITY

OAuth 2.0 Security BCP

Modern OAuth tehditleri ve güvenlik önerileri.

 SECURITY RISK

OWASP API Security Top 10

Object authorization, resource consumption ve inventory riskleri.

 REALTIME WEB

MDN WebSocket API

Tarayıcıda çift yönlü iletişim modeli.

Değerlendirme notu: Güncellik tek başına seçim ölçütü değildir. Framework seçenekleri; resmi destek durumu, ekip yetkinliği, prototip ölçümleri, güvenlik gereksinimleri ve toplam işletim maliyetiyle birlikte değerlendirilmelidir.

SONUÇ

Sağlam bir uygulama mimarisi açık sorumluluklar üzerine kurulur.

Framework seçimi uygulamanın çalışma düzenini, API sözleşmesi sistem sınırlarını, doğrulama süreci ise güvenlik ve işletim kalitesini belirler. Bu üç alan birlikte değerlendirildiğinde teknik kararlar sürdürülebilir ve ölçülebilir hâle gelir.