অতীতে Psono.com পরিচালিত হতো Odoo v11 দ্বারা। Odoo একটি অসাধারণ CMS, কিন্তু আমরা শিখতে পারলাম যে, আপডেট করা কঠিন। বিশেষ করে তাদের ওয়েবসাইট মডিউল আমাদের পরীক্ষার সময় অনেক সমস্যার সৃষ্টি করেছে। Odoo v11 এর আয়ু ২০২০ সালের শেষ নাগাদ শেষ হবে, তাই আমরা একটি সমাধান খুঁজতে বাধ্য হলাম।
আমরা বিভিন্ন বিকল্প নিয়ে চিন্তা করেছি, হয়তো Odoo v13 এ আপডেট করা এবং সমস্ত কন্টেন্ট ও কাস্টমাইজেশন নিজেই মাইগ্রেট করা, কাউকে আমাদের জন্য মাইগ্রেশন করতে নিয়োগ করা, বা সম্পূর্ণ নতুন একটি CMS এ মাইগ্রেট করা। আমরা সিদ্ধান্ত নিয়েছি যে, Psono.com সম্পূর্ণভাবে মাইগ্রেট করতে হবে এবং আমরা এটি v11 এর পেছনে একটি ফায়ারওয়ালে ব্যবহার করব এবং পরে এটি মাইগ্রেট করব (আমরা এখনও সিদ্ধান্ত নিইনি)।
এই সিদ্ধান্ত নেওয়ার পিছনে কারণগুলো ছিল:
- আমাদের কাছে Psono.com এর জন্য মাইগ্রেট করার মতো খুব সামান্য পরিমাণ কন্টেন্ট আছে। প্রধানত কিছু ব্লগ পোস্ট।
- Odoo v13 এ মাইগ্রেশন দুই বছরের মধ্যে একই সমস্যার পুনরুত্পাদন করবে যখন v13 এর EOL পৌঁছে যাবে, সম্ভাব্য আরও বেশি ডেটা মাইগ্রেট করার জন্য থাকতে পারে।
- আমরা Odoo v11 এর ওয়েবসাইটের কাস্টমাইজেশন ক্ষমতা নিয়ে খুব একটা খুশি ছিলাম না। তাদের টেমপ্লেট ডাটাবেসে সংরক্ষিত হওয়ায় সবকিছু অত্যন্ত জটিল।
- খরচ। কাউকে মাইগ্রেশন করার জন্য নিয়োগ করা আমাদের অন্তত ৫,০০০ মার্কিন ডলার খরচ হবে, সম্ভবত আরও বেশি।
- Odoo এর কমিউনিটি খুব সক্রিয় ছিল, কিন্তু গত কয়েক বছরে লাইসেন্স পরিবর্তন এবং ফাংশনালিটি ও প্লাগইনসমূহকে পেইড সমাধানে মাইগ্রেট করা এবং সবকিছুকে পেওয়ালের পিছনে রাখার সাথে কমিউনিটি মৃত হয়ে গেছে।
- Psono.com প্রধানত একটি স্ট্যাটিক ওয়েবসাইট স্ট্যাটিক কন্টেন্ট সহ। যদি আমাদের ডায়নামিক কন্টেন্ট প্রয়োজন হয় তবে আমরা এটি একটি API এর মাধ্যমে টেনে নিতে পারি।
যাত্রা
মাইগ্রেশন করার সিদ্ধান্ত নেওয়ার পর আমাদের সিদ্ধান্ত নিতে হয়েছিল কোন ফ্রেমওয়ার্ক। ক্লাসিক ফ্রেমওয়ার্ক রয়েছে যেমন হুগো, যার ব্যবহার আমরা করেছি যদিও তাদের ফাংশনালিটি সীমিত। অন্য বিকল্পগুলি অনুসন্ধান করার সময় আমরা কিছু সমাধান খুঁজে পেয়েছি নোড / রিয়্যাক্ট বিশ্বে।
এখানে লিখতে চেয়েছিলাম "চমৎকার সমাধান", কিন্তু আমি মনে করি না বর্তমান ফ্রন্টএন্ড ডেভেলপমেন্টের ভাঙা অবস্থায় কিছু শিরোনামের দাবি করে। ভাঙা শুনছেন? মনে রাখুন সময় যেখানে ডেভেলপাররা একটি ইনডেক্স HTML এবং স্ক্রিপ্ট ট্যাগ দিয়ে jquery লোড করে ওয়েবসাইট তৈরি করতে পারতেন এবং শুরু করতে পারতেন? এখন আপনাকে প্রয়োজন npm বা yarn, আপনাকে বুঝতে হবে package.json, webpack স্ক্রিপ্টস, আধুনিক ফ্রেমওয়ার্ক যেমন angular বা react যা তাদের নিজস্ব ক্লায়েন্ট নিয়ে আসে। JSX বা টাইপস্ক্রিপ্ট। হট রিলোডিং এমন সুবিধা যা নির্ভরযোগ্যভাবে কাজ করে না (ফাইল মনিটর করা হয় না, কিছু পরিবর্তনের ফলে আপনাকে সম্পূর্ণরূপে পুনরায় শুরু করতে হয়, অথবা হট রিলোডিং খুব তাড়াতাড়ি
so you end up killing development servers and waiting minutes for them to be back up (at least in bigger projects). (I miss hitting F5 and then just having everything there without any issues!). Not to mention a new framework or tool at least every half a year where old tools are abandoned daily. I could easily fill pages with me ranting about the current state of frontend development. Anyway, back to the actual topic.
In the absence of sane alternatives the best options (at the time of me writing this) would be next.js and gatsby. At least that's how some articles promoted them. Both are equally popular if you compare Github stars or commits. The only difference that we could spot during an initial evaluation is the requirement of a server component for next.js, while gatsby creates static sites (Please don't kill me now if there is an option to run next.js without active server! :D)
So we played a bit around with Gatsby and it looked fine. As a next step we went ahead and were looking for a theme. Gatsby is a "new" utility, so all themes that we could find were still in a very basic state. Thirty minutes and third bucks later we had a visually appealing theme that covered at least some of the required components and we started modding it.
Hosting options are abundant these days, such as Firebase, Netlify, Cloudflare, Vercel, simple GCP Cloud storage, or AWS Cloudfront. Plus own servers with docker containers running on Kubernetes (had to mention it!). (Remember the old days where you could just rent webspace for 5 dollars a month with PHP and a MySQL DB :D ... but that's for another article...)
After comparing them, reading some reviews, and checking out possible combinations (like Cloudflare in front of Firebase) we initially tried out Cloudflare. As huge fans of their service it was a natural choice, yet sadly their wrangler utility had problems. First it was always throwing an error and then we were not able to authenticate ... The initial errors were gone the next day (maybe a new bash did the trick), yet the authentication problem persisted. I believe that I must have made some error and gave up after a couple of hours reading their documentation and trying different solutions.
Netlify was another candidate, yet you either have to connect it to a git provider and let them build it (we wanted to use GitLab CI) or manually upload the build output. Maybe they have an option somewhere to upload the build output through and API, yet I could't find one. An alternative would have been a repo where we actually push the build output, yet that seemed unnecessary complex... Another problem for me is their pricing model. They charge per member (!!!) a quite substantial amount. Keep in mind that this is for a static website. Statements like "4× bandwidth" trigger bad memories of "fair use webhosting"-times where people would kick you if you use too much...
As fourth service we tried Firebase (which as a benefit is free for our target bandwidth and requests) and everything worked out of the box. Their redirect capabilities are a bit limited, so mapping old URLs to more beautiful ones became a bit tedious but a couple of redirect rules later everything was working. Their pricing seems reasonable and you are charged for server resources. One should stay away from all their extra services to avoid vendor lock in, yet we only needed hosting.
We also briefly checked vercel, yet their requirement to log in with a Github account and then a permission with "Act on my behalf" threw me off even before signing up.
The blog was the most difficulty one to migrate. We ended up copying over all the content manually. That is nothing you should be doing with a bigger blog, yet our blog only had fifteen posts. Gatsby supports multiple mechanisms, yet we wanted something simple that someone without technical background would be able to create new blog posts. We decided to go with markdown and as such had to learn how to instruct gatsby to read markdown pages. The actual mechanism took us about half a day with all image handling. A nice blog post theme and images another half a day.
After migrating all content and further modding the theme heavily we automated our deployment with Gitlab CI, so a simple push would trigger our build pipeline and deploy everything to Firebase.
Why Gitlab and not Github? Github has the lead for historic reasons. They currently have at least 80% of all developers and projects. Gitlab on the other hand delivers features. That's why in the past we decided to go with Gitlab, as there was no real feature development in Github for years. This has now dramatically changed since Microsoft bought Github and Github Actions are a milestone, yet Github still has a long way to go if they want to compete with Gitlab. So for us who host all their projects on Gitlab it was a natural choice to use it for this project too.
The conclusion
And that's where we are now:
- Gatsby as CMS
- Commercial theme
- Markdown powered blog
- Gitlab CI for automated deployments
- Firebase Hosting
We were quite happy with this outcome and the new website looks much better!
