30 Bin Satır React Koduyla Çoklu Satıcı Pazar Yeri Nasıl Kurulur?

Çevrimiçi alışveriş siteleri için hazırlanan birçok eğitim, ürün listesinden ödeme bölümüne kadar olan standart süreci kapsar. Ancak gerçek zorluk, aynı uygulamada üç farklı kullanıcı grubunu — müşterileri, satıcıları ve yöneticileri — gerçek zamanlı olarak birbirine bağlarken verilerin karışmasını önlemektir.

Ben de DEV Community’de yayınlanan bir dizi yazıda, Ecommerce adlı çok satıcılı pazar yerimi baştan inşa ederken karşılaştığım bu zorlukları ve 30.000 satır React kodu deneyimimi sizlerle paylaştım. İşte bu süreçte öğrendiklerim.

Tek Uygulama, Üç Farklı Kullanıcı Arayüzü

Tek bir satıcının olduğu bir e-ticaret sitesi basit bir uygulamadır. Oysa çok satıcılı bir pazar yeri, veri tabanını paylaşan üç ayrı uygulamadan oluşur:

• Müşteriler, ürünleri görüntüler, satın alır ve satıcılarla sohbet eder

• Satıcılar, kendi mağazalarını yönetir, siparişleri yerine getirir ve ödeme taleplerinde bulunur

• Yöneticiler, herkesi denetler — satıcıları onaylar, anlaşmazlıkları çözer ve ödemeleri serbest bırakır

Tecrübesiz geliştiriciler, bu üç grubu tek bir App.js dosyası içinde if (kullaniciTuru === 'yönetici') gibi koşullarla yönetmeye çalışır. Bu yaklaşım kısa sürede karmaşık hale gelir ve bakımı imkansızlaşır. Bunun yerine, her kullanıcı grubu için tamamen bağımsız kimlik doğrulama sistemleri oluşturmak daha güvenli ve ölçeklenebilir bir çözümdür:

<Route element={<KorunanMusteriYolu />}>...</Route>
<Route element={<KorunanSaticiYolu />}>...</Route>
<Route element={<KorunanYoneticiYolu />}>...</Route>

Her yol koruyucu bileşeni, kendi oturum durumunu bağımsız olarak kontrol eder. Bir satıcı oturumu, URL’de manuel müdahaleyle bile yönetici görünümüne sızdırılamaz.

Özel Sunucuya Gerek Kalmadan Gerçek Zamanlı Sohbet

Müşteriler ve satıcılar arasında anlık mesajlaşma sistemi kurmayı hedefledim. Sayfa yenilemesi ya da aralıklı sorgulama yerine, Firestore’un gerçek zamanlı dinleyicilerini kullandım. Bu tercih, projenin ölçeği için doğru bir karardı:

onSnapshot(
  query(mesajlarRef, orderBy('zamanDamgasi')),
  (anlikVeri) => {
    // Yeni mesajlar geldiğinde arayüz anında güncellenir
  }
);

Bu tek desen, sohbet sistemini, okunmamış mesaj sayaçlarını ve kullanıcıların çevrimiçi olup olmadığını yönetmek için kullanıldı — hiçbir özel WebSocket sunucusu kurmadan.

"Çevrimiçi" Durumunu Doğru Yönetmek

Bir satıcının "çevrimiçi" olduğunu göstermek basit gibi görünse de uygulama yaparken ciddi sorunlarla karşılaşılıyor. Basit bir cEvrimici: true bayrağı, kullanıcı bilgisayarını kapattığında bile aktif kalır — sonsuza kadar "çevrimiçi" olarak görünür.

Bu sorunun çözümü, kalp atışı deseni adı verilen bir yöntemdir: Satıcının tarayıcısı açıkken her birkaç saniyede bir sonGorulme zaman damgası güncellenir. Tarayıcı kapandığında veya görünmez hale geldiğindeyse bu işlem durur:

document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    kalpAtisiDurdur();
  } else {
    kalpAtisiBaslat();
  }
});

Başkaları satıcı profilini görüntülerken sadece son kalp atışı zamanına bakar: Son kalp atışı ne kadar yakın bir tarihte gerçekleşti? Bu sayede sunucu tarafında cron görevi çalıştırmaya ya da "çevrimiçi" durumunda kalıcı hayaletlere yer vermeden sorunu çözmüş oluruz.

Medya Dosyalarını Veri Tabanında Saklamamak

İlk aşamalarda, resimleri doğrudan veri tabanında saklamak gibi basit bir hata yaptım. Bu yaklaşım ölçeklenebilir değildir — Firestore belgeleri boyut sınırlamalarına sahiptir ve büyük base64 kodlanmış blob’lar yükleme hızını öldürür.

Çözüm, tüm yüklemeleri Cloudinary üzerinden yönlendirmekti. İmzasız yükleme ayarlarını kullanarak, API gizli anahtarını istemci tarafında saklamadım:

formVerisi.append('upload_preset', cloudinaryAyarlar.yuklemeAyarı);
const yanit = await fetch(` {
  method: 'POST',
  body: formVerisi
});

Cloudinary, resimleri yeniden boyutlandırır, formatlarını değiştirir ve CDN üzerinden dağıtır — veri tabanı sadece bir URL saklar.

Ödeme Yönetimi: Kimse Konuşmayan Sorun

Satıcıların para kazanmasını sağlamak kolaydır. Ancak parayı güvenli bir şekilde çekmelerini sağlamak çok daha önemlidir. Bu nedenle, bir CekilisTalepleriYoneticisi modülü oluşturdum:

• Bir satıcı para çekme talebinde bulunur

• Talep beklemedeki kuyruğa girer — fonlar otomatik olarak serbest bırakılmaz

• Bir yönetici tarafından manuel olarak incelenip onaylandıktan sonra para hareket eder

Bu manuel kontrol noktası bilinçli bir tercihtir. Ödeme süreçlerini otomatikleştirmek cazip görünse de, ilk dolandırıcılık girişimine kadar her şey yolunda gider. Para hareketinin olduğu her noktada insan müdahalesi en ucuz dolandırıcılık önleme yöntemidir.

İlk Pazar Yerinizi Kurarken Dikkat Edilmesi Gerekenler

• Üç kullanıcı grubunu projenin başından ayırın. Daha sonra rol izolasyonunu tek bir kimlik doğrulama sistemine eklemek acı verici olabilir.

• Özel bir sunucu kurmadan önce veri tabanınızın gerçek zamanlı özelliklerini kullanın. Firestore’un dinleyicileri, ayrı bir gerçek zamanlı servis kurmanın yerini aldı.

• İkili medya dosyalarını yapısal verilerin olduğu yerde saklamayın. Medya dosyalarını hemen özel altyapılara taşıyın.

• Para hareketinin olduğu her noktaya bir insan kontrolü yerleştirin.

Kullanılan Teknolojiler

| Katman | Teknoloji | |--------------|------------------------------------| | Ön uç | React, React Router, Material UI (MUI) | | Veri tabanı | Firebase Firestore, Firebase Kimlik Doğrulama | | Gerçek zamanlı veri | Firebase Realtime Database (varlık durumu) | | Medya | Cloudinary |

Faiz Ullah — Full-Stack Geliştirici & DG Technology Kurucusu 🌐 dgtechnology.online · 💻 faizullah.pk · 📦 github.com/faizullahpk/multivendor-marketplace

Gerçek dünya tam yığın sistemleri inşa ederken karşılaşılan zorluklara dair daha fazla içerik için takipte kalın. Çoklu kullanıcı rollerine ve gerçek zamanlı veriye sahip projeler geliştiriyorsanız, deneyimlerinizi paylaşmaktan çekinmeyin.