Alleycat: ব্লগের সিএমএস নতুন করে তৈরি করা হয়েছে

নমস্কার, আমি অযোগ্য।
আমি ব্লগের সিএমএস নতুন করে তৈরি করার চেষ্টা করেছি।
GitHub - haturatu/alleycat: cms & frontend · GitHub

শেষ পর্যন্ত এত কিছু তৈরি করার পর মনে হতে পারে যে ওয়ার্ডপ্রেস ব্যবহার করলেই ভালো হতো, তবে কিছু বিষয় আছে।

কেন তৈরি করা হলো

আমার ব্লগটি মূলত 2020 সালের দিকে ওয়ার্ডপ্রেস থেকে LumeCMS-এ স্থানান্তরিত হয়েছিল, এবং মূল স্থানান্তরের উদ্দেশ্যগুলি ছিল নিম্নরূপ:

• ওয়ার্ডপ্রেস

  • অনেক মেমরি ব্যবহার করে

  • শুধুমাত্র একটি ব্যক্তিগত ব্লগের জন্য MySQL হোস্ট করা অতিরিক্ত

  • বৈশিষ্ট্য সম্প্রসারণ সম্পূর্ণরূপে প্লাগইন নির্ভর

  • CSS ইত্যাদি প্রায়শই বিশৃঙ্খল হয়ে পড়ে

  • admin এর অধীনে পোর্ট আলাদা করতে না পারায় নিরাপদে পরিচালনা করা কঠিন

  • ছবি কপি-পেস্ট করে সরাসরি পেস্ট করা খুব সহজ ছিল

  • সমস্ত ছবির জন্য থাম্বনেইল আকারের ছোট ছবি তৈরি করা হয়, যা অপ্রয়োজনীয় সম্পদ তৈরি করে

• LumeCMS

  • বেশ মেমরি ব্যবহার করে

  • এটি একটি SSG CMS হওয়ায়, প্রতিটি নিবন্ধ আপডেটের জন্য সবকিছু বিল্ড করা পরিবেশ-বান্ধব ছিল না

  • ছবি কপি-পেস্ট করে সরাসরি আপলোড করা যায় না

  • এর সরলতা অসাধারণ ছিল

  • আসলে, শুধুমাত্র markdown ব্যবহার করে লেখা কোনো সমস্যা ছিল না, তবে স্মার্টফোন থেকে আপডেট করার সময় এটি বেশ কঠিন ছিল

উপরের মতো বিষয়গুলি ছিল।

প্রয়োজনীয়তা

সুতরাং, প্রয়োজনীয়তাগুলি নিম্নরূপ:

• সিএমএস নিজেই পোর্ট অনুযায়ী আলাদা করা যায়

• ছবি কপি-পেস্ট করে আপলোড করা এবং লিঙ্ক তৈরি করা

• স্মার্টফোন থেকেও সম্পাদনা করা সহজ ডিজাইন

• যতটা সম্ভব CSS ন্যূনতম রাখা যায়

  • শেষ পর্যন্ত এটি অনিবার্যভাবে বাড়বে

  • বাহ্যিক নির্ভরতা CSS বাড়লে এটি বোঝা কঠিন হয়ে পড়ে, তাই যতটা সম্ভব এড়াতে চাই

• JS ছাড়াই ফ্রন্টএন্ড দেখা যায়

  • পারফরম্যান্সের দিক থেকে স্ট্যাটিক বিল্ড অপরিহার্য, এবং আমি w3m ব্যবহারকারীদের জন্য বন্ধুত্বপূর্ণ একটি স্পেসিফিকেশন চেয়েছিলাম, যা আমি এখনও মাঝে মাঝে ব্যবহার করি

• TOC অপরিহার্য

  • এটি থাকলে পঠনযোগ্যতা অনেক বেড়ে যায়

  • তবে, আগে Lume এর TOC নিজেই h2 থেকে শুরু হতো কেন? ভেবেছিলাম, কিন্তু শিরোনামের সমতুল্য TOC এ অন্তর্ভুক্ত না হওয়াটা কিছুটা বোধগম্য হতে পারে?

  • তবে কেন যেন Lume শুধুমাত্র h3? পর্যন্তই লক্ষ্য ছিল

    • সম্ভবত ডিজাইন ভেঙে যাওয়ার প্রবণতা বেশি বলে?

• এডিটরটি রিচ এডিটর এবং md থাকলে সহজ হয়

  • স্মার্টফোন থেকে সম্পাদনার জন্য

• এখন DB এর গুরুত্ব বুঝতে পারছি

বাস্তবায়ন প্রসঙ্গে

ব্যক্তিগতভাবে, Pocketbase ব্যবহার করা বেশ সহজ ছিল, তাই আমি এটি গ্রহণ করেছি। ডেটা ব্যাকআপের জন্য আলাদাভাবে কিছু বাস্তবায়ন না করেও, স্ট্যান্ডার্ড ওয়েব UI থেকে ব্যাকআপ zip ফাইল সংরক্ষণ করা যায়।

গোপনীয় তথ্য পরিচালনাও Pocketbase দ্বারা সুন্দরভাবে বাস্তবায়িত হয়েছে, যা খুব সহজ। DB সম্ভবত SQLite।

এছাড়াও, আমি বহুভাষিক সমর্থন বাস্তবায়ন করতে চেয়েছিলাম, কিন্তু বাধা খুব বেশি ছিল। তাই, Gemini API নিবন্ধন করে বহুভাষিক সমর্থন সক্ষম করার সিদ্ধান্ত নিয়েছি।

এমনকি গুগল ট্রান্সলেটেও ব্রাউজারের উপরের দিকে গিয়ে অনুবাদ বোতাম টিপতে হয়, এবং বিভিন্ন ডকুমেন্টেশন পৃষ্ঠা দেখে আমার মনে হয়েছে যে এটি থাকলে ভালো হয়। তবে, এটি শুধুমাত্র নিবন্ধ পৃষ্ঠাগুলির জন্য।

যদি এত বেশি পরিবর্তন করা হয়, তাহলে কি ব্লগ সাইটটি পরিবর্তিত হবে? অথবা, ব্লগ লেখক কোন দেশের দৃষ্টিকোণ থেকে লিখছেন তা জানতে আগ্রহী, তাই জাপানিরা জাপানি হিসাবে About পৃষ্ঠার মতো কিছুতে আগ্রহী হতে পারে এবং আমি অন্য পৃষ্ঠাগুলির জন্য এর প্রয়োজনীয়তা অনুভব করিনি।

inode সংখ্যা বা ডিস্ক I/O এর সমস্যা

SSG-তেও একই ধরনের সমস্যা রয়েছে, বিল্ডের পরে ফাইলের সংখ্যা বাড়লে ডিস্ক I/O তীব্রভাবে স্ক্যান করা হয়। না না, inode শেষ না হওয়া পর্যন্ত নিবন্ধ বাড়বে না... এই ধরনের মন্তব্য বাদ দিয়ে, আমি অপ্রয়োজনীয় ডিস্ক r/w অপারেশন বাড়াতে চাই না।

এই বিষয়ে, বিল্ডের পরের পাবলিক ডেটার জন্য ততটা স্থায়িত্বের প্রয়োজন নেই। তাই

$ rg tmp
backend/ssr/config.go
13:     staticExportDir  = getEnv("STATIC_EXPORT_DIR", "/tmp/alleycat-static")

এভাবে, ডিফল্টরূপে /tmp এর অধীনে আউটপুট করে, স্ট্যাটিক বিল্ডের পরের ফাইলগুলি RAM-এ স্থাপন করে বিতরণ করা হয়।

ছবি ডেটা সংরক্ষণের স্থান

মূলত, আমি ওয়েব এডিটর থেকে কপি-পেস্ট করে ছবি আপলোড করতে চেয়েছিলাম, এবং যতটা সম্ভব এক্সপোর্ট নিজেই নিবন্ধ এবং ছবির সেটের মধ্যে সামঞ্জস্য বজায় রাখতে সহজ হয়, তাই আমি বাইনারিগুলি সরাসরি Pocketbase এ রাখার সিদ্ধান্ত নিয়েছি।

এটি কিছুটা কেমন... এমন প্রশ্নও উঠতে পারে, তবে ছবির ফাইলগুলি যে ফোল্ডারে সংরক্ষিত আছে তা দেখার প্রয়োজন আমার কখনও হয়নি, এবং এটি জটিলতা দূর করার জন্য। এছাড়াও, Pocketbase এ যাচাই করা সহজ হওয়ার সুবিধাও পাওয়া যাবে বলে মনে হয়েছিল, তাই আমি এটি করেছি।

চূড়ান্ত সম্পদ: 500MiB এর নিচে

আমার মনে হয় এটি বেশ ভালো হয়েছে।

বিল্ড করার সময় উপরের ছবির মতো দেখায়, তবে স্ট্যান্ডবাই রিসোর্স প্রায় এইরকম। এটি প্রায় 150MiB বা তার নিচে স্থিতিশীল হয়।

সিএমএস সহ এই রিসোর্স দিয়ে এটি বাস্তবায়ন করতে পারাটা ভালো ছিল, এবং Codex দিয়ে ফ্রন্টএন্ড ডিজাইনের দিকটা কতটা উন্নত করা যায় তা নিজেও পরীক্ষা করে দেখতে চেয়েছিলাম, তাই আমার মনে হয় এটি একটি ভালো পরীক্ষা ছিল।

তাহলে আবার দেখা হবে। শুভেচ্ছা রইল।