*
* $2.98 Billion Revenue: Global in-app purchase revenue generated by short drama apps across 2025.
* 115% Year-Over-Year Increase: The third-fastest growth rate of any app category tracked by Sensor Tower. [2, 4]
*

## ⏱️ Overtaking Mobile Engagement
Data from Q4 2025 shows that daily usage of short drama leaders like ReelShort beats premium long-form streaming platforms on mobile devices in the U.S.: [2, 5]

*
* ReelShort: 35.7 minutes per day per user.
* Amazon Prime Video: 26.9 minutes per day.
* Netflix Mobile: 24.8 minutes per day.
* Disney+: 23.0 minutes per day. [2, 3]
*

## 📥 Surging App Downloads

*
* 733 Million Downloads: Total global installs driven by microdrama apps in Q4 2025 alone.
* 658 Million Downloads: Total global installs for traditional long-form streaming platforms in the same timeframe. [2]
*

The underlying analysis published by platforms like [Filmustage](https://filmustage.com/blog/short-drama-apps-compared-reelshort-vs-dramabox-in-2026/) notes that these numbers anchor production and pitching decisions for creators in 2026. Major legacy Hollywood entrants are actively building mobile-first vertical strategies to tap into this highly addictive, micro-payment-driven business model. [2, 6]
If you’d like, I can:

*
* Explain the monetization models used by these apps
* Provide details on the top dominating apps in this space
* Break down the typical genres and formats of microdramas
*

[1] [https://finance.yahoo.com](https://finance.yahoo.com/news/microdramas-overtake-streamers-mobile-engagement-061100325.html)
[2] [https://filmustage.com](https://filmustage.com/blog/short-drama-apps-compared-reelshort-vs-dramabox-in-2026/)
[3] [https://omdia.tech.informa.com](https://omdia.tech.informa.com/pr/2026/feb/microdramas-overtake-streamers-on-mobile-engagement-says-omdia)
[4] [https://www.media-marketing.com](https://www.media-marketing.com/en/news/microdrama-apps-overtake-streamers-on-mobile/)
[5] [https://deadline.com](https://deadline.com/2026/02/microdrama-more-time-cellphones-streaming-services-omdia-1236732921/)
[6] [https://www.youtube.com](https://www.youtube.com/watch?v=vsQHJUzaYqg&t=3)

Evet, bu veriler kesinlikle doğrudur ve bu sektörde gerçekten bu kadar büyük kazançlar bulunmaktadır. [1, 2]
Görselde yer alan istatistikler, mobil pazar analiz şirketleri [Sensor Tower](https://sensortower.com/blog/state-of-short-drama-apps-2025) ve [Omdia](https://omdia.tech.informa.com/pr/2026/feb/microdramas-overtake-streamers-on-mobile-engagement-says-omdia) tarafından yayınlanan resmi raporlara dayanmaktadır. Hatta güncel küresel pazar payı verileri incelendiğinde, bu dikey kısa dizi (microdrama) sektörünün toplam büyüklüğü (Çin içi pazar dahil) 11 milyar doları aşmış durumdadır. [1, 2, 3, 4]
Bu kadar yüksek kazançların oluşmasının ardında yatan temel faktörler şunlardır:
## 🪙 Pahalı ve Agresif Para Kazanma Modeli

*
* Bölüm Başına Ödeme: Netflix gibi platformlara ayda sabit bir ücret ödersiniz. Short drama uygulamalarında (ReelShort, DramaBox vb.) ise ilk 5-10 bölüm ücretsizdir. Sonraki her bir dakikalık bölümü izlemek için “jeton” (coin) satın almanız gerekir. [1]
* Tuzak Kurgular: Diziler tam en heyecanlı yerinde (cliffhanger) bittiği için kullanıcılar fark etmeden ardı ardına jeton harcar. Bir dizinin tamamını (ortalama 60-90 bölüm) bitirmek bazen 50 ila 100 dolar arasında bir maliyete ulaşabilir. Bu da sinema biletinden veya aylık Netflix aboneliğinden çok daha pahalıdır.
*

## 🎬 Düşük Maliyet, Yüksek Kâr Marjı

*
* Ucuz Prodüksiyon: Hollywood yapımları milyonlarca dolar harcarken, bu dikey diziler Los Angeles veya Doğu Avrupa’da, amatör ya da yarı profesyonel oyuncularla, telefonların dikey formatına uygun olarak 150.000 – 250.000 gibi çok düşük bütçelerle, sadece birkaç günde çekilir.
* Hızlı Geri Dönüş: Yatırılan bütçe, agresif sosyal medya reklamları sayesinde birkaç hafta içinde katlanarak geri kazanılır. [1, 5]
*

## 📈 Devlerin Rekabeti (2026 Trendi)
Pazardaki bu devasa para akışı nedeniyle, 2026 yılı itibarıyla Disney (Disney Accelerator programı üzerinden), Amazon ve TikTok (Pine Drama) gibi dev şirketler de kendi dikey kısa dizi formatlarını ve yatırımlarını devreye sokarak bu milyar dolarlık pastadan pay almaya başlamıştır. [1, 5]
Kısacası, insanların mobil cihazlardaki kısalan dikkat sürelerini ve “merak” duygusunu paraya çeviren bu sistem, şu an uygulama dünyasının en çok kazandıran iş modellerinden biridir. [2, 6]

[1] [https://filmustage.com](https://filmustage.com/blog/short-drama-apps-compared-reelshort-vs-dramabox-in-2026/)
[2] [https://www.media-marketing.com](https://www.media-marketing.com/en/news/microdrama-apps-overtake-streamers-on-mobile/)
[3] [https://deadline.com](https://deadline.com/2026/02/microdrama-more-time-cellphones-streaming-services-omdia-1236732921/)
[4] [https://www.mediapost.com](https://www.mediapost.com/publications/article/413505/microdramas-drove-in-app-revenue-of-11b-worldwide.html)
[5] [https://www.linkedin.com](https://www.linkedin.com/posts/da-hoang-635186199_the-short-drama-apps-report-activity-7475810580654739456–rCf)
[6] [https://asoworld.com](https://asoworld.com/blog/mobile-app-insights-13-short-drama-apps-crack-google-play-s-top-50-grossing/)

Böyle bir profile sahip birinin öğrenme eğrisi ve tahmini süreleri şu şekildedir:

### 1. Aşama: Dart Dilini Öğrenmek (1 – 3 Gün)
Dart, modern ve öğrenmesi oldukça kolay bir dildir. C-style syntax (C, Java, C#, JavaScript benzeri) kullanır.
* **PHP (OOP) ve Go (Statik Tip) Avantajı:** PHP’nin modern nesne yönelimli yapısı (sınıflar, arayüzler) ve Go’nun güçlü statik tipleme (strongly-typed) disiplini sayesinde Dart’ın sözdizimine (syntax) uyum sağlamak maksimum **2-3 gün** sürer.
* **Null Safety:** Dart’ın güvenli null yapısı (Sound Null Safety) Go’daki pointer kontrolü veya PHP’deki null kontrolleri ile benzer mantıktadır, bu yüzden hiç yabancılık çekmezsiniz.

### 2. Aşama: Flutter ve Bildirimsel (Declarative) UI Mantığı (1 Hafta)
Backend geliştiriciler genellikle yukarıdan aşağıya akan (imperative) veya sunucu taraflı şablon (template) yapılarına alışıktır. Flutter ise **Declarative UI** (React, SwiftUI benzeri) mantığıyla çalışır.
* Arayüzün durumuna (State) göre ekranın kendini yeniden çizmesi mantığını kavramak,
* `Row`, `Column`, `Stack`, `Container` gibi temel arayüz bileşenlerini (Widgets) öğrenmek ve yerleşim (Layout) kurallarına alışmak yaklaşık **1 hafta** sürer.

### 3. Aşama: Durum Yönetimi (State Management) ve Asenkron Yapı (1 – 2 Hafta)
Backend dünyasından gelenler için en büyük zihinsel dönüşüm buradadır. Uygulamanın durumunu (kullanıcı giriş yaptı mı, sepette ne var, tema koyu mu açık mı) cihaz üzerinde yönetmek gerekir.
* Go’daki goroutine/channel mantığına aşina biri için Dart’taki `Future`, `Stream` ve `async/await` yapısı çocuk oyuncağı gelecektir.
* **Riverpod** veya **Bloc** gibi durum yönetimi kütüphanelerini öğrenip uygulamaya entegre etmek **1-2 hafta** sürer.

—

### Toplam Süre Özeti

| Aşama | Ne Öğrenilecek? | Süre |
| :— | :— | :— |
| **Dart Temelleri** | Sınıflar, Fonksiyonlar, Null Safety | **1-3 Gün** |
| **Flutter UI** | Widget Ağacı, Layout, Navigasyon | **5-7 Gün** |
| **State & Async** | Riverpod/Bloc, HTTP İstekleri, Stream’ler | **7-10 Gün** |
| **Gerçek Proje** | Bir API’ye bağlanıp tam çalışan uygulama yapmak | **1 Hafta** |
| **TOPLAM** | **Üretken (Productive) seviyeye gelmek** | **~3 – 4 Hafta (1 Ay)** |

**Özetle:** Günde 2-3 saatlik düzenli bir çalışma ile **1 ay içinde** kendi mobil uygulamanızı sıfırdan yazıp API’lerinizle konuşturacak seviyeye rahatlıkla gelebilirsiniz.

### 1. Frontend: SortableJS ile Menü Yönetimi

Önce CDN üzerinden gerekli kütüphaneyi HTML’ine ekle:

“`html

“`

#### HTML Yapısı:

“`html

• Anasayfa
• Hakkımızda
  • Ekibimiz
• İletişim

Menüyü Kaydet

“`

#### JavaScript:

“`javascript
new Sortable(document.getElementById(‘menu-list’), {
group: ‘nested’,
animation: 150,
fallbackOnBody: true,
swapThreshold: 0.65
});

document.getElementById(‘save-menu’).addEventListener(‘click’, () => {
// Tüm listeyi serialize et ve Go backend’e gönder
const data = getOrder(document.getElementById(‘menu-list’));
fetch(‘/api/menu/save’, {
method: ‘POST’,
body: JSON.stringify(data),
headers: {‘Content-Type’: ‘application/json’}
});
});

“`

—

### 2. Backend: Go (Fiber) Skeleton

Veritabanında menüleri `id`, `parent_id` ve `order` sütunları ile tutman yeterlidir. Go tarafında gelen veriyi karşılayacak ve kaydedecek yapıyı kuralım.

#### Model (GORM):

“`go
type MenuItem struct {
ID uint `json:”id”`
ParentID uint `json:”parent_id”`
Title string `json:”title”`
Order int `json:”order”`
}

“`

#### API Handler (Fiber):

“`go
package main

import (
“github.com/gofiber/fiber/v2”
)

func main() {
app := fiber.New()

app.Post(“/api/menu/save”, func(c *fiber.Ctx) error {
var menuItems []MenuItem
if err := c.BodyParser(&menuItems); err != nil {
return c.Status(400).JSON(fiber.Map{“error”: “Geçersiz veri”})
}

// Veritabanı işlemi:
// 1. Transaction başlat (db.Begin())
// 2. Mevcut menüyü temizle veya update et
// 3. Gelen yeni sıralamayı döngüyle veritabanına işle

return c.JSON(fiber.Map{“status”: “success”})
})

app.Listen(“:3000”)
}

“`

### Kritik İpuçları:

1. **Serialization:** `SortableJS` ile iç içe listeleri çekerken `nested` yapıyı korumak için `sortable.toArray()` yerine her `li` elemanının verisini (id ve parent) manuel olarak bir `map` içinde toplamanı öneririm.
2. **Veritabanı:** PostgreSQL kullanıyorsan, menüleri getirmek için `WITH RECURSIVE` sorgusunu bir “view” olarak tanımlarsan, Go tarafından menüyü çekmek tek bir satır sürer.
3. **Güvenlik:** Menü kaydetme endpoint’ine mutlaka bir `Auth Middleware` ekle ki herkes menüleri değiştiremesin.

Bu skeleton üzerinden ilerleyerek, `sortable.toArray()` fonksiyonunun döndürdüğü veriyi `JSON` olarak backend’e nasıl parse edeceğin konusunda bir örneğe ihtiyaç duyarsan detaylandırabilirim. Hangi veritabanı kütüphanesini (GORM, sqlx vb.) kullanıyorsun?

İşte Türkçedeki gibi Özne – Nesne – Yüklem dizilimine sahip olan başlıca diller:

### Asya Dilleri

* **Korece:** Japonca ile birlikte Türkçeye dilbilgisi (sondan eklemelilik ve SOV yapısı) olarak en çok benzeyen dillerden biridir.
* **Moğolca:** Dil yapısı ve mantığı açısından Türkçeye son derece paralel bir dildir.
* **Hintçe ve Urduca:** Hint-Avrupa dil ailesinden olmalarına rağmen cümle dizilimleri SOV şeklindedir.
* **Tibetçe ve Birmanca:** Çin-Tibet dil ailesine mensup olmalarına rağmen (örneğin Mandarin Çincesi genellikle SVO iken) bu diller SOV yapısını benimsemiştir.

### Hint-Avrupa ve Orta Doğu Dilleri

* **Farsça:** Hint-Avrupa dil ailesinden olmasına rağmen tıpkı Türkçe gibi Özne-Nesne-Yüklem dizilimi kullanır (Örn: *Man sib mikhoram* – Ben elma yiyorum).
* **Kürtçe ve Peştuca:** İrani diller kolundan olan bu dillerde de temel yapı SOV’dur.
* **Latince:** Günümüz Avrupa dilleri (İngilizce, İspanyolca, Fransızca vb.) genellikle Özne-Yüklem-Nesne (SVO) kullansa da, Avrupa dillerinin en önemli atalarından olan Klasik Latince büyük oranda SOV dizilimine sahipti (Örn: *Lupus ovem edit* – Kurt koyunu yer).

### Diğer Önemli Örnekler

* **Baskça:** Avrupa’daki diğer dillerin kökenine uymayan, İspanya-Fransa sınırındaki bu izole dil de SOV yapısını kullanır.
* **Tamilce (ve diğer Dravid dilleri):** Güney Hindistan’da konuşulan bu köklü diller de aynı dizilimi takip eder.
* **Diğer Türk Dilleri:** Doğal olarak Azerbaycan Türkçesi, Kazakça, Özbekçe, Kırgızca, Tatarca gibi diller de birebir aynı yapıya sahiptir.

—

> **Ortak Bir Özellik:** Özne-Nesne-Yüklem (SOV) dizilimi kullanan dillerin çok büyük bir kısmında yapısal bir mantık ortaklığı vardır. İngilizcedeki gibi “preposition” (ön takı / *in* the house) kullanmak yerine, Türkçedeki veya Japoncadaki gibi “postposition” (son takı / ev-*de*) kullanırlar. Ayrıca bu dillerde sıfatlar neredeyse her zaman nitelenen isimden önce gelir (*kırmızı araba* gibi).

———–

Macarca (Ural dil ailesine mensuptur) bu konuda oldukça ilginç ve özel bir örnektir.

Macarca, Türkçedeki gibi katı bir **Özne-Nesne-Yüklem (SOV)** kuralına sahip değildir. Hatta İngilizcedeki gibi katı bir SVO (Özne-Yüklem-Nesne) kuralı da yoktur.

Macarca, **esnek (serbest) kelime dizilimine** sahip ve **”odak (vurgu) merkezli”** bir dildir.

### Macarcada Kelime Dizilimi Mantığı

Macarcada cümlenin ögelerinin yeri, **neyi vurgulamak istediğinize** göre sürekli değişir. Kural basittir: **Vurgulanmak istenen kelime daima fiilden (yüklemden) hemen önce gelir.**

Örneğin “Peter elmayı yiyor” cümlesini ele alalım:

* **Nötr (Vurgusuz):** *Péter eszi az almát.* (Péter yiyor elmayı – **SVO**)
* **Elmayı vurgulamak (Başka bir şeyi değil, elmayı):** *Péter az almát eszi.* (Péter elmayı yiyor – **SOV**, Türkçe ile aynı dizilim)
* **Peter’i vurgulamak (Başkası değil, Peter):** *Az almát Péter eszi.* (Elmayı Péter yiyor – **OSV**)

Gördüğünüz gibi, Macarcada kelimelerin yerini değiştirmek cümlenin dilbilgisini bozmaz, sadece cümlenin hangi sorunun cevabı olduğunu (vurguyu) değiştirir.

### Neden Türklere Çok Tanıdık Gelir?

Macarca kelime dizilimi açısından esnek olsa da, dilin iç işleyiş mantığı **Türkçe ve Japonca ile neredeyse birebir aynıdır.** Bu yüzden bir Türk için Macarca öğrenmek, bir İngiliz’e kıyasla çok daha kolaydır. İşte başlıca ortak noktalar:

* **Sondan Eklemeli Yapı (Aglutinatif):** Tıpkı Türkçe ve Japonca gibi ekler kelimenin sonuna gelir. Ön takı (preposition) yoktur, son takı (postposition) vardır.
* *Ház* (Ev) -> *Ház-ban* (Ev-de)

* **Ünlü Uyumu:** Türkçedeki büyük/küçük ünlü uyumu kuralının çok benzeri Macarcada da bulunur. Ekler, kelimedeki seslilerin kalın veya ince oluşuna göre değişir.
* **Cinsiyet Ayrımı Yoktur:** İspanyolca, Fransızca veya Arapçadaki gibi eril/dişil kelimeler yoktur. “O” zamiri için İngilizcedeki (he/she/it) ayrımı yoktur, sadece **”ő”** (o) kullanılır.
* **Yokluk İfadesi:** İngilizcede “var değil” mantığı kullanılırken, Macarcada tıpkı Türkçedeki gibi “var” (*van*) ve “yok” (*nincs*) kelimeleri ayrıdır.

Özetle; Macarca nötr halinde genellikle SVO’ya (Özne-Yüklem-Nesne) eğilim gösterse de, gerektiğinde Türkçe gibi SOV (Özne-Nesne-Yüklem) dizilimine geçebilen, dilbilgisi kuralları olarak Türkçenin Avrupa’daki “uzak kuzeni” gibi davranan bir dildir.

———————

Rusça (Hint-Avrupa dil ailesinin Slav kolundandır), temel ve nötr halinde **Özne-Yüklem-Nesne (SVO)** dizilimine sahiptir. Bu yönüyle standart yapısı İngilizceye benzer, Türkçeden ayrılır.

Ancak tıpkı Macarcada olduğu gibi, Rusçada da kelime dizilimi **son derece esnektir.** Hatta Rusça, dünyadaki kelime dizilimi en serbest olan dillerden biridir. İstediğiniz an cümleyi Türkçe gibi **Özne-Nesne-Yüklem (SOV)** şeklinde kurabilirsiniz ve bu dilbilgisi açısından tamamen doğru kabul edilir.

### Rusçada Kelimelerin Yeri Neden Değişebilir?

Rusçada kelimelerin cümle içindeki görevini (kimin özne, kimin nesne olduğunu) dizilim değil, kelimelerin aldığı **”ismin halleri” (padej sistemi)** belirler.

Kelimenin sonundaki harf değişiminden kimin işi yaptığı, kimin işten etkilendiği belli olduğu için kelimeleri istediğiniz gibi karıştırabilirsiniz. Anlam bozulmaz, sadece **cümlenin vurgusu ve duygusu değişir.**

Örneğin; *”Kedi (Kot) fareyi (mısh) yakaladı (poymal)”* cümlesini ele alalım:

* **Kot poymal mısh (SVO – Nötr):** Kedi fareyi yakaladı. (Standart bilgi verişi).
* **Kot mısh poymal (SOV – Türkçe gibi):** Kedi fareyi *yakaladı*! (Vurgu eylemdedir, kaçırmadı yakaladı anlamı katar).
* **Mısh poymal kot (OVS):** Fareyi *kedi* yakaladı. (Köpek değil, kedi yakaladı vurgusu vardır).

Tüm bu dizilimler günlük hayatta yaygın olarak kullanılır. Rusçada genellikle en önemli veya en yeni bilgi cümlenin **sonuna** saklanır.

### Türkçeden Temel Farkları

Rusça, istediğiniz zaman Türkçe gibi (SOV) dizilebilmesine rağmen dil mantığı olarak Türkçeden çok uzaktır:

* **Bükümlü Dil (Fusional):** Türkçe ve Japoncadaki sondan eklemeli (yapboz gibi ekleri uç uca ekleme) mantığı yoktur. Kelimeler ek alırken kökleri tamamen değişebilir (bükülebilir).
* **Ön Takı (Preposition) Kullanımı:** Türkçede “masanın **üzerinde**” derken yön/konum bildiren ekler kelimenin sonuna gelirken, Rusçada İngilizcedeki gibi kelimenin başına ayrı bir edat olarak gelir (***na* stole**).
* **Cinsiyet (Eril/Dişil/Nötr):** Cansız nesneler dahil her ismin bir cinsiyeti vardır ve sıfatlar, zamirler, hatta geçmiş zaman fiilleri bile bu cinsiyete göre şekil değiştirir.

> **Özetle:** Rusça standart olarak Özne-Yüklem-Nesne (SVO) dilidir. Ancak ismin halleri sistemi sayesinde, duruma ve vermek istediğiniz duyguya göre kelimelerin yerini tıpkı bir Türkçe cümlesiymiş gibi (Özne-Nesne-Yüklem) dizebilirsiniz. Ünlü “Seni seviyorum” cümlesi olan *Ya lyublyu tebya (SVO)* yerine, günlük hayatta tıpkı Türkçe gibi dizilen *Ya tebya lyublyu (SOV)* versiyonunu çok sık duyarsınız.

———

Belarusça (Doğu Slav dilleri kolundandır), dilbilgisi yapısı ve kelime dizilimi açısından **Rusça ile neredeyse birebir aynıdır.**

Farklı dillerin gramer yapılarını kelime kelime analiz edip karşılaştırırken, Belarusçayı yapısal olarak Rusça ile aynı kategoriye koyabiliriz. Temel dizilimi **Özne-Yüklem-Nesne (SVO)** şeklindedir, ancak tıpkı Rusçada olduğu gibi **kelime dizilimi tamamen esnektir.**

### Esneklik ve “İsmin Halleri” (Padej) Sistemi

Belarusçada da kelimelerin cümledeki görevini sıralama değil, aldıkları ekler (ismin halleri sistemi) belirler. Bu nedenle cümleyi Türkçedeki gibi **Özne-Nesne-Yüklem (SOV)** şeklinde dizmek gramer açısından tamamen doğrudur ve eylemi değil de nesneyi vurgulamak için sıkça kullanılır.

Japonca örneğimizdeki “Ben çay içiyorum” cümlesini Belarusça kelime kelime analiz edelim:

* **Standart (Nötr) Dizilim (SVO):** Я п’ю чай *(Ya p’yu çay)* – “Ben içiyorum çay.”
* **Türkçe Gibi (Vurgulu) Dizilim (SOV):** Я чай п’ю *(Ya çay p’yu)* – “Ben çay içiyorum!”

## Kelime Analizi

Cümlenin yapıtaşları şu şekildedir:

* **Я (Ya):** “Ben” (Özne – Yalın hal)
* **п’ю (p’yu):** “İçiyorum” (Yüklem – 1. tekil şahıs şimdiki zaman çekimi. Fiil kökü *піць* yani içmektir).
* **чай (çay):** “Çay” (Nesne – Belirtme hali / Akuzatif. Eril ve cansız bir isim olduğu için kelime yalın haliyle aynı kalır ancak cümle içindeki görevi nesnedir).

## Karşılaştırmalı Tablo

| Dil | Dizilim Mantığı | Örnek (Ben çay içiyorum) |
| — | — | — |
| **Türkçe** | Katı SOV (Özne-Nesne-Yüklem) | Ben çay içiyorum. |
| **Rusça** | Esnek, Nötr SVO | Я пью чай *(Ya pyu çay)* |
| **Belarusça** | Esnek, Nötr SVO | Я п’ю чай *(Ya p’yu çay)* |

### Rusçadan Temel Farkı Nedir?

Yapısal ve dizilimsel olarak Rusçadan farksız olsa da (bükümlü yapı, edat kullanımı, eril/dişil/nötr cinsiyet ayrımı), **kelime dağarcığı ve fonetik** olarak ayrışır.

Tarihsel nedenlerden ve coğrafi yakınlıktan dolayı Belarusçada, Rusçaya kıyasla çok daha fazla Lehçe (Polonyaca) kökenli kelime bulunur. Ayrıca Rusçadaki “T” ve “D” sesleri Belarusçada genellikle “Ts” ve “Dz” olarak daha yumuşak çıkar (buna dilbilimde *dzekanye/tsekanye* denir). Ancak bu fonetik farklar, kelimeleri Türkçe gibi yan yana dizme esnekliğini değiştirmez.

Log formatınıza (`2026/06/26 17:01:31 … exit status 1`) bakılırsa büyük ihtimalle **Go (Golang)** kullanıyorsunuz.

Supabase, bağlantıları yönetmek için varsayılan olarak “Transaction” modunda bir havuz kullanır (genellikle port 6543). Bu modda, uygulamanız bir `prepared statement` oluşturup bunu önbelleğe aldığında (isim: `stmtcache_…`), bir sonraki sorguda havuz size farklı bir arka plan bağlantısı verebilir veya aynı bağlantıyı başka bir işlem için kullanabilir. Bu durum, PostgreSQL’in “bu isimde bir statement zaten var” hatası vermesine sebep olur.

İşte bu sorunu çözmek için uygulayabileceğiniz yöntemler:

### Çözüm 1: ORM / Sürücü Seviyesinde Prepared Statement’ları Kapatmak (Önerilen)

Eğer uygulamanızda çok sayıda anlık bağlantı yapılıyorsa (örneğin serverless/Lambda fonksiyonları), bağlantı havuzunu (Port 6543) kullanmaya devam etmeli ama sürücünüzün statement önbelleğini kapatmalısınız.

**Eğer Go ve GORM kullanıyorsanız:**
Veritabanı bağlantınızı başlatırken `PrepareStmt` özelliğini `false` olarak ayarlayın:

“`go
db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{
PrepareStmt: false, // Bu ayarı false yapın veya tamamen kaldırın (varsayılan false’tur)
})

“`

**Eğer Go ve `pgx` sürücüsünü kullanıyorsanız:**
Bağlantı dizesinin (connection string) sonuna statement cache’i devre dışı bırakacak parametreler ekleyin:

“`text
postgres://postgres.[projeniz]:[şifreniz]@aws-0-eu-central-1.pooler.supabase.com:6543/postgres?default_query_exec_mode=exec

“`

Veya bağlantı dizesinde `statement_cache_capacity=0` parametresini kullanın.

—

### Çözüm 2: Supabase Doğrudan Bağlantısını (Direct Connection) Kullanmak

Eğer uygulamanız uzun süre çalışan (long-running) bir sunucuda çalışıyorsa ve bağlantı sınırlarını aşma riskiniz yoksa, Supabase’in bağlantı havuzunu bypass edip doğrudan veritabanına bağlanabilirsiniz. Doğrudan bağlantılarda prepared statement’lar sorunsuz çalışır.

Supabase Dashboard’dan alacağınız bağlantı dizesindeki portu **6543** yerine **5432** olarak değiştirin:

* **Hata veren bağlantı (Pooler):** `[…pooler.supabase.com:6543/postgres](https://…pooler.supabase.com:6543/postgres)`
* **Sorunsuz çalışacak bağlantı (Direct):** `[…db.supabase.com:5432/postgres](https://…db.supabase.com:5432/postgres)`

*(Not: Supabase yakın zamanda pooler altyapısını güncelledi, eğer yeni Supavisor kullanıyorsanız host adresi aynı kalıp sadece port 5432 olarak değişebilir. Dashboard -> Database -> Settings -> Connection String altından “Direct Connection” seçeneğini kopyalayabilirsiniz.)*

**Özetle:** Supabase pooler (6543) kullanıyorsanız driver’ın statement önbelleğini kapatın. Eğer önbelleği kapatamıyor veya kapatmak istemiyorsanız, doğrudan bağlantı portunu (5432) kullanın.

Bu kredinin verilme sıklığı ve API kullanım mantığı şu şekildedir:

### 1. Krediler Aylık mı Yoksa Bir Seferlik mi?

Bu krediler **AYLIK** olarak yenilenir.
Sistem şu şekilde işler:

* Seçtiğiniz Google AI Ultra paketine göre her ay hesabınıza **40$ veya 100$** değerinde Google Cloud kredisi tanımlanır.
* **Kritik Kural:** Bu aylık krediler bir sonraki aya devretmez. O yüzden o ay içinde projenizde, veri tabanlarınızda veya API isteklerinizde bu krediyi sonuna kadar harcayabilirsiniz.

—

### 2. Gemini API’ye Bağlanırken Dikkat Etmeniz Gerekenler

Daha önce bahsettiğimiz gibi, bu ücretsiz Cloud kredisini Gemini API için harcamak istiyorsanız **kesinlikle Google Cloud Vertex AI** API kapısını kullanmalısınız.

* **Neden Vertex AI?** Aldığınız bu krediler bir Google Cloud promosyon kodudur. Google Cloud Console (`console.cloud.google.com`) üzerindeki faturalandırma (Billing) hesabınıza tanımlanır. Vertex AI da doğrudan bu faturadan düştüğü için **istekleriniz tamamen ücretsiz kredinizden karşılanır.**
* **Neden AI Studio Değil?** API anahtarınızı (API Key) direkt Google AI Studio (`ai.google.dev`) üzerinden alıp oraya kredi kartı bağlarsanız, harcamalarınız kartınızdan nakit olarak çekilir; Google Cloud kredileriniz orada geçerli olmaz.

—

### 💡 Özetle

Google AI Ultra abonesi olduğunuzda, her ay düzenli gelen **40$/100$’lık bulut kredisini** Vertex AI üzerinden Gemini modellerine (`Gemini 3 Pro`, `Gemini 3 Flash` vb.) bağlanmak için gönül rahatlığıyla kullanabilirsiniz. Bu sayede hem Antigravity IDE içindeki yerel limitleriniz artar hem de dışarıda geliştirdiğiniz kendi yazılım projelerinizin yapay zeka harcamalarını tamamen Google’a ödetmiş olursunuz.

Bu eksikliği fark etme sürecimi adım adım şöyle özetleyebilirim:

**1. “Burada Hatalar Var” Sözü Üzerine İlk Hipotezler**
Siz bana `”burada hatalar var, tekrar düzenle”` dediğinizde ilk iş olarak arka planda `go build ./…` ve `go vet ./…` komutlarını çalıştırdım. Kod hiçbir derleme veya sözdizimi (syntax) hatası vermedi. Derleme hatası olmadığına göre sorunun **mantıksal (logical)** veya **eksik bir entegrasyon** olduğunu anladım.

**2. Veri Akışını (Data Flow) Zihnimde Canlandırma**
Sisteminize yeni alanlar (`Word`, `RootAndStructure` vb.) eklemiştik. Bir verinin dışarıdan (API veya form) gelip veritabanına yazılma yolculuğunu düşündüm:
`HTTP Handler -> App Service -> Domain Model -> Outbound Adapters (Postgres, Mongo vb.)`

Domain modeline ve Postgres’e bu alanları eklediğimi biliyordum. Ancak verinin bu iki nokta arasında kaybolabileceği yerleri aramaya başladım.

**3. Uygulama (Service) Katmanındaki Gözden Kaçan Detayı Bulma**
Akışı takip ederek ilk olarak `app/service.go` dosyasına baktım. Gördüm ki `CreateDi` ve `UpdateDi` metotlarında, dışarıdan gelen `input` objesindeki veriler `Di` modeline manuel olarak kopyalanıyordu (`current.Explanation = input.Explanation` gibi). Ancak benim eklediğim yeni alanların hiçbiri burada atanmıyordu! Yani siz formu doldurup göndersiniz bile, Service katmanı bu yeni alanları umursamayıp çöpe atıyordu.

**4. “Service Katmanını Unuttuysam, Başka Neyi Unutmuş Olabilirim?” Sorusu**
Service katmanındaki bu eşleştirmeyi atladığımı fark edince, kendi kendime *”Domain’i ve Postgres’i güncelledim ama demek ki bu modülün dışarıya bağlandığı diğer portları kontrol etmedim”* dedim.

Hemen `adapters/outbound` dizininin içine baktım. Orada sadece `postgres` olmadığını, bir de `mongodb` klasörü bulunduğunu gördüm.

**5. MongoDB’nin Yapısal Farklılığını Hatırlama ve Kontrol**
Golang’de Postgres için `gorm` etiketleri kullanılır ve biz bunu `postgres/repository.go` içinde halletmiştik. Ancak MongoDB tamamen farklı bir NoSQL veritabanıdır ve verileri BSON formatında dökümanlar (documents) olarak tutar. Bu yüzden MongoDB’nin kendi struct’ları (genelde `bson` etiketlerine sahip) ve kendi Mapping (eşleştirme) fonksiyonları (`toDocument`, `toDomain`, `Upsert` işlemleri içindeki `bson.M{}`) olmak zorundaydı.

Hemen `adapters/outbound/mongodb/repository.go` dosyasını açıp okudum ve teorimin doğru olduğunu gördüm: Oradaki `DiDocument` struct’ında ve MongoDB’ye kayıt atan `Upsert` sorgusunda yeni alanların hiçbiri yoktu.

**Özetle:**
Sizin “hata var” uyarınız derleme hatası üretmeyince, dedektif gibi verinin yaşam döngüsünü (Handler -> Service -> Database) adım adım izledim. Service katmanındaki kopukluğu bulunca, mimarinin diğer uç noktalarına da (MongoDB gibi) şüpheyle yaklaştım ve hatanın kök nedenini bu sistematik takip sayesinde fark ettim.

“`bash
git tag -d $(git tag)
“`

Bu komut, yerel repodaki bütün tag’leri tek seferde siler. [git-scm](https://git-scm.com/docs/git-commit)
İstersen önce hangi tag’ler olduğunu görmek için:

“`bash
git tag
“`

Bir remote’daki tag’leri silmek farklı bir işlemdir; bu komut sadece **local** tag’leri kaldırır. [git-scm](https://git-scm.com/docs/git-commit)

– Commit’i geri al, değişiklikleri stage’de tut:
“`bash
git reset –soft HEAD~1
“`

– Commit’i geri al, değişiklikleri working tree’de tut:
“`bash
git reset –mixed HEAD~1
“`

– Commit’i tamamen sil, değişiklikleri de at:
“`bash
git reset –hard HEAD~1
“`

Eğer commit’i remote’a push ettiysen, `reset –hard` yerine çoğu zaman şu daha güvenlidir:
“`bash
git revert HEAD
“`

`git commit –amend` ise son commit’i silmez; son commit’i düzeltmek için kullanılır. [atlassian](https://www.atlassian.com/git/tutorials/saving-changes/git-commit)

“`bash
git push –tags
“`

Belirli bir remote’a göndermek istersen:

“`bash
git push origin –tags
“`

Sadece tek bir tag göndermek için:

“`bash
git push origin
“`

`–tags` tüm local tag’leri yollar; `–follow-tags` ise yalnızca commit’lerle ilişkili annotated tag’leri gönderir. [git-scm](https://git-scm.com/book/en/v2/Git-Basics-Tagging)