AFFiNE nasıl çalışıyor? BlockSuite, CRDT ve local-first mimarinin kökeni

[[Page ve Edgeless]] neden aynı içeriği iki farklı düşünme yüzeyinde gösterebiliyor? Cevabın bir kısmı AFFiNE'in başından beri "sayfa" yerine **dönüşebilir blok** fikrini merkeze koymasında.

Önce isimleri ayıralım

1 Şubat 2023 tarihli AFFiNE yazısı dört adı açıklıyor.

Toeverything

Projelerin arkasındaki organizasyon.

AFFiNE

Kullanıcının gördüğü bilgi ve çalışma alanı ürünü.

BlockSuite

AFFiNE'de blok oluşturma, düzenleme, görüntüleme ve dönüştürme işlevlerini bağımsız bir paket olarak ayırma girişimi.

Yazının temel fikri şu: AFFiNE'deki "her şey blok" yaklaşımı yalnız ürünün içine gömülmesin; başka geliştiricilerin de kullanabileceği bir editör altyapısına dönüşsün.

OctoBase

Aynı 2023 yazısı OctoBase'i, CRDT tabanlı ortak çalışma backend'i ve veritabanı olarak tanımlar. Görevi veri kopyaları arasındaki çakışmaları çözmek ve local-first/gerçek zamanlı ortak çalışmayı mümkün kılmaktır.

Bu tanım **2023 mimari anlatımıdır**. 2026 ürününü incelerken güncel repo ve dokümantasyon ayrıca kontrol edilmelidir.

"A tuşuna bastım" neden bu kadar karmaşık?

AFFiNE ekibi 2022'de iki uzun yazıyı tek bir basit olay üzerine kuruyor: ortak çalışmalı bir editörde kullanıcı **A** tuşuna bastığında ne olur?

Bu iyi bir mimari sorudur. Çünkü ekranda tek harf görürsün; sistemde ise en az şu işler olabilir:

• mevcut seçim anlaşılır,
• hangi bloğun değişeceği bulunur,
• veri modeli güncellenir,
• değişiklik geri alınabilir hâle gelir,
• yerel depoya yazılır,
• ağ varsa diğer istemcilere aktarılır,
• başka kullanıcının eşzamanlı değişikliğiyle uzlaştırılır.

Kullanıcı deneyimi basit görünür; sistem karmaşıklığı aşağıya gömülür.

İşlemden veri modeline

İlk teknik yazı iki yaklaşımı ayırıyor.

Bir editör değişikliği doğrudan son metni değiştirerek tutabilir. Fakat ortak çalışma için çoğu zaman "ne yapıldı?" bilgisini de modellemek gerekir.

Örneğin:

• ekle,
• sil,
• değiştir.

Bu yaklaşım undo/redo ve ağ üzerinden değişiklik taşıma için önemlidir.

Yazı daha sonra iki büyük ortak çalışma ailesini karşılaştırıyor:

• **OT — Operational Transformation**
• **CRDT — Conflict-free Replicated Data Type**

BlockSuite için verilen örnek Yjs tabanlı CRDT yaklaşımıdır.

CRDT kullanıcıya ne kazandırır?

Teknik ayrıntının kullanıcıya dönük sonucu şu:

Aynı belgenin birden fazla kopyası farklı yerlerde değişebilir ve sistem, değişiklikleri yalnız "son yazan kazanır" mantığıyla ezmek zorunda kalmadan ortak bir sonuca ulaştırmaya çalışır.

Bu local-first yazılım için kritiktir.

Çünkü ağ her zaman açık olmayabilir.

Çevrimdışı düzenleme tasarımın neresinde?

İkinci teknik yazı, Yjs/YDoc örneğinde yerel model değişikliklerinin ağ isteğinden bağımsız uygulanabildiğini anlatıyor.

Burada **provider** ayrımı önemli:

• depolama sağlayıcısı: değişikliği yerel/veri tabanı tarafına yazar,
• ağ sağlayıcısı: değişikliği WebSocket/WebRTC benzeri kanal üzerinden taşır.

Bir belge birden fazla provider'a bağlanabilir.

Bu düşünce sayesinde "offline" ayrı bir ekran modu olmak zorunda değildir. Kullanıcı yerel modeli değiştirir; ağ geldiğinde senkron mekanizması devreye girer.

Bu, [[local-first]] yaklaşımının teknik karşılıklarından biridir.

Block modeli neden Page + Edgeless için uygun?

2023 açıklamasında AFFiNE isminin "affine transformation" fikrinden geldiği belirtiliyor: bilgi farklı şekillere dönüşürken alttaki "gerçek" mümkün olduğunca aynı kalır.

Bunu ürün diline çevirirsek:

• aynı bilgi doğrusal belgede okunabilir,
• aynı blok görsel yüzeyde konumlandırılabilir,
• yapılandırılmış koleksiyonun parçası olabilir.

Ama burada dikkat: "aynı veri modeli sayesinde her şey her zaman kayıpsız dönüşür" gibi daha güçlü bir iddiayı bu eski yazılardan çıkarmamalıyız. Ürün davranışını güncel sürümde ayrıca test etmek gerekir.

Tarayıcı tarafında başka ne oluyor?

Platform I/O yazısı editörün yalnız veri modeli olmadığını gösteriyor.

Örneğin metin seçimi için:

• tarayıcının native selection API'si,
• contenteditable,
• MutationObserver,
• özel seçim arayüzleri,
• Web Components

gibi parçalar devreye giriyor.

BlockSuite'in tarihsel tasarımı, her paragrafı ayrı düzenlenebilir birim olarak ele alıp metin dışı blokları farklı DOM bileşenlerinde tutmaya çalışıyor.

Buradan çıkan önemli ürün dersi:

**Güçlü ortak çalışma; senkron algoritması, seçim, DOM, undo, blok ve ağ davranışının birlikte tasarlanmasını gerektirir.**

2023 local-first planı neydi?

Mart 2023 yazısı AFFiNE'in offline/local-first hedefini aşamalar halinde anlatıyordu:

1. cihazda yerel kullanım + isteğe bağlı AFFiNE Cloud,
2. yerel ağ içinde cihazlar arası senkron,
3. yerel ağda hesaplar arası ortak çalışma ve isteğe bağlı sunucu/cloud.

Aynı yazı workspace'i dosya düzeyinde kontrol etme, farklı import/export biçimleri ve self-host desteği hedeflerinden de söz ediyordu.

Bunların hepsi 2023 planının parçalarıdır. 2026'da hangi kısmın tam olarak ürünleştiğini görmek için güncel doküman ve sürüm notlarına bakmak gerekir.

2026'da neden hâlâ bu eski yazıları okuyoruz?

Çünkü ürünün bugünkü yüzeyini anlamak için kökenindeki üç karar hâlâ öğretici:

**1. Blok birinci sınıf nesne.** Editör, uzun bir rich-text alanından daha geniş bir veri modeli kullanıyor.

**2. Ortak çalışma veri modeline gömülüyor.** Senkron sonradan eklenmiş bir dosya kopyalama işi olarak düşünülmüyor.

**3. Offline/local-first ürün mimarisinin başından beri parçası.** Bu yüzden yalnız pazarlama etiketinden ibaret olup olmadığını tarihsel olarak izleyebiliyoruz.

Temmuz 2026'da güncellenen açık kaynak yazısı, bugünkü ürünü Page, Edgeless ve databases/collections üçlüsüyle anlatıyor. Yani erken dönemdeki "yazı + görsel düşünme + yapılandırılmış veri" fikri, ürün yüzeyinde hâlâ okunabiliyor.

Kullanıcı için çıkarım

AFFiNE'i değerlendirirken "hangi özellikleri var?" sorusundan önce şunu sor:

**Benim bilgim tek bir belge biçiminde mi kalacak, yoksa yazı, tahta ve yapılandırılmış görünüm arasında hareket edecek mi?**

İkinci cevap baskınsa AFFiNE'in mimari fikri anlamlı hâle gelir.

Birinci cevap baskınsa — yalnız düz Markdown, minimum bağımlılık ve uzun vadeli dosya taşınabilirliği istiyorsan — daha basit bir araç daha doğru olabilir.

Mimari, ürünün **hangi probleme doğal olarak uyduğunu** söyler.