تجارت الکترونیک · مهاجرت بک‌اند
Reniom.com — مهاجرت زنده بک‌اند
جایگزینی بک‌اند Next.js/Prisma یک فروشگاه آنلاین زنده با یک سرویس مستقل Django REST Framework روی ترافیک واقعی — فروشگاه، تسویه حساب، احراز هویت و کل پنل مدیریت اکنون روی API جدید اجرا می‌شوند، بدون هیچ تغییر ظاهری برای خریداران. اکنون در reniom.vercel.app زنده است، همراه با یک دستیار خرید هوشمند داخل فروشگاه.
پشته فناوری
مهاجرت
Reniom در ابتدا روی بک‌اند Next.js/Prisma اجرا می‌شد. این بک‌اند به‌طور کامل با یک سرویس مستقل Django به همراه Django REST Framework روی دیتابیس Postgres اختصاصی خودش در Railway جایگزین شد — مرور فروشگاه، تسویه حساب مهمان، ورود با OTP، صفحه حساب کاربری و کل پنل مدیریت اکنون همگی از طریق API جدید انجام می‌شوند. Prisma به‌طور کامل از فرانت‌اند حذف شد (بدون وابستگی، بدون schema، بدون client)؛ اپلیکیشن Next.js روی Vercel به یک کلاینت خالص API تبدیل شد بدون هیچ تغییر ظاهری برای خریداران. این کار در چند فاز روی ترافیک زنده انجام شد: ساخت اسکلت و بازسازی مدل‌ها، خواندن اطلاعات فروشگاه، سبد خرید و تسویه حساب، احراز هویت واقعی با OTP (جایگزین یک stub موقت توکن)، آپلود تصویر مخصوص کارکنان روی یک Railway Volume (جایگزین Vercel Blob)، یک اسکریپت مهاجرت داده یک‌باره و ایدم‌پوتنت از دیتابیس قدیمی Prisma، انتقال فروشگاه، CRUD مخصوص کارکنان و در نهایت تسویه حساب مهمان، تماس و پروفایل — که در همان نقطه Prisma به‌طور کامل کنار گذاشته شد.
چه چیزی این انتقال را ایمن کرد
چند تصمیم بود که این انتقال را روی ترافیک واقعی و زنده عملی کرد: هر مدل از یک کلید اصلی UUID استفاده می‌کند (مطابق با رشته‌های مبهم cuid() خود Prisma، تا شکل شناسه‌ای که کلاینت می‌بیند هرگز عوض نشود)؛ تسویه حساب مهمان به‌جای شناسه‌ی دیتابیس از slug محصول استفاده می‌کند، چون سبدهای خریدی که پیش از انتقال در مرورگر ذخیره شده بودند شناسه‌های قدیمی Prisma را داشتند که در طرح جدید به هیچ‌چیز اشاره نمی‌کردند؛ وضعیت سفارش PENDING عمداً بازتعریف شد تا به‌جای «یک سفارش ثبت‌شده» (معنای قدیمی)، معنای «این سبد خرید زنده‌ی مشتری است» را بدهد، و اسکریپت مهاجرت یک‌باره ردیف‌های PENDING با معنای قدیمی را به CONFIRMED نگاشت کرد تا تاریخچه‌ی سفارش‌ها درست بماند؛ و احراز هویت پنل مدیریت روی سیستم کاربری خود Django و با یک بررسی صریح is_staff بازسازی شد، تا نشست OTP یک مشتری هرگز نتواند وارد یک نشست مدیریتی شود.
رنیوم چه می‌فروشد
فراتر از بک‌اند، خود رنیوم یک فروشگاه واردات مستقیم است: کالای اصل که از ایتالیا و ترکیه خریداری و به یک انبار در ایران آورده می‌شود، بدون واسطه‌های معمول فروش. کاتالوگ چهار دسته را پوشش می‌دهد — آرایشی و بهداشتی، پوشاک و کفش، لوازم حیوانات خانگی، و یک دسته‌ی سوپرمارکت/خانه — که همه با قیمت تومانی و از موجودی داخلی به فروش می‌رسند.
دستیار خرید رنیوم
«دستیار خرید رنیوم» یک دستیار گفت‌وگومحور داخل فروشگاه است، پشت یک ویجت شناور: خریدار همان چیزی را که می‌خواهد به فارسی روان می‌گوید — «یک کرم مرطوب‌کننده برای پوست خشک می‌خوام» دقیقاً همان مثالی است که خود دستیار به‌عنوان راهنما نشان می‌دهد — و از بین محصولات واقعی کاتالوگ، بهترین گزینه‌ها را پیشنهاد می‌دهد. پشت این دستیار یک مدل زبانی بزرگ (Claude از Anthropic) قرار دارد که به‌جای پاسخ دادن بر اساس یک حدس ثابت، می‌تواند خودش جست‌وجوهای تکمیلی انجام دهد و فقط اجازه دارد محصولاتی را پیشنهاد بدهد که واقعاً پیدا کرده. برای کاربران تازه‌وارد هم چند پیشنهاد آماده در همان ابتدا نشان داده می‌شود، تا ویجت با یک کادر خالی باز نشود.
عملیات فروش، عمداً مدل‌سازی‌شده
سفارش‌های ویژه (واردات سفارشی) یک چرخه‌ی عمر پنج‌مرحله‌ای و قابل‌پیگیری را طی می‌کنند — ثبت درخواست، پرداخت بیعانه، خرید، رسیدن به انبار، ارسال؛ سفارش‌های عادی پرداخت‌بعد‌از‌تأیید هستند و هنوز مرحله‌ی پیش‌پرداخت آنلاین وجود ندارد؛ مرجوعی و تعویض کالا تا ۷ روز کاری پس از تحویل امکان‌پذیر است؛ و ثبت نظر برای یک محصول فقط برای مشتری‌ای ممکن است که همان کالای مشخص را واقعاً سفارش داده و تحویل گرفته — محدودیتی که در سطح دیتابیس اجرا می‌شود، نه فقط یک قانون نمایشی در فروشگاه.
