In the past Psono.com was driven by Odoo v11. Odoo is a great CMS yet as we had to learn, updates are hard. Especially their website module produced a lot of trouble during our testing. Odoo v11 will reach it's end of life by end of 2020 so we were forced to find a solution.
We thought about different options, either updating to Odoo v13 and manually migrating all the content and customizations ourself, hiring someone to do the migration for us, or migrating away completely to a new CMS. We have decided to migrate Psono.com away completely and will continue to use v11 behind a firewall and migrate it later (we haven't decided yet).
The reasons behind that decision were:
- We only have a very small amount of content that we would need to migrate for Psono.com. Mainly some blog posts.
- A migration to Odoo v13 would reproduce the same problem in two years when v13 reaches its EOL potentially with a lot more data to migrate.
- We were not too happy with the customization capabilities of Odoo v11's websites. Everything is extremely complex with their templates being stored in the database.
- The costs. Hiring someone to do the migration would cost us at least 5000 USD, potentially more.
- Odoo's community was very active, yet with the development in the past years of license switches and migrating functionality and plugins to paid solutions and putting everything behind a pay wall the community is dead.
- Psono.com is mainly a static website with static content. If we would need dynamic content we could pull it in with APIs.
The journey
After having the decision to migrate away we had to decide which framework. There are classic frameworks like e.g. hugo that we used yet their functionality is limited. While looking for alternatives we found some solutions in the node / react world.
I wanted to write here "excellent solutions", yet I don't think that anything in the current broken state of frontend development deserves that title. Broken you ask? Remember the times where developers could create a website with an index.html and script tag to load jquery and were able to start developing websites? Now you need npm or yarn, you need to understand package.json, webpack scripts, modern frameworks like angular or react which all bring their own client with them. JSX or typescript. Features like hot reloading do not work reliably (file not monitored, some modifications need a full restart, or hot reloading is triggered too early so you have to manully refresh anyway) 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.
As hosting option you can choose nowadays between multiple providers, namely Firebase, netlify, Cloudflare, Vercel, simple GCP Cloud storage or AWS Cloudfront, own servers, docker containers running on Kubernetes (I had to mention it!), ... (Remember the old times where you would just rant a webspace for $5 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!
