ساخت Saas در پنج روز

من خودم را دوست دارم یک چالش خوب گاهی اوقات. نه آن نوع خشمگینی که در کانال MrBeast پیدا می کنید، جایی که آنها از نابرابری اقتصادی در حال رشد سوء استفاده می کنند. اما یک چالش ساده “ایکس چیزی را در مدت زمان Y بسازید”.

من مدت زیادی است که از کارآفرینی ناخواسته رنج می برم. من در مورد آن نوشته‌ام و قبلاً برای درمان آن یک چالش مشابه را امتحان کرده‌ام. تاکنون موفقیت چندانی برای گزارش دادن نداشته ام.

بنابراین، با دوبرابر کردن چالش دیگر، می‌خواستم الگوی راه‌اندازی saas خود را برای چرخش انتخاب کنم و ببینم که در زندگی واقعی چقدر خوب کار می‌کند. من همچنین می‌خواستم در ایجاد ویدیو در یوتیوب بهتر شوم، بنابراین برای افزودن کارهای بیشتر به آنچه که در حال حاضر یک جدول زمانی فشرده است، تصمیم گرفتم یک ویدیو در مورد هر روز از چالش ایجاد کنم.

تصمیم گرفتم در عرض 5 روز یک micro-saas ایجاد کنم.

در پنج روز چه چیزی می توانید بسازید؟

با توجه به رنجی که در بالا ذکر شد، مدت‌هاست که مشترک همه خبرنامه‌هایی هستم که بر روی «ایده‌های تجاری» تمرکز داشتند که می‌توانستم به آن‌ها دست پیدا کنم.

من قبلاً سعی کرده‌ام با نوشتن هر روز 10 ایده که مدت زمان کافی طول کشیده‌اند، آب خلاق خود را به جریان بیاندازم تا فهرستی مناسب از ایده‌های نه چندان مناسب داشته باشم. کل این ایده که ایده ها مهم هستند مدت ها پیش از بین رفت. آنچه مهم است، مانند واقعا مهم است، اجرا و در واقع انجام کاری هر چیزی

من سعی کرده ام این را به دل بگیرم. بیرون بردن چیزها در طبیعت را در اولویت قرار دهید و ببینید چه اتفاقی می افتد. من قصد ندارم استدلال کنم که انجام برخی تحقیقات بازار از قبل و انتخاب امیدوارکننده ترین آنها اتلاف وقت خواهد بود. اما زمانی که تازه شروع به کار کرده اید، احتمالاً نباید زمان زیادی را در اینجا بگذرانید، زیرا هنوز (مثل من) احساس شهودی برای تمرکز توجه خود ندارید. به اطراف نگاه کنید، و ببینید که افراد دیگر در چه کاری انجام می دهند و از آن پول در می آورند. چیزی را انتخاب کنید که با علاقه و مهارت شما مطابقت داشته باشد، سعی کنید یک رقیب ایجاد کنید و آن را از آنجا بگیرید.

به هر حال، به لیست طولانی ایده های نابغه من برگردم. من مدتی را صرف فیلتر کردن ایده‌ها بر اساس میزان صحبت آنها با من و اینکه آیا فکر می‌کردم انجام آن‌ها در 5 روز کاری امکان‌پذیر است یا خیر صرف کردم. محدودیت زمانی به من کمک کرد تا ایده‌های زیادی را کاهش دهم، که بسیاری از آنها شامل به دست آوردن داده‌های زیادی برای از بین بردن بارهای بیش از حد هوش مصنوعی است. بنابراین، من واقعاً چه چیزی را می‌توانم در عرض پنج روز بسازم و نسخه‌ای از آن را ارسال کنم؟

یک وبلاگ بدون کد

طرح بازی

من الان بارها وبلاگ خودم را نوشته و بازنویسی کرده ام. زمانی که به جاوا اسکریپت/تایپ اسکریپت علاقه زیادی داشتم و وب‌سایت «پرتفولیو» خود را با محتوای سبک وبلاگ‌نویسی داشتم، در next.js شروع کردم تا آن را در Rust یاد بگیرم و بازنویسی کنم تا در نهایت فقط در Go مستقر شوم. زبانی که در سالهای اخیر با آن کار کرده ام. من فکر می‌کنم این یکی از بهترین راه‌ها برای توسعه‌دهندگان برای درک نحوه ساخت و ارسال نرم‌افزار است، مخصوصاً در اوایل، زیرا شما را از تمام مراحلی که در ساخت برنامه‌های وب رخ می‌دهد، عبور می‌دهد.

به هر حال، من تجربه کمی در نوشتن نرم افزار وبلاگ نویسی دارم.

من اخیراً شروع به استفاده از Traefik به نفع Caddy برای پراکسی معکوس برنامه هایم کرده بودم. همراه با یک افزونه docker به نام rollout شما اساساً استقرارهای بدون توقف را به صورت رایگان دریافت می کنید. این جرقه ایده ای را ایجاد کرد که چگونه می توانم به راحتی وبلاگ ها را برای مشتریان ایجاد کنم، آنها را به روز نگه دارم و در صورت نیاز دوباره راه اندازی کنم.

من به سادگی یک فایل الگو دارم که برخی از متغیرها را تجزیه می کند، فایل را ایجاد می کند و در یک مکان خاص ذخیره می کند و با اشاره به این فایل، docker-compose را فراخوانی می کند. آسان. این در نهایت چیزی شبیه به این شد:

services:
  blog--id-{{.BlogID}}:
    image: mbvofdocker/the-bloggening:{{.Version}}
    environment:
      - ENV_VAR_1={{.EnvVarOne}}
      - ENV_VAR_2={{.EnvVarTwo}}
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.blog-{{.BlogID}}.loadbalancer.server.port=3333"

من برچسب‌ها و فیلدها را برای اختصار کنار گذاشته‌ام، اما این باید ایده را به شما منتقل کند.

Traefik از کشف و مسیریابی ترافیک به هر وبلاگ مراقبت می کند، گواهی های SSL تولید می کند و وضعیت سلامت هر کانتینر را در نظر می گیرد.

در مرحله بعد، باید راهی برای چرخش سریع وبلاگ ها با طرح های مختلف، تم های رنگی، چیدمان ها و غیره وجود داشته باشد. شاید حدس زده باشید که این چیزی است که در این قسمت از فایل docker-compose بالا اتفاق می افتد: mbvofdocker/the-bloggeing:{{.Version}} و حق با شماست

من برای شروع فقط یک طرح و دو تم رنگی تیره و روشن داشتم. اساسا، من فقط این وبلاگ را که در حال خواندن این مقاله در آن هستید، دوباره ایجاد می کنم، اما به صورت خودکار.

سپس، به راهی نیاز داشتم که بتوانم اطلاعاتی درباره وبلاگ مانند نام، عنوان، توضیحات و غیره دریافت کنم. شاید حتی برخی از شبکه های اجتماعی و هر زمان که کاربر این کار را بخواهد به صورت پویا به روز شود.

اگر اخیراً زمانی را در فضای فناوری گذرانده‌اید، احتمالاً در مورد تبلیغات SQLite و Turso شنیده‌اید. Turso یک نسخه ارتقا یافته از SQLite به نام libsql را منبع باز کرده است که به شما امکان می دهد با استفاده از درخواست های HTTP با پایگاه داده خود صحبت کنید و کپی های خواندنی را تعبیه کنید. ترکیب این دو دقیقا همان چیزی بود که من دنبالش بودم.

بنابراین مولفه ها و طرح در جای خود بود. من از الگوی شروع خود استفاده می‌کنم، برای هر وبلاگی که مشتری ایجاد می‌کند، یک فایل docker-compose ایجاد می‌کنم، ترافیک را با استفاده از traefik به آن هدایت می‌کنم و داده‌ها را از طریق Turso همگام‌سازی/ارائه می‌کنم. اما همانطور که یک مرد خردمند یک بار گفت:

هر کسی تا زمانی که با مشت به دهانش بخورد نقشه ای دارد

پایگاه داده های من کجا هستند؟

من داشتم موارد بالا را سریع کنار هم می گذاشتم، مثل تند تند. من قطعاً می توانم این را در آن 5 روز درست کنم، مشکلی نیست. من یک نسخه آزمایشی داشتم و می‌خواستم همسرم تلاش کند و وبلاگ خودش را ایجاد کند، بنابراین با اشتیاق او را مجبور کردم هر کاری را که انجام می‌داد کنار بگذارد تا بنشیند و یک کاربر آزمایشی به همان اندازه مشتاق باشد.

او جریان ثبت نام را بدون هیچ مشکلی طی کرد. من در این مرحله یک رویکرد بسیار آزادانه برای رسیدگی به خطا در نظر گرفته بودم، که اساساً به این معنی بود که فقط زمانی وارد سیستم می‌شدم که موارد خطا داشته باشند. اما، هیچ اتفاقی نیفتاد. در حال گزارش موفقیت کلی بود و می‌توانستم ببینم که تصویر کانتینر در حال اجرا و سالم است. بنابراین ما به وبلاگ او رفتیم که به صورت محلی در حال ارائه بود mortens-wifes-blog.localhost، aaaaan و هیچ چیز.

نمی‌خواستم او فکر کند که موفقیت مالی که من عملاً از این پروژه تضمین کرده بودم یک رویا بود، دیوانه‌وار به دنبال دلیل آن بودم. روشن می شود، از زمانی که من در نسخه رایگان Turso بودم آنها گاهی اوقات “خوشه” من را به خواب می بردند. با این حال، API آنها هیچ خطایی را برنمی‌گرداند یا متوجه ایجاد نشدن پایگاه داده نشد. کمی سخت است، اما باز هم، نرم افزار رایگان، بنابراین من واقعا نمی توانم شکایت کنم. همچنین، متوجه شدم که تا زمانی که از پایگاه داده خودم برای نگهداری اطلاعات استفاده می کنم، می توانم به راحتی داده ها را با هر وبلاگ از طریق یک نقطه پایانی که با sqlite معمولی باقی می ماند همگام سازی کنم.

من تغییرات را انجام دادم، او را دوباره ثبت نام کردم و همه چیز درست شد. عالیه سپس، سردرد بعدی من (و خیلی بزرگتر): کد خروج 18.

فراخوانی داکر از داخل داکر

من عاشق داکر هستم. محفظه کردن برنامه شما بسیار منطقی است. در این مورد، در نهایت باعث ناامیدی زیادی شد.

همه چیز به صورت محلی کار می‌کرد، اما من خارج از داکر روی دستگاهم توسعه می‌دهم و وقتی به تولید فشار می‌آورم، آن را بسته‌بندی و ارسال می‌کنم. بنابراین فراخوانی docker از برنامه من مشکلی نبود تا زمانی که مجبور شدم این کار را با تصویر docker انجام دهم که به طور خودکار به منابع موجود در سیستم میزبان دسترسی ندارد. این یک راه حل نسبتاً آسان بود، فقط یک حجم را اضافه کنید که حاوی سوکت داکر باشد و شما آماده هستید.

volume:
  - /var/run/docker.sock:/var/run/docker.sock

با این حال، من مدام یک خطای خروج از سیستم دریافت می کردم که تا آخر عمر نتوانستم معنی آن را بفهمم. هیچ چیز از گوگل و درخواست چت جیپیتی حاصل نشد. من حتی Stackoverflow را امتحان کردم بی فایده بود. سپس کل تنظیمات را روی دستگاه محلی خود تکرار کردم، اما همه چیز در docker در حال اجرا بود، جایی که کار می کرد، که باعث شد بیشتر از پاسخ سؤالات داشته باشم.

معلوم شد که من نسخه صحیح تصویر داکر را روی سرور نکشیده بودم تا شروع نشود. به طور معمول، زمانی که تصویری در دسترس نباشد، داکر سعی می‌کند آن را از یک هاب بیرون بکشد. من، نسبتاً ساده لوحانه، فرض کردم که در اینجا هم همین اتفاق خواهد افتاد که البته اینطور نشد زیرا مجوزها متفاوت هستند.

این باعث تأخیر بسیار زیادی می‌شد که من به موقع برای ایجاد تجربه سوار شدن که تمام روز 5 را برای آن صرف می‌کردم، خیلی سخت بودم.

در پایان، من یک نسخه زنده داشتم که به کاربران اجازه می داد ثبت نام کنند، یک وبلاگ ایجاد کنند و چیزی را به صورت زنده ببینند، به عنوان مثال mortens-blog.mbvlabs.com. اما، از آنجایی که در روز 5 خیلی برایم تنگ شده بود، نتوانستم عملکردی را اجرا کنم که به کاربران اجازه می دهد پست های وبلاگ را آپلود یا بنویسند. گفتن اینکه بدون آن ویژگی کار را تمام کردم احتمالاً به آن فشار می آورد، اما خیلی نزدیک شدم و از آن زمان آن را به تنظیمات اضافه کردم. این محصول هنوز نیاز به کار دارد، اما با پشت سر گذاشتن این 5 روز، پایه ای سریع برای ایستادن به آن داد. در گذشته نگر، من احتمالاً این کار را انجام نمی دهم و مجبور می شوم برای هر روز یک ویدیو در مورد آن ایجاد کنم. فقط از نظر ذهنی باید چیزی بسازید و همچنین آن را در داستانی کار کنید که نشان می دهد پیشرفت بسیار دشوار است. شما نمی توانید فقط در روند ساخت و ساز سرعت ببخشید. شما باید کلیپ ها و تکه هایی از ویدیوها را در طول کل فرآیند دریافت کنید. اما فوق العاده سرگرم کننده بود

اما، غذای آماده چیست؟

فوریت خوبه

اعلام تاریخ پایان به صورت عمومی، حتی برای مخاطبان نسبتاً کوچک، در برش دادن به هسته محصول و آنچه مورد نیاز است، بسیار سودمند بود. من چندین بار در طول آن هفته متوجه شدم که برای چیزهایی وقت صرف می‌کنم یا چیزهایی را اضافه می‌کنم که واقعاً در هسته اصلی کاری که می‌خواستم انجام دهم ضروری نیست: به کاربران اجازه می‌دهم به سرعت یک وبلاگ زیبا بسازند و محتوا اضافه کنند.

من فکر می کنم که به طور کلی فوریت چیز خوبی در نرم افزار است. بسیار آسان است که وارد یک تجزیه و تحلیل طولانی مدت از آنچه در حال حاضر در مقابل آنچه در آینده مورد نیاز است، شوید. زمان خود را صرف تمرکز بر زمان حال کنید و ممکن است در آینده برای شما مشکل باشد. زمانی را برای آماده شدن برای آینده صرف کنید و رسیدگی به نیازهای آینده آسان تر خواهد بود. اگر در مورد آن الزامات آینده درست می گویید. و این هسته اصلی آن است، شما باید در مفروضات خود در مورد آینده درست باشید که اکثر مردم به ندرت چنین می کنند. من فکر می‌کنم بهینه‌سازی در حال حاضر به شما امکان می‌دهد چیزی را در دنیای واقعی دریافت کنید که کاربران بتوانند آن را آزمایش کنند و درباره آن بازخورد بدهند. تا زمانی که از شیوه های خوبی مانند اصل مسئولیت واحد، جداسازی نگرانی و YAGNI پیروی کنید، به احتمال زیاد رسیدگی به الزامات آینده مشکل بزرگی نخواهد بود. و، آیا باید چنین باشد و شما نیاز به بازنویسی بسیاری از کدها داشته باشید، آیا این چیز خوبی نیست؟ این بدان معنی است که شما چیزی در مورد دامنه ای که در آن کار می کنید یاد گرفته اید و این در نهایت چیزی است که باید نرم افزار را هدایت کند.

از فکر کردن دست بردارید، چیزهایی را ارسال کنید و ببینید چه اتفاقی می افتد.