# Uygulamayı en baştan net bir API çevresinde tasarlamak

> Bir uygulamayı en baştan net bir API çevresinde, tipli bir veritabanı ve yalnızca bu API'yi tüketen bir ön yüzle tasarlamak, ihtiyaca özel iş uygulaması geliştirirken benimsediğim yaklaşım.

- Source canonique : [https://allaux.fr/tr/expertises/architecture-fullstack-api-first](https://allaux.fr/tr/expertises/architecture-fullstack-api-first)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Tipik ihtiyaç

CMS üzerinde çalışan klasik mağazaların ötesinde bazı ihtiyaçlar, özel olarak kurgulanmış bir iş uygulaması gerektirir: kendine has bir mantığı olan bir müşteri paneli, şirket içi bir araç ya da mevcut bir mağazanın, bir CMS eklentisinin makul biçimde taşıyabileceğini aşan bir uzantısı. Bu tür projeler, ön yüz ile arka ucun iç içe geliştirildiği ve sonradan geliştirmesi zorlaşan bir yapıya kıyasla, en baştan bir API çevresinde düşünülmüş bir mimariden fayda görür.

## Bu tür ihtiyaçlarda nasıl çalışıyorum

API-first yaklaşımı, ön yüz ile arka uç arasındaki veri alışverişi sözleşmesini ikisinden birini ayrıntılı biçimde geliştirmeye başlamadan önce net olarak tanımlamak demektir: hangi kaynaklar var, hangi işlemler mümkün, hangi veri biçimi dolaşıyor. Bu sözleşme ortak referans hâline gelir; sözleşmeye uyulduğu sürece arka uca dokunmadan görsel arayüzü değiştirebilir ya da ön yüzü bozmadan iş mantığını geliştirebilirsiniz.

Teknoloji tarafında araçları alışkanlıkla değil projeye göre seçiyorum: net ve modüler bir mimari için NestJS ile Node.js arka ucu, kod ile veritabanı arasındaki tip hatalarını azaltmak için Prisma veya Drizzle gibi tipli bir ORM, zengin ve akıcı bir deneyim gerektiğinde React veya Next.js ön yüzü. Veritabanı şemasından ön yüze kadar uçtan uca tip güvenliği, aksi hâlde ancak canlı ortamda ortaya çıkacak bir hata sınıfını büyük ölçüde ortadan kaldırır.

## Fiyatlandırmayı etkileyen faktörler

- **Veri modelinin karmaşıklığı** — Çok sayıda ilişki ve tutarlılık kuralı içeren bir iş modeli, varlıkları basit bir uygulamaya göre çok daha fazla tasarım çalışması ister.
- **Kullanıcı ve profil sayısı** — Birden fazla kullanıcı profiline göre ayrıntılı yetki yönetimi, herkese aynı erişimi veren bir yapıya kıyasla ek bir karmaşıklık katmanı getirir.
- **Gereken dış entegrasyonlar** — Tek başına çalışan bir uygulama, en baştan birden fazla üçüncü taraf sistemle veri alışverişi yapması gereken bir uygulamadan daha hızlı geliştirilir.
- **Performans ve yük gereksinimleri** — Sınırlı bir şirket içi kullanım, çok sayıda dış kullanıcıya açılan bir uygulamadan farklı kısıtlar getirir.

## Başlamadan önce sorulacak sorular

> API sözleşmesi geliştirmeye başlamadan önce net biçimde tanımlanabiliyor mu, yoksa bu aşamada hâlâ belirsiz mi? Uygulamanın kaç farklı kullanıcı profilini yönetmesi gerekiyor? Bugünden bilinen dış entegrasyonlar hangileri, ileride hangileri eklenebilir?

## FAQ

### Neden ihtiyaca özel bir mimari yerine CMS kullanılmasın?

İhtiyaç, CMS'in iyi yaptığı işlerle örtüştüğü sürece CMS anlamlı kalır. İş mantığı projeye özgü ve merkezi hâle gelir gelmez, ihtiyaca özel bir mimari, başka bir kullanım için tasarlanmış bir aracın sınırlarını sürekli dolaşmak zorunda kalmanızı önler.

### Teknoloji yığını seçimi dayatılıyor mu?

Hayır, seçim projenin gerçek kısıtlarına göre yapılır: kodun devredileceği mevcut ekip, performans gereksinimleri, hâlihazırda kullanılan ekosistem. Müşterinin belirlediği bir teknoloji yığını, ihtiyaçla tutarlıysa olduğu gibi uygulanır.

### Bu mimari küçük bir uygulama için de uygun mu?

Faydası özellikle uygulama zaman içinde gelişecekse veya yeni entegrasyonlar alacaksa belirgin olur; çok sınırlı ve değişmeyecek bir ihtiyaç için daha hafif bir yaklaşım yeterli olabilir.