Workspace

Workspace, domain, API ve runtime kararlarının tek bir operasyonel akışta bağlı kaldığı yerdir. Mock API projeni oluşturduğun, yapılandırdığın, doğruladığın ve iterasyon yaptığın merkezi ortamdır.

Bu sayfa, workspace'in her önemli alanını ele alır ve her alanın ne yaptığını, nasıl etkili kullanılacağını ve nelere dikkat edilmesi gerektiğini açıklar.

Workspace Alanları

Workspace, modelleme ve API tasarımı iş akışının belirli bir parçasına odaklanan farklı alanlara ayrılmıştır. Bu alanlar arasında istediğin zaman geçiş yapabilirsin — bir alandaki değişiklikler anında diğerlerine yansır.

1. Proje Bağlamı ve Navigasyon

Üst düzey workspace bağlamı, hangi proje üzerinde çalıştığını ve farklı görünümler arasında nasıl gezindiğini kontrol eder.

Neler Yapabilirsin

• Aktif projeler arası geçiş — birden fazla projen varsa, proje seçici yerini kaybetmeden bağlam değiştirmeni sağlar.
• Modelleme bağlamını kararlı tutma — workspace, hangi tablo, görünüm veya yapılandırma panelini açık bıraktığını hatırlar.
• Görünümler arası geçiş — modelleme panosu, tablo düzenleyici, API tasarımı ve runtime önizlemesi arasında gezin.

Proje Ayarları

Her projenin API endpoint URL'sini belirleyen benzersiz bir slug değeri vardır:

POST /mock/{slug}/graphql

Slug, proje adından otomatik olarak oluşturulur ancak özelleştirilebilir. Slug'ları kısa, küçük harfli ve tire ile ayrılmış tut (örneğin customer-portal, ecommerce-demo).

ws-01-project-switcherMissing

Proje bağlam çubuğu ve görünüm geçişi.

2. Modelleme Panosu

Modelleme panosu, yapısal tasarım alanıdır — domain entity'lerini ve bağlantılarını oluşturup düzenlediğin görsel bir tuvaldir.

Tablolarla Çalışma

Pano, her entity'yi bir tablo kartı olarak gösterir. Şunları yapabilirsin:

• Yeni tablolar oluşturma — iş konseptlerini temsil eden entity'ler ekle (örneğin Product, Customer, Order).
• Tabloları konumlandırma — tablo kartlarını sürükleyip bırakarak mekânsal olarak düzenle. Görsel netlik için ilişkili entity'leri birlikte grupla.
• Tablo özelliklerini düzenleme — tabloları yeniden adlandır, gösterim seçeneklerini yapılandır ve meta verileri yönet.
• Tabloları silme — artık gerekli olmayan entity'leri kaldır.

Görsel İlişki Çizgileri

Tablolar arasındaki ilişkiler, ilişkili entity'leri birbirine bağlayan görsel çizgiler olarak gösterilir. Çizgiler şunları belirtir:

• Yön — ilişkinin sahibi hangi entity (ok yönü).
• Kardinalite — ilişki türü (1:1, 1:n, m:n), çizgi üzerindeki notasyonlarla gösterilir.
• Bağlantı noktaları — ilişkide hangi sütunların yer aldığı.

Bu görsel temsil, domain yapını bir bakışta incelemeni ve eksik veya hatalı ilişkileri tespit etmeni kolaylaştırır.

Pano Kontrolleri

• Yakınlaştırma ve kaydırma — fare tekerleğiyle yakınlaştırma ve sürükleyerek kaydırma ile büyük panolarda gezin.
• Izgara yakalama — isteğe bağlı ızgara hizalaması tabloları düzgün konumlandırır.
• Otomatik düzenleme — optimal okunabilirlik için tabloları otomatik olarak düzenle.

ws-02-modelling-boardMissing

Bağlı domain entity'leriyle modelleme panosu.

Pano kısıtlamaları

Free User

Free ve misafir kullanıcılar modelleme panosuna tam erişime sahiptir. Pano karmaşıklığı, bir proje içindeki tablo sayısıyla değil, yalnızca planının izin verdiği proje sayısıyla sınırlıdır.

3. Tablo ve Attribute Yapılandırması

Modelleme panosunda bir tablo seçtiğinde, entity ve attribute'ları için detaylı yapılandırma seçenekleri sunan tablo düzenleyici paneli açılır.

Tablo Özellikleri

Her tablo şunlara sahip olmalıdır:

• Net bir ad — iş diline uyan tekil isimler kullan (Invoice, invoices_table değil).
• Bir açıklama — isteğe bağlı ancak takım iletişimi ve dokümantasyon için faydalıdır.

Attribute Yapılandırması

Her attribute (sütun) için şunları yapılandırırsın:

Özellik	Açıklama	Etki
Name	Alan tanımlayıcısı	GraphQL alan adı olur
Type	string, number, boolean, date, json	Filtre operatörlerini ve doğrulamayı belirler
Required	Alanın bir değere sahip olması gerekip gerekmediği	GraphQL null olabilirliğini etkiler
Sortable	Alanın sıralama işlemlerini destekleyip desteklemediği	Sorgularda sort parametresini etkinleştirir
Searchable	Alanın aramaya katılıp katılmayacağı	Arama sorgusu çözümlemesine dahil edilir
Filterable	Alanın filtre ifadelerini destekleyip desteklemediği	Sorgularda filter parametresini etkinleştirir
Mapping	Veri kaynağı: OFF_FIELD, FAKE veya CONST	Alanın hangi veriyi döndürdüğünü belirler

Adlandırma Kuralları

Tutarlı adlandırma, modelini okunabilir ve oluşturulan kodunu öngörülebilir kılar:

• Attribute'lar — camelCase kullan (örneğin firstName, totalAmount, isActive)
• Tablolar — tekil PascalCase kullan (örneğin Customer, OrderItem)
• Kısaltmalardan kaçın — description, desc'den iyidir; quantity, qty'den iyidir

Veri Nesnesi Seçimi

Bir attribute'u gerçek veri seti alanına (OFF_FIELD) eşlerken, aşağıdakileri içeren bir yan panel açılır:

• Arama — veri nesnelerini ada veya etikete göre bul
• Etiket filtreleri — sonuçları kategoriye göre daralt
• Örnek önizleme — bir eşleştirmeye karar vermeden önce örnek değerleri gör

Bu, her attribute için doğru veri kaynağını seçmeni sağlar.

ws-03-table-editorMissing

Attribute yapılandırma paneliyle tablo düzenleyici.

ws-03b-data-object-selectorMissing

Arama ve önizleme ile veri nesnesi seçim paneli.

4. İlişki Tanımı

İlişkiler, entity'lerini birbirine bağlar ve verinin aralarında nasıl aktığını tanımlar. İlişkileri doğru kurmak kritik öneme sahiptir — runtime'da iç içe sorguların nasıl çözümleneceğini belirlerler.

İlişki Türleri

Tür	Örnek	Anlam
Bire-Bir (1:1)	User → Profile	Her kullanıcının tam olarak bir profili vardır
Bire-Çok (1:n)	Customer → Order[]	Her müşterinin birden fazla siparişi vardır
Çoka-Çok (m:n)	Product ↔ Category	Ürünler birden fazla kategoriye aittir ve bunun tersi de geçerlidir

Kalite Kontrol Listesi

Bir ilişkiyi sonlandırmadan önce şu soruları sorun:

• Sahiplik mi, referans mı? — Bu ilişki gerçek bir sahipliği mi temsil ediyor (müşteri siparişlerinin sahibidir) yoksa bir referansı mı (sipariş bir ödeme yöntemine referans verir)?
• Yön netliği — Hangi entity'nin üst, hangisinin alt olduğu açık mı?
• Arama davranışı — Üst entity'yi sorgularken alt veriler varsayılan olarak dahil edilmeli mi? Ters yön için durum ne?
• Kardinalite doğruluğu — Bu gerçekten 1:n mi, yoksa gelecekte m:n olabilir mi?

İlişkilerin Runtime'ı Nasıl Etkilediği

Runtime'da ilişkiler, sorgu motorunun iç içe verileri nasıl derlediğini belirler. Sorgularken:

query {
  customers(limit: 5) {
    id
    name
    orders {
      id
      totalAmount
    }
  }
}

Runtime, her Customer için ilişkili Order kayıtlarını aramak üzere ilişki tanımını kullanır. İlişki yanlış yapılandırılmışsa (yanlış yön, eksik yabancı anahtar referansı), iç içe veri boş veya hatalı olacaktır.

ws-04-relation-editorMissing

İlişki kurulumu ve kardinalite yapılandırması.

5. API Tasarım Entegrasyonu

API tasarım alanı, domain modelinin bir GraphQL API olarak nasıl sunulacağını kontrol etmeni sağlar. Her entity veya işlem genel olmak zorunda değildir — API tasarım görünümü, yalnızca mevcut aşama için anlamlı olanı açmana yardımcı olur.

Sorgu Adlandırma

Mockomat, entity adlarından otomatik olarak sorgu adları oluşturur, ancak bunları özelleştirebilirsin:

• Liste sorgusu — varsayılan olarak çoğul form (örneğin products, customers)
• Detay sorgusu — varsayılan olarak tekil form (örneğin product, customer)

Frontend takımının veri hakkında nasıl düşündüğüne uyan adlar seç. Sorgu adı, her GraphQL isteğindeki giriş noktası olur.

İşlem Açılımı

Hangi işlemlerin kullanılabilir olacağını sen kontrol edersin:

• Liste sorgularını etkinleştirme/devre dışı bırakma — tüketicilerin koleksiyonları getirip getiremeyeceğine karar ver.
• Detay sorgularını etkinleştirme/devre dışı bırakma — tüketicilerin tekil kayıtları getirip getiremeyeceğine karar ver.
• Sayfalandırma varsayılanlarını yapılandırma — varsayılan sayfa boyutunu ve maksimum limitleri belirle.

Tasarım İlkeleri

• Dar başla — önce daha az işlem aç, model kararlılaştıkça genişlet.
• Bilinçli adlandır — sorgu adları API sözleşmenin bir parçasıdır. Daha sonra değiştirmek tüm tüketicileri etkiler.
• Açmadan önce doğrula — endpoint'i takımınla paylaşmadan önce davranışı doğrulamak için önizlemeyi kullan.

ws-05-api-designMissing

Model tablolarına hizalı API tasarım görünümü.

6. Önizleme ve İpucu İş Akışı

Önizleme, her modelleme iterasyonunun parçası olmalıdır, son bir adım değil. Modelini dürüst tutan geri bildirim döngüsüdür.

Önizleme Nasıl Çalışır

Önizlemeyi açtığında Mockomat:

1. Mevcut modelinden bir GraphQL şeması oluşturur.
2. Eşleştirilmiş verilerine karşı bir örnek sorgu yürütür.
3. Sonuçları hazırlık ipuçlarıyla birlikte döndürür.

Önizleme, hem veri yanıtını hem de dikkat edilmesi gereken sorunları gösterir.

İpucu Türleri

İpuçları, model sorunlarını tanımlayıp düzeltmene yardımcı olan eyleme dönüştürülebilir sinyallerdir:

İpucu	Anlam	Eylem
Eşleştirilmemiş attribute	Bir alanın yapılandırılmış veri kaynağı yok	OFF_FIELD, FAKE veya CONST eşleştirme ata
Eksik endpoint meta verisi	Bir sorgu veya işlem gerekli yapılandırmadan yoksun	API tasarım görünümünü aç ve kurulumu tamamla
Yapılandırma uyumsuzluğu	Bir alan sortable olarak işaretlenmiş ancak uyumlu bir veri türü yok	Attribute türünü ve bayrak kombinasyonunu incele
İlişki uyarısı	Bir ilişki hedef entity'si veya sütunu eksik	Tablo düzenleyicisindeki ilişki tanımını kontrol et

İterasyon İş Akışı

En verimli iş akışı sıkı bir döngü izler:

1. Model değişikliği yap — bir tablo ekle, bir attribute değiştir, bir ilişki oluştur.
2. Önizleme aç — bir sorgu çalıştır ve sonuçları incele.
3. İpuçlarını incele — uyarı veya hataları gider.
4. API tasarımını güncelle — gerekirse sorgu adlarını veya işlem açılımını ayarla.
5. Tekrarla — model kararlı ve önizleme temiz olana kadar devam et.

Bu döngü dakikalar değil, saniyeler sürmeli. Ne kadar hızlı iterasyon yaparsan, nihai modelinin kalitesi o kadar yüksek olur.

ws-06-preview-hintsMissing

Eyleme dönüştürülebilir hazırlık ipuçlarıyla önizleme görünümü.

7. Görünümler ve Çapraz Bağlantı Navigasyonu

Görünümler, aynı temel model üzerinde farklı perspektifler sunar. Menüler arasında gezinmek yerine, çapraz bağlantılar kullanarak ilişkili bağlamlar arasında geçiş yapabilirsin.

Mevcut Görünümler

• Pano görünümü — tabloları ve ilişkileri gösteren görsel modelleme tuvali.
• Tablo detay görünümü — tam attribute yapılandırması ile tek bir entity'ye odaklanmış görünüm.
• API tasarım görünümü — seçilen entity için sorgu ve işlem yapılandırması.
• Runtime önizlemesi — canlı sorgu yürütme ve yanıt inceleme.

Çapraz Bağlantı Navigasyonu

Bir görünümde çalışırken, ilişkili bağlam linkleri satır içi olarak kullanılabilir. Örneğin:

• Tablo detay görünümünden, o tablonun sorgularını test etmek için doğrudan runtime önizlemesine geçebilirsin.
• Runtime önizlemesinden, bir alan sorunu fark edersen tablo düzenleyicisine geri dönebilirsin.
• API tasarım görünümünden, tam domain yapısını incelemek için modelleme panosuna geçebilirsin.

Bu navigasyon modeli seni akışta tutar — bağlam değiştirmek için asla "panoya geri dön" demen gerekmez.

ws-07-views-navigationMissing

Workspace görünümleri arası çapraz bağlantı navigasyonu.

Kayıtlı kullanıcı iş akışı ipucu

Registered User

Kısa iterasyon döngüleri oluştur: model güncelleme → önizleme kontrolü → API güncelleme. Bu, ilerlemeyi ölçülebilir tutar ve gecikmeli uyumsuzluk keşfini önler. İlişkili bağlamlar arasında hızla geçmek için görünüm navigasyonunu kullan.

Ücretli kullanıcı iş akışı ipucu

Paid User

Adlandırma ve ilişki desenleri için takım düzeyinde kurallar tanımla. Bu kuralları daha hızlı onboarding ve incelemeler için projeler arasında yeniden kullan. Yeni takım üyelerinin hemen takip edebilmesi için kurallarını proje açıklamasında belgelendir.