نوشته‌ها
وردپرس، PHP اختصاصی و وقتی مشتری به سیستم بزرگ‌تر نیاز ندارد
کار مشتری من با سایت‌های PHP و وردپرس، افزونه‌های اختصاصی، سیستم‌های سبک مدیریت محتوا و ابزارهای کسب‌وکاری روی LAMP شروع شد. آن سال‌ها هنوز مشخص می‌کنند میان وردپرس، افزونهٔ اختصاصی، CMS کوچکِ دست‌ساز، لاراول و یک پلتفرم کامل چطور انتخاب کنم.
کار مشتری از کسب‌وکار شروع می‌شود، نه از پشته
مدت‌ها پیش از پلتفرم‌های امروزی کنوین، کار فریلنسری من در پونیشا دور سایت‌های اختصاصی PHP و وردپرس برای مشتری‌های مشخص می‌چرخید. بعدتر پروژه‌های لاراول، افزونهٔ اختصاصی وردپرس و اتصال به APIهای خارجی هم به آن اضافه شد. تماس مستقیم با مشتری به اندازهٔ خود کد مهم بود: مشتری به‌ندرت در خلأ «یک CMS» می‌خواهد؛ می‌خواهد چیزی منتشر کند، فرایندی را بچرخاند یا کاری تکراری را از حالت دستی دربیاورد.
برای همین کار وردپرس و سایت اختصاصی هنوز روی برآورد سیستم‌های بزرگ‌ترم اثر می‌گذارد. نخستین سؤال فنی این نیست که کدام پشته پرزرق‌وبرق‌تر است؛ این است که چه کسی هر هفته با آن کار می‌کند، چه چیزی را باید بدون صدا کردن توسعه‌دهنده عوض کند و کدام بخش واقعاً منطق کسب‌وکار است و کدام بخش فقط صفحه. پشته‌ای که پیش از این جواب‌ها انتخاب شود، تزئینی است که خودش را معماری جا زده است.
وردپرس واقعاً در چه چیزی خوب است؟
وردپرس وقتی در اوج است که مرکز ثقل کار محتوا باشد و مشتری راه آشنایی برای مدیریتش بخواهد. برای خیلی از سایت‌های کسب‌وکاری این سازش نیست؛ انتخاب درست است. بازسازی انتشار و رسانه و مدیریت معمول صفحه از صفر می‌تواند همان بودجه‌ای را بخورد که باید خرج محتوای واقعی مشتری، طراحی و جزئیات مخصوص کسب‌وکارش می‌شد.
اشتباه این است که همین قدرت را نامحدود فرض کنی. سیستم محتوا را با افزونه و استثنا می‌شود خیلی دورتر از شکل صادقانه‌اش کش داد، اما هر کش‌دادنی هزینهٔ نگهداری دارد. قاعدهٔ من از آن سال‌ها ساده است: وردپرس را برای چیزی به کار ببر که خودش می‌فهمد و نسبت به اولین نقطه‌ای که کسب‌وکار از «انتشار» شبیه «نرم‌افزار» می‌شود، حواس‌جمع باش.
افزونهٔ اختصاصی درز است، نه زباله‌دان
نوشتن افزونهٔ اختصاصی یادم داد دنبال درز بگردم. افزونهٔ متمرکز می‌تواند همان یک رفتار کسب‌وکاری را که وردپرس ندارد اضافه کند و سطح آشنای انتشار برای مشتری دست‌نخورده بماند. نسخهٔ ناسالمش افزونه‌ای است که بی‌صدا به یک اپلیکیشنِ به‌رسمیت‌نشناخته‌شده داخل اپلیکیشن تبدیل می‌شود؛ با قواعدی پخش‌شده میان هوک و قالب و گوشه‌های دیتابیس که هیچ‌کس دلش نمی‌خواهد دوباره سراغشان برود.
APIهای خارجی این مرز را مهم‌تر می‌کنند. وقتی سایت با سرویس دیگری حرف می‌زند، کسی باید تصمیم بگیرد چه چیزی اعتبارسنجی شود، چه چیزی ذخیره شود، شکست یعنی چه و حقیقت دست کدام طرف است. این تصمیم‌ها جای لایهٔ اتصالِ محدود و مشخص‌اند، نه پخش‌شده در رندر صفحه. همین انضباط بعدها به قلب کار بک‌اند و API من رسید؛ پوسته وردپرس باشد، لاراول باشد یا سیستم اختصاصی.
همان درز مشخص می‌کند سایت با چه وقاری می‌تواند بزرگ شود. یک اتصال کوچک تا وقتی یک کار روشن و یک مالک روشن دارد می‌تواند افزونه بماند؛ اما وقتی گردش کار و رفتارِ تلاش دوباره و مجوز و گزارش‌گیری مخصوص خودش را حمل می‌کند، بی‌سروصدا به سرویسی تبدیل شده که فقط برچسب افزونه دارد. زود نامیدن این گذار به مشتری اجازه می‌دهد آگاهانه قدم سرویس یا پلتفرم را بردارد، نه اینکه وسط یک قطعی بفهمد آن «افزونهٔ کوچک» ستون باربر بوده است. تعیین محدودهٔ خوب خیلی وقت‌ها یعنی نگذاری معماری مهم بی‌نام از در پشتی وارد شود.
کی CMS سبک و اختصاصی، پاسخ کوچک‌تر است؟
در سمت LAMP کار فریلنسری، سیستم مدیریت محتوای سبک و ابزار کسب‌وکاری متناسب با نیاز مشتری هم ساختم؛ با PHP، MySQL، Apache و لینوکس. وقتی گردش کار باریک و آن‌قدر مشخص است که پلتفرم عمومی سطح تماس بیشتری از ارزشش می‌آورد، CMS کوچک اختصاصی می‌تواند پاسخ درست باشد: مفهوم کمتر، آموزش کمتر، گزینهٔ بی‌ربط کمتر و ابزاری که دنبال خود کار می‌رود، نه اینکه آدم‌ها را وارد جهان تازه‌ای کند.
اما «اختصاصی» خودبه‌خود یعنی در طول زمان ساده‌تر نیست. از لحظه‌ای که ویرایشگر و مجوز و جریان انتشار و ابزار عملیاتی را خودت بسازی، مالک همه‌شان هستی. برای همین هزینهٔ طول عمر را مقایسه می‌کنم، نه ظرافت روز انتشار را. اگر کار اصلی مشتری انتشار محتواست، وردپرس شاید سیستم کوچک‌تر باشد حتی اگر کدبیسش بزرگ‌تر است؛ اگر کار اصلی یک عملیات تکراری مشخص است، ابزار اختصاصی متمرکز از هر جهت مهمی کوچک‌تر درمی‌آید.
کی وقت رفتن به لاراول یا پلتفرم کامل است؟
نقطهٔ فارغ‌التحصیلی وقتی می‌رسد که سایت خودش به سیستم کسب‌وکار تبدیل شود: حساب‌هایی با مجوز معنادار، فرایندهای وضعیت‌دار، اتصال‌هایی که نباید سرسری خراب شوند یا مسیرهای عملکردی‌ای که معماری خودشان را می‌خواهند. آن‌جا فریم‌ورکی مثل لاراول دیگر «مهندسی بیشتر» نیست؛ ظرف صادقانهٔ کار است. تجربهٔ بعدی‌ام در تسمینو و جاجیگا که در نوشتهٔ لاراول آمده، این مرز را برایم کاملاً ملموس کرد.
همان قضاوت امروز پشت پلتفرم‌های اختصاصی SvelteKit کنوین هم هست. قرار نیست هر سایت مشتری به پلتفرم تبدیل شود؛ سایت حرفه‌ای و پلتفرم محصول و ابزار داخلی مرکز ثقل متفاوت دارند و انکارش در هر دو جهت پول هدر می‌دهد: بروشور بیش‌ازحد ساخته‌شده سخت نگه داشته می‌شود و سیستم کسب‌وکاری کم‌ساخته‌شده دقیقاً وقتی مهم می‌شود، شکننده از آب درمی‌آید.
چک‌لیست تصمیم امروز من
با پنج سؤال شروع می‌کنم: چه کسی محتوا را ویرایش می‌کند و هر چند وقت؟ کدام گردش کار مخصوص همین کسب‌وکار است؟ چه چیزی باید به سرویس بیرونی وصل شود؟ بعد از انتشار چه کسی سیستم را نگه می‌دارد؟ و وقتی ترافیک و مجوز و داده دیگر ساده نبودند چه می‌شود؟ جواب‌ها معمولاً به یکی از چهار گزینهٔ صادقانه می‌رسند: وردپرس همان‌طور که هست، وردپرس با یک افزونهٔ متمرکز اختصاصی، CMS یا ابزار سبک اختصاصی، یا پلتفرمی بر پایهٔ فریم‌ورک. عامل تعیین‌کننده به‌ندرت این است که این ماه چه چیزی سریع‌تر منتشر می‌شود؛ این است که مشتری بعد از رفتن توسعه‌دهندهٔ اصلی از اتاق، کدام گزینه را می‌تواند با آرامش اداره کند، امن نگه دارد و تغییر بدهد.
این مقیاس قضاوت یادگار همان سال‌های پونیشا و Freelancer.com است. ابزارهای فهرست پروژه‌های امروزم تازه‌ترند، اما قاعده عوض نشده: کوچک‌ترین سیستمی را انتخاب کن که بتواند بار کسب‌وکار را بدون وانمود کردن بکشد. اگر نمی‌دانی سایتت کدام سمت این خط است، رزومه‌ام محدودهٔ سیستم‌هایی را نشان می‌دهد که در هر دو سمت خط ساخته‌ام.