3dfilamentci

• Kataloğunu modelleyemeyen genel bir e-ticaret paketinden taşınan uzman bir 3D baskı mağazası.
• Tam bir malzeme ve renk arayan — “PLA mat siyah” — ve doğrudan o varyanta inmek isteyen alıcılar.
• Binlerce varyantı, stoğu ve siparişi yöneten ve Excel’de yaşayan mağaza ekibi.

• Platformun tamamını tek başıma tasarlayıp geliştirdim: NestJS API ve arka plan worker’ı, Next.js mağaza, React admin paneli ve OpenAPI’den üretilen tipli bir istemci.
• Varyant matrisli katalog, SEO’ya göre tasarlanmış varyant adresleri ve yönlendirmeler, Excel içe/dışa aktarma, rezervasyonlu stok defteri, kartlı ödeme (PayTR) ve havale.
• Admin güvenliği — argon2, Redis oturumları, TOTP 2FA, hesap kilitleme, hız sınırları, roller, işlem kaydı — ve Türk mevzuatının istediği kayıtlar: sipariş anlık görüntüsü, izin geçmişi, mesafeli satış sözleşmesi onayı.
• Kod olarak altyapı: Caddy arkasında Docker Compose, gerçek PostgreSQL ve Redis’e karşı CI, GHCR’ye imajlar, tag ile production deploy ve yazılı bir geri alma prosedürü.

1. 1Kataloğu içe aktar

   Ekip bir Excel dosyası yükler; her satır önce doğrulanıp raporlanır, sonra tek transaction’da uygulanır. Dışa aktarılan dosya aynen geri yüklenebilir.

2. 2Ürünü bul

   Türkçe karakter duyarsız arama ya da filtreli kategoriler bir varyant sayfasına götürür: her rengin kendi indekslenebilir adresi var, ağırlık ve çap parametre.

3. 3Sepet ve ödeme adımı

   Fiyat, stok, kargo eşiği ve KDV her seferinde sunucuda yeniden hesaplanır; sözleşme sürümü ve izinler zaman ve IP ile saklanır.

4. 4Öde

   Kart (PayTR iFrame) ya da havale. Stok sipariş anında rezerve edilir, hash’i doğrulanan ödeme bildirimi gelince düşülür.

5. 5Gönder

   Ekip siparişi hazırlanıyor → kargoda (takip no zorunlu) → teslim edildi olarak ilerletir; iadeler stoğu otomatik geri ekler.

1. 01

   Bir framework yerine ticaret çekirdeğini sıfırdan kurmak

   Yerine: Vendure — değerlendirildi, belgelendi, seçilmedi.

   Neden: Admin paneli ayrıca tasarlanıyordu ve veri modelinin ilk günden bir pazaryerine hazır olması gerekiyordu. Odaklı NestJS modüllerine sahip olmak, bir framework’ü bu ikisine göre bükmekten ucuzdu.

2. 02

   Hibrit varyant adresleri

   Yerine: Her varyanta bir sayfa ya da hepsine tek sayfa.

   Neden: Her varyant ekseninin bir rolü var: renk, kendi canonical ve indekslenebilir adresi olan bir sayfa ekseni; ağırlık ve çap aynı sayfada parametre. Trafik renk aramalarında; “1 kg mı 250 g mı” sayfaları ince kopyalar olurdu. Ürün taşınınca eski adresler doğru renge 301 olur, yönlendirme zincirleri düzleştirilir.

3. 03

   Transactional outbox ve worker

   Yerine: Mağaza sayfalarını request handler’dan yenilemek.

   Neden: Her katalog yazımı aynı transaction’da bir olay üretir; BullMQ worker’ı bunları toplu halde mağaza yenilemesine çevirir. Bir istek yarıda kalsa da hiçbir değişiklik kaybolmaz ya da iki kez duyurulmaz — aynı akış pazaryeri senkronunu da besleyecek.

4. 04

   Stoğu siparişte rezerve et, ödemede düş

   Yerine: Stoğu yalnızca ödeme başarılı olunca düşmek.

   Neden: Kilitli satırlarla, asla eksiye düşmeyen bir hareket defteri. İki alıcı son makarayı aynı anda alamaz, rezervasyonlar kendiliğinden düşer ve geç gelen bir ödeme stoğu yeniden rezerve eder ya da siparişi bir insana işaretler.

Tek sunucuda Docker Compose: production ve staging ortak bir edge ağında ayrı projeler olarak çalışıyor. Buradaki her şey benim.

tipli API uç noktası (üretilen istemci)

91

API, mağaza ve adminde test dosyası

200+

mobil Lighthouse performansı, ürün sayfaları

90 → 95

inceleme bulgusu düzeltildi, her biri regresyon testli

30+