Di masa lalu Psono.com didukung oleh Odoo v11. Odoo adalah CMS yang hebat, namun seperti yang kami pelajari, pembaruan cukup sulit. Terutama modul situs web mereka menimbulkan banyak masalah selama pengujian kami. Odoo v11 akan mencapai akhir masa hidupnya pada akhir tahun 2020 sehingga kami dipaksa menemukan solusi.
Kami memikirkan berbagai opsi, baik memperbarui ke Odoo v13 dan secara manual memigrasi semua konten dan kustomisasi sendiri, menyewa seseorang untuk melakukan migrasi untuk kami, atau migrasi sepenuhnya ke CMS baru. Kami telah memutuskan untuk memigrasi Psono.com sepenuhnya dan akan terus menggunakan v11 di balik firewall dan memigrasikannya nanti (kami belum memutuskan).
Alasan di balik keputusan tersebut adalah:
- Kami hanya memiliki sejumlah kecil konten yang perlu kami migrasi untuk Psono.com. Utamanya beberapa postingan blog.
- Migrasi ke Odoo v13 akan mengulang masalah yang sama dalam dua tahun ketika v13 mencapai akhir masa pakainya, berpotensi dengan lebih banyak data untuk dimigrasi.
- Kami tidak terlalu senang dengan kemampuan kustomisasi situs web Odoo v11. Semuanya sangat rumit dengan template mereka yang disimpan dalam basis data.
- Biaya. Menyewa seseorang untuk melakukan migrasi akan memakan biaya setidaknya 5000 USD, mungkin lebih.
- Komunitas Odoo sangat aktif, tetapi dengan perkembangan beberapa tahun terakhir mengenai perubahan lisensi dan migrasi fungsionalitas serta plugin menjadi solusi berbayar dan menempatkan semuanya di balik paywall, komunitasnya mati.
- Psono.com utamanya adalah situs web statis dengan konten statis. Jika kami memerlukan konten dinamis, kami dapat mengambilnya dengan API.
Perjalanan
Setelah mengambil keputusan untuk migrasi, kami harus memutuskan framework mana yang akan digunakan. Ada framework klasik seperti hugo yang pernah kami gunakan, tetapi fungsionalitasnya terbatas. Saat mencari alternatif, kami menemukan beberapa solusi di dunia node/react.
Saya ingin menulis di sini "solusi yang sangat baik", tetapi saya tidak berpikir bahwa ada sesuatu dalam keadaan pengembangan frontend saat ini yang pantas mendapatkan gelar itu. Rusak, Anda bertanya? Ingat masa ketika pengembang bisa membuat situs web dengan file index.html dan tag skrip untuk memuat jquery dan bisa mulai mengembangkan situs web? Sekarang Anda memerlukan npm atau yarn, Anda harus memahami package.json, skrip webpack, framework modern seperti angular atau react yang semuanya membawa client mereka sendiri. JSX atau typescript. Fitur-fitur seperti hot reloading tidak bekerja secara andal (file tidak dimonitor, beberapa modifikasi memerlukan restart penuh, atau hot reloading dipicu terlalu awal sehingga Anda harus menyegarkan secara manual) sehingga Anda akhirnya mematikan server pengembangan dan menunggu beberapa menit agar mereka kembali aktif (setidaknya dalam proyek yang lebih besar). (Saya merindukan menekan F5 dan kemudian semuanya sudah ada tanpa masalah!). Belum lagi framework atau alat baru setidaknya setiap setengah tahun sekali di mana alat lama ditinggalkan setiap hari. Saya bisa dengan mudah mengisi halaman dengan keluhan saya tentang keadaan pengembangan frontend saat ini. Bagaimanapun juga, kembali ke topik sebenarnya.
Dengan tidak adanya alternatif yang baik, opsi terbaik (pada saat saya menulis ini) adalah next.js dan gatsby. Setidaknya begitulah beberapa artikel mempromosikannya. Keduanya sama populernya jika Anda membandingkan bintang atau komit di Github. Satu-satunya perbedaan yang bisa kami temukan selama evaluasi awal adalah kebutuhan komponen server untuk next.js, sementara gatsby membuat situs statis (Tolong jangan marahi saya sekarang jika ada opsi untuk menjalankan next.js tanpa server aktif! :D).
Jadi kami mencoba sedikit dengan Gatsby dan kelihatannya baik-baik saja. Sebagai langkah selanjutnya kami mencari tema. Gatsby adalah utilitas "baru", jadi semua tema yang bisa kami temukan masih dalam keadaan sangat dasar. Tiga puluh menit dan tiga puluh dolar kemudian kami memiliki tema yang secara visual menarik yang setidaknya mencakup beberapa komponen yang diperlukan, dan kami mulai memodifikasinya.
Sebagai opsi penyimpanan, Anda dapat memilih saat ini antara beberapa penyedia, yaitu Firebase, netlify, Cloudflare, Vercel, penyimpanan Cloud GCP sederhana atau AWS Cloudfront, server sendiri, kontainer docker yang berjalan di Kubernetes (harus saya sebutkan!), ... (Ingat masa lalu di mana Anda hanya menyewa webspace seharga $5 sebulan dengan PHP dan database MySQL :D ... tapi itu untuk artikel lain...)
Setelah membandingkan mereka, membaca beberapa ulasan, dan memeriksa kemungkinan kombinasi (seperti Cloudflare di depan Firebase) kami awalnya mencoba Cloudflare. Sebagai penggemar besar layanan mereka, itu adalah pilihan alami, namun sayangnya utilitas wrangler mereka memiliki masalah. Pertama, selalu melempar error dan kemudian kami tidak bisa melakukan autentikasi... Kesalahan awal hilang keesokan harinya (mungkin bash baru yang menyelesaikan masalahnya), namun masalah autentikasi tetap ada. Saya percaya saya membuat kesalahan dan menyerah setelah beberapa jam membaca dokumentasi mereka dan mencoba berbagai solusi.
Netlify adalah kandidat lain, tetapi Anda harus menghubungkannya ke penyedia git dan membiarkan mereka membangunnya (kami ingin menggunakan GitLab CI) atau mengunggah output build secara manual. Mungkin mereka memiliki opsi di suatu tempat untuk mengunggah output build melalui API, tetapi saya tidak dapat menemukan satu pun. Alternatifnya adalah repo di mana kami sebenarnya mendorong output build, tetapi tampaknya terlalu rumit... Masalah lain bagi saya adalah model harga mereka. Mereka mengenakan biaya per anggota (! !!) sejumlah yang cukup besar. Ingatlah bahwa ini untuk situs web statis. Pernyataan seperti "4× bandwidth" memicu kenangan buruk dari masa "webhosting penggunaan wajar" di mana orang-orang akan menendang Anda jika Anda menggunakan terlalu banyak...
Sebagai layanan keempat kami mencoba Firebase (yang sebagai manfaatnya gratis untuk bandwidth dan permintaan yang kami targetkan) dan semuanya berfungsi tanpa masalah. Kemampuan pengalihan mereka terbatas, jadi memetakan URL lama ke yang lebih indah menjadi sedikit membosankan, tetapi beberapa aturan pengalihan kemudian semuanya berfungsi. Harga mereka tampak wajar dan Anda dikenakan biaya untuk sumber daya server. Seseorang harus menjauh dari semua layanan tambahan mereka untuk menghindari ketergantungan vendor, tetapi kami hanya perlu hosting.
Kami juga memeriksa vercel sebentar, tetapi persyaratan mereka untuk masuk dengan akun Github dan kemudian memberikan izin dengan "Bertindak atas nama saya" membuat saya mundur bahkan sebelum mendaftar.
Blog adalah yang paling sulit untuk dimigrasi. Kami akhirnya menyalin semua konten secara manual. Itu bukan sesuatu yang harus Anda lakukan dengan blog yang lebih besar, tetapi blog kami hanya memiliki lima belas postingan. Gatsby mendukung beberapa mekanisme, tetapi kami menginginkan sesuatu yang sederhana sehingga seseorang tanpa latar belakang teknis dapat membuat postingan blog baru. Kami memutuskan untuk menggunakan markdown dan oleh karena itu harus belajar bagaimana menginstruksikan gatsby untuk membaca halaman markdown. Mekanisme sebenarnya membutuhkan waktu setengah hari dengan semua penanganan gambar. Tema postingan blog yang bagus dan gambar membutuhkan setengah hari lagi.
Setelah memigrasikan semua konten dan memodifikasi tema dengan berat, kami mengotomatisasi penyebaran kami dengan Gitlab CI, jadi sebuah push sederhana akan memicu pipeline build kami dan menyebarkan semuanya ke Firebase.
Mengapa Gitlab dan bukan Github? Github memimpin karena alasan historis. Saat ini mereka memiliki setidaknya 80% dari semua pengembang dan proyek. Gitlab, di sisi lain, memberikan fitur. Itulah mengapa di masa lalu kami memutuskan untuk menggunakan Gitlab, karena tidak ada pengembangan fitur yang nyata di Github selama bertahun-tahun. Ini telah berubah secara dramatis sejak Microsoft membeli GitHub dan GitHub Actions adalah tonggak penting, tetapi GitHub masih memiliki jalan panjang jika mereka ingin bersaing dengan GitLab. Jadi bagi kami yang menghosting semua proyek mereka di GitLab, itu adalah pilihan alami untuk menggunakannya untuk proyek ini juga.
Kesimpulan
Dan di sinilah kami sekarang:
- Gatsby sebagai CMS
- Tema komersial
- Blog yang didukung markdown
- Gitlab CI untuk penyebaran otomatis
- Hosting Firebase
Kami cukup senang dengan hasil ini dan situs web baru ini terlihat jauh lebih baik!
