وبیتو هسته تجاری را از فروشگاهی که آن را نمایش میدهد جدا کرده، همین معماری هدلس است، اما خودِ فروشگاه را هم ارائه میدهد، بنابراین هدلس رفتن به معنای سفارش دادن یک پروژه فرانتاند پیش از شروع فروش نیست. شما با قالبهای رندرشده در سمت سرور شروع میکنید که با توکنهای طراحی و بهصورت بصری قابل تغییرند، و اگر بعداً ظاهر اختصاصی خواستید، آن را روی همان API فروشگاهی میسازید که قالبهای آماده هم از آن استفاده میکنند، در حالی که کاتالوگ، مالیات، سفارش و منطق عمدهفروشی روی پلتفرم میماند.
معاوضه همیشگی هدلس
پلتفرمهای هدلس کلاسیک یک API و یک صفحه سفید به شما میدهند: تا کسی فرانتاند نسازد چیزی نمایش داده نمیشود و بعد از آن هر تغییر محتوا از مسیر برنامهنویس میگذرد. فروشگاهسازهای سنتی هم فروشگاهی میدهند که عملاً نمیتوانید از آن بیرون بیایید. موضع وبیتو ارائه هر دو طرف است: یک فروشگاه واقعی از روز اول، و APIی که جایگزینکردن آن را یک پروژه عادی میکند نه یک مهاجرت.
توکن طراحی، نه کد قالب
تغییر ظاهر با توکنها انجام میشود: رنگ، فونت، گردی گوشهها و فاصلهها: که بهصورت بصری ویرایش میشوند و در همه صفحاتی که قالب رندر میکند یکدست اعمال میشوند. این همان بخشی است که فروشندگان واقعاً میخواهند تغییر دهند و لازم نیست به تمپلیت دست بزنند؛ نتیجه هم منسجم میماند نه مجموعهای از CSSهای موردی. پنل و فروشگاه هر دو فارسی و راستبهچپ هستند، بنابراین چیدمان چیزی نیست که بعداً وصله شود.
صفحه و محتوا، بدون سیستم دوم
صفحات فرود، محتوای تحریریه و وبلاگ با دستهبندی بخشی از خود فروشگاه هستند نه سیستمی جدا با ورود جداگانه. صفحات از بلوکها ساخته میشوند، محتوا برای زبانهای فعال قابل ترجمه است و همهچیز در سمت سرور رندر میشود تا قابل ایندکس باشد: با متادیتای هر صفحه، آدرس canonical و داده ساختاریافته.
وقتی سراغ ظاهر اختصاصی رفتید
API فروشگاه و وبهوکها مستند هستند و همان رابطیاند که قالبهای آماده مصرف میکنند، پس فرانتاند اختصاصی یک مسیر ویژه با رفتار متفاوت نیست. محاسبه مالیات، پردازش سفارش، قیمتگذاری عمده و صدور فاکتور روی پلتفرم میماند و شما فقط همان لایهای را صاحب میشوید که واقعاً میخواستید صاحبش باشید.