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; kendi kodundan yapılan çağrılar projenin bir API key'ini taşır (bkz. Entegratörler):

POST /mock/{slug}/graphql
Authorization: Bearer mck_your_api_key

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

Misafir oturumları dahil her plan modelleme panosuna tam erişime sahiptir. Proje başına tablo ve tablo başına attribute sayısı planına bağlıdır — bkz. [Hesap ve Planlar](/tr/account/).

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	örneğin String, Integer, Float, Boolean, Date, JSON, Enum	Dışa aktarımlardaki tür; bağlanan verinin türünü seç
Required	Alanın bir değere sahip olması gerekip gerekmediği	OpenAPI dışa aktarımında zorunlu olarak işaretlenir
Sortable	Modelle birlikte saklanır	Kod dışa aktarımında sıralanabilir liste sütunlarını işaretler; mock API eşlenmiş her attribute'a göre sıralar (sortField)
Searchable	Alanın aramaya katılıp katılmadığı	Liste işlemlerinin searchTerm aramasına dahil edilir
Filterable	Modelle birlikte saklanır	Mock API'ye etkisi yok — filtreleme işlem parametreleriyle yapılır
Mapping	Veri kaynağı: SOURCE veya CONSTANT; COMPUTED yalnızca bunu zaten taşıyan attribute'larda (değerlendirilmez)	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

Verileri Eşleme

Panonun Mappings panelinde önce tabloyu veri havuzundaki bir tabloya bağlarsın (Kanonik tablo) — Öner uygun bir tablo önerir ya da tüm tablolarda kendin ararsın. Ardından tablonun attribute'larını onun sütunlarına bağlarsın (SOURCE); … kesin olanı uygula tüm kesin önerileri tek seferde uygular. Boş kalması gereken attribute'ları Eşleme gerekli değil ile işaretlersin. Ayrıntılar: Data Sources & Field Mapping (İngilizce).

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(pageSize: 5) {
    items {
      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.
• Varsayılanları yapılandırma — varsayılan sayfa boyutunu (sayfa başına en fazla 100 kayıt) ve varsayılan sıralamayı 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. Modelinin, eşlemelerinin ve işlemlerinin güncel durumunu kullanır.
2. Tablonun liste işlemini içe aktarılan veriler üzerinde çalıştırır.
3. Verileri gösterir; bir şey eksikse bir ipucu verir.

Ö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 aktarılan verilerle eşlenmemiş	Tablo içe aktarılan verilere bağlı değil; API bu tablo için satır döndürmez	Tabloyu ve attribute'larını Mappings panelinde bağla
API bağlaması yok	Görünüm bir liste işlemine bağlı değil; veri yüklenmez	Görünüm ayarlarında bir liste işlemi bağla
Tanımlayıcı alan yok	Görünümün tanımlayıcı alanı yok; satıra tıklamak detay görünümünü açmaz	Görünüm ayarlarında tanımlayıcı alanı belirle

İ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.