Laravel kullanarak çok satıcılı bir e-ticaret pazaryeri nasıl kurulır

Pazar yeri, birden fazla kiracıya (tenant) sahip bir sistemdir ve bu sistem ürün satışı yapmaktadır. Bu cümle, tüm uygulama problemini tek bir cümlede özetler. Satıcı paneli planlama aşamasında zor görünse de, asıl zorluk üçüncü haftada ortaya çıkar; çünkü sistemdeki her sorgu bir anda yeni bir soruyla cevaplanmak zorundadır. Bu verinin sahibi kimdir? Hangi satıcı bu ürüne, bu sipariş satırına, bu stok seviyesine, bu fiyat seviyesine sahiptir? Vitrin asla sorun değildi. Sorun, bir pazar yerinin ilk tablodan itibaren çoklu kiracılı olmasıdır; çoğu mağaza ise tek kiracılıdır.

Yani yapacağınız ilk karar, çoğu durumda yüksek maliyeti olan bir karardır: kendi çoklu kiracılığınızı mı inşa edeceksiniz, yoksa zaten var olan bir arka ucu mu kullanacaksınız? Tek kiracılı bir mağazaya izolasyon eklemek, üzerine bir özellik ekleyeceğiniz bir şey değildir — bu, keşfettiğiniz bir yeniden yazımdır. Modeller, sorgular, sepet ve yönetici üzerinden vendor_id geçirirken, unuttuğunuz her yer bir veri sızıntısı haline gelir; bir satıcı diğer satıcının siparişlerini görür. Bu kılavuz, mevcut olanı kullanmaktansa, çoklu kiracılı bir veri modeli barındıran Aimeos üzerinden inşa etmeyi öneriyor ve zamanınızı altyapı yerine pazaryeri üzerinde harcıyorsunuz.

Çoklu Kiracılığın Nerede Olacağına Karar Verin

Herhangi bir koddan önce, temeli dürüstçe seçin; çünkü bu, önümüzdeki ay ne kadar süreyle izolasyona harcayacağınızı belirleyecektir.

Kendin inşa et beyaz tahtada en ucuz gibi görünür ama en pahalı olandır. Çoklu kiracılık, her model, her birleşim, her rapor ve her API uç noktası üzerinde bir kesişen konudur. Maliyet, yazdığınız kapsamlanma kodu değil; unuttuğunuz bir maddeyle ilgilidir. Bir birleşimde kaybolan bir filtre, bir satıcının diğerinin siparişlerini okumasına neden olur ve bunu üretimde bulursunuz, inceleme sırasında değil. Ayrıca, bitmiş halde kalmaz. Eklediğiniz her özellik, kendi izolasyonunu yeniden kazanmak zorundadır, bu yüzden sonunda bir yan proje olarak çoklu kiracılık çerçevesini işletmek durumunda kalırsınız.

Tek kiracılı mağaza + ek geliştirme, sorunu taşımakta ancak çözmemektedir. Temel, bir satıcıyı varsaydığı için, uzantı satıcı sütunları ve filtreleri tasarıma ekler. İzolasyon, veri katmanının disiplini yerine, uzantının disiplininde yaşar; ve uzantının hatırladığı yerlerde tutulur, temel mağazanın direkt eriştiği yerlerde sızabilir: yönetim araçları, ihracatlar ve satıcılarla ilgili bilgilere sahip olmayan üçüncü taraf eklentileri. Üstelik ekin sürüm döngüsünü ve fiyatını devralırsınız, ve onun platform ile uyumlu kalacağına güvenirsiniz.

Bu kılavuzun geri kalan kısmı, izolasyonun veri modeli özelliği olarak yer aldığı üçüncü satıra dayanmaktadır; her adım bir bayrak veya küçük bir yapılandırma miktarıdır, değilse bir sprint değil.

Arka Ucu Kurun

PHP 8.2+ ve bir veritabanına (MySQL, MariaDB, PostgreSQL veya SQL Server) ihtiyacınız var. Dağıtım, vitrini, yönetim panelini, API’leri ve önceden tohumlanmış bir kataloğu tek bir komutla bağlar.

composer create-project aimeos/aimeos myshop

Veritabanı, mail ve admin hesabı için geçerli yanıtları verin, ardından biraz etrafa bakın:

cd myshop
php artisan serve

Vitrin http://127.0.0.1:8000, yönetici http://127.0.0.1:8000/admin adresinde. Bu noktada, çalışan bir tek mağazaya sahipsiniz. Sonraki iki adım bunu bir pazar yerinde dönüştürecektir.

Çoklu Satıcı Modunu Aktif Hale Getirin

Çoklu satıcı mekanizması kutuda gelir. Bunu .env dosyasında tek bir satırla açın:

SHOP_MULTISHOP=true

Bu, her satıcıya kendi kapsamlı vitrini ve arka ucu ile birlikte kendi sitesini verir – Aimeos’un kiracı için olan terimi. Bayrakların ne yaptığını yönlendirmede görebilirsiniz: Her rota, URL’deki satıcıya göre kapsamlanmıştır, böylece vitrin, JSON:API, yönetim panelleri ve satıcıların kendi arka uçları bununla sınıflandırılır.

'admin'    => ['prefix' => 'admin/{site}/jqadm',   'middleware' => ['web', 'auth', 'verified']],
'graphql'  => ['prefix' => 'admin/{site}/graphql', 'middleware' => ['web', 'auth', 'verified']],
'jsonapi'  => ['prefix' => '{site}/jsonapi',       'middleware' => ['web', 'api']],
'default'  => ['prefix' => '{site}/shop',          'middleware' => ['web']],
'supplier' => ['prefix' => '{site}/s',             'middleware' => ['web']],

{site} yer tutucu estetik URL’ler için değildir. Bir satıcının yönetim panelinin diğerine ulaşmasını engelleyen gezi, API’ye kadar uzanır.

Satıcıların Kendilerini Kayıt Etmelerine İzin Verin

Her satıcı hesabını elle oluşturmak, bir demo fazını aşamaz. Kendin kayıt olmayı açın:

SHOP_REGISTRATION=true

Yeni kaydolmuş bir satıcı, yalnızca kendi sitesi üzerinde yöneticilik haklarına sahip olur — kendi kataloğu, siparişleri, müşterileri ve ayarları tamamen kendisine aittir. Eğer bu, yeni kaydolan bir satıcıya vermek istemediğiniz bir güçse, varsayılan izin seviyesini düşürebilirsiniz:

SHOP_PERMISSION=editor

Ve eğer “admin” ya da “editor” varsayımları düşündüğünüz erişime uyuyorsa, izin setleri de yapılandırma olarak mevcut. Yönetici kaynak yapılandırmanızı yayınlayın ve her rolün hangi panelleri ve eylemleri incelemesine izin vereceğinizi tam olarak belirleyin. Platform yöneticisi kök kalır; satıcılar sadece kendilerine verilen alanı alır.

Edindiğiniz İzolasyonu Anlayın

İki bayrak yeterince bilgi veriyor, böylece sonucu güvenilirlik kazanır ve sürekli kontrol etmek zorunda kalmazsınız. SHOP_MULTISHOP=true ve SHOP_REGISTRATION=true ayarlarını yaptıktan sonra, birkaç satıcı hesabı oluşturun, her birine giriş yapın ve basit olanı doğrulayın — her biri diğerinin kataloğunu veya siparişlerini göremez ve bu olmadan da bir kapsamlandırma maddesi yazılmamıştır.

Yaşayan ön uç demo ve yönetici demo isterseniz mevcut, belgeler çoklu satıcı setini baştan sona kapsar ve pazar yeri eklentisi ise komisyon ve ödeme katmanının bulunduğu yerdir.

Bir pazar yerinin uygulanması, aslında zaten mevcut olması gereken kısımları uygulamamak hakkında. Tasarımı çok kiracılı olan bir arka uç ile başlayın ve gönderdiğiniz şey pazar yeri olsun — bunun altında bulunan altyapı değil.