Pergi Tanpa Kepala: Gunakan Kasus Dan Apa Manfaatnya

Artikel ini telah didukung dengan baik oleh teman-teman terkasih kami di Storyblok, CMS tanpa kepala yang ramah dengan editor visual, komponen bersarang, dan blok konten yang dapat disesuaikan untuk situs web dan aplikasi. Terima kasih!

Melihat kembali tahun-tahun pengembangan untuk web, saya telah menggunakan lusinan alat CMS yang berbeda baik dari rak maupun buatan sendiri. Saya telah menerapkan dan membangun banyak situs dan plugin WordPress , serta ekstensi untuk situs CMS layanan lengkap di .NET. Tapi bagi saya, semuanya berubah ketika saya pertama kali mendengar tentang tanpa kepala, dan sekarang, bertahun-tahun kemudian, saya merasa sangat nyaman di ekosistem tanpa kepala .

Antusiasme ini tidak muncul begitu saja. Meskipun mungkin tampak menakutkan untuk memahami semua opsi tanpa kepala, saya telah menyempurnakan strategi saya sendiri untuk opsi tanpa kepala yang berbeda di lingkungan yang berbeda, dan membuat diri saya akrab dengan tersangka biasa di ruang tanpa kepala. Pindah ke headless membantu saya menghindari hambatan yang disebabkan oleh keterbatasan sistem all-in-one yang lebih besar.

Membagi fungsi sehingga Anda dapat memenuhi tujuan yang kompleks hari ini dan mempersiapkan aplikasi Anda untuk berkembang dengan mudah di masa depan memberi saya ketenangan pikiran. Kami senang dapat berkontribusi pada penerapan dan iterasi yang berhasil pada layanan web yang dibangun di atas solusi tanpa kepala untuk perusahaan swasta dan pemerintah negara bagian California.

Dalam artikel ini, saya ingin berbagi beberapa petunjuk dan pedoman berguna yang telah saya pelajari selama bertahun-tahun, dengan harapan mereka akan membantu Anda memahami dunia tanpa kepala, dan menemukan kandidat yang tepat untuk proyek Anda. Tetapi sebelum kita menyelami, kita perlu sedikit mundur ke masa lalu untuk memahami apa yang dibawa tanpa kepala ke meja.

Sebelum Tanpa Kepala

Beberapa tahun yang lalu, alur kerja kami tampaknya berfokus pada berbagai alat, tumpukan, dan teknologi. Untuk CMS, kami kebanyakan menggunakan all-in-one-tools. Mereka menyertakan fungsi pembuatan konten dan tampilan konten.

Pengguna alat ini terjebak dengan ujung depan yang datang dengan backend. Kemampuan Anda untuk menyesuaikan hal-hal terbatas. Anda dapat menginstal plugin tetapi semuanya harus dibuat untuk alat Anda. Anda dapat menulis kode khusus — tetapi hanya dalam bahasa yang digunakan alat Anda dan dalam batasannya.

Semuanya berubah selama beberapa tahun terakhir dengan CMS tanpa kepala mendapatkan daya tarik di seluruh industri.

Renaisans Alat Khusus

Saat ini, kami memiliki beragam alat yang berspesialisasi dalam tampilan penulisan atau presentasi konten. CMS tanpa kepala berfokus pada bagian pembuatan konten dan menyediakan cara untuk menghubungkan alat presentasi konten yang terpisah. Kurangnya frontend yang menghadap pengguna adalah apa yang membuatnya tanpa kepala dan memberikannya fleksibilitas untuk bekerja dengan alat apa pun melalui API-nya.

Mampu merekayasa frontend Anda sendiri dari awal membebaskan banyak tim pengembangan. Anda mungkin memiliki tim insinyur crack yang fasih dalam memberikan aplikasi satu halaman yang apik di Vue.js atau rendering cepat, situs yang dihasilkan statis antipeluru dengan 11ty. Semua kerangka kerja pengembangan web terbaru dirancang untuk bekerja dengan mudah dengan data terstruktur yang dapat disediakan dari CMS tanpa kepala.

CMS tanpa kepala adalah alat yang terfokus. Ini memiliki tanggung jawab yang lebih kecil daripada solusi all-in-one. Titik akhir API yang disediakan oleh CMS tanpa kepala memberikan pemisahan yang bersih antara sistem sehingga Anda dapat menukar arsitektur depan atau belakang secara independen seiring perkembangannya. Produk Anda berkembang, ekosistem alat berkembang, pendekatan baru tersedia. Persyaratan backend dan frontend Anda akan berubah. Jika Anda memiliki pengaturan tanpa kepala, Anda akan dapat beradaptasi dengan lebih mudah karena front dan backend Anda sudah dipisahkan dengan rapi oleh API dan Anda dapat memutakhirkannya secara mandiri.

Apakah Headless Tepat Untuk Saya?

Terutama, headless memberi Anda fleksibilitas yang mungkin Anda perlukan untuk memenuhi persyaratan yang menantang. Mungkin sulit untuk memenuhi tujuan Anda jika Anda harus banyak memodifikasi produk all-in-one. Menggabungkan alat tanpa kepala dengan frontend yang lebih kecil, berbeda, atau buatan sendiri mungkin merupakan cara termudah untuk memberikan desain dan alur pengguna yang Anda inginkan.

• Jika Anda ingin menyempurnakan setiap langkah alur pembayaran produk , Anda dapat menggunakan opsi perdagangan tanpa kepala untuk mencapainya,
• Jika Anda ingin sangat mengoptimalkan Time to First Byte , Anda mungkin ingin menggunakan generator situs statis yang membuat ulang konten berdasarkan perubahan berdasarkan CMS API tanpa kepala,
• Jika Anda menghosting alat Anda sendiri dan berhati-hati tentang keamanan, Anda mungkin ingin mengunci lingkungan penulisan Anda di belakang firewall dan menggunakannya tanpa kepala dari frontend berbasis Jamstack yang lebih sederhana,
• Jika Anda menyajikan konten yang sama ke berbagai klien, seperti web, aplikasi asli, atau widget pihak ketiga, Anda dapat membuatnya sedemikian rupa sehingga semuanya dapat berkomunikasi melalui CMS yang sama tanpa kepala.

Jika Anda dapat memenuhi persyaratan proyek Anda dengan sempurna dengan alat lengkap, maka opsi tanpa kepala mungkin sedikit berlebihan untuk Anda. Dengan cara yang sama, jika tim Anda sangat senang dan berpengalaman dengan solusi lengkap Anda saat ini, Anda tidak perlu khawatir tentang pemisahan perkakas depan dan belakang. Namun, jika sebaliknya, Anda mengalami keterbatasan alat Anda, maka tanpa kepala akan memungkinkan Anda untuk mengatasi masalah Anda secara langsung.

Contoh: eCommerce Tanpa Kepala

Mari kita lihat pilihan headless tertentu: Anda dapat mengintegrasikan platform eCommerce yang ada, seperti Shopify, sebagai alur lengkap yang mengambil alih seluruh proses checkout, atau Anda dapat menggunakan opsi headless yang juga disediakan Shopify.

• Dalam kasus sebelumnya, desain Anda akan sangat bergantung pada template Shopify dan fungsionalitas yang siap pakai , jadi penyesuaian alur pembayaran akan dimungkinkan, tetapi sangat terbatas.
• Dalam kasus terakhir, Anda dapat merancang alur pembayaran Anda dengan cara apa pun yang Anda suka, dan Anda akan mengandalkan Shopify untuk hanya melakukan transaksi keuangan.

Perbedaan yang signifikan adalah bahwa opsi tanpa kepala akan mengharuskan Anda untuk membuat setiap tampilan yang dilihat pengguna Anda. Sekali lagi, jika itu terdengar merepotkan tanpa keuntungan, maka Anda mungkin tidak memerlukan solusi tanpa kepala.

Sebuah tim yang membutuhkan versi tanpa kepala akan menyambut kebebasan yang diberikan ini. Desain Anda tidak akan memiliki kendala, dan Anda akan dapat mengontrol setiap piksel dari setiap tampilan. Anda akan memegang kendali penuh atas semua kode yang dijalankan pada perangkat pengguna Anda, sehingga Anda dapat melacak, mengoptimalkan, dan mempercepat secara harfiah setiap interaksi.

Pada saat yang sama, Anda masih menyerahkan pemrosesan transaksi ke solusi eCommerce tanpa kepala Anda, sehingga Anda mendapatkan manfaat dari sistem backend mereka.

Intinya adalah: jika Anda berjuang dengan kemacetan dalam solusi eCommerce Anda saat ini — baik itu front-end yang berat, UI yang kompleks, atau hanya desain yang tidak dapat diakses — maka opsi tanpa kepala akan memudahkan tim Anda untuk menyelesaikan masalah ini. Demikian pula, jika kedengarannya akan memudahkan tim Anda untuk meningkatkan corong konversi dengan membuat penerapan fitur baru lebih cepat dan lancar, maka sebaiknya pertimbangkan juga opsi tanpa kepala.

Menghindari Lock-In Dengan Satu Platform

Melihat keadaan front-end hari ini, memisahkan kendaraan authoring dan pengiriman konten Anda adalah cara teraman untuk merancang berbagai hal di dunia di mana opsi untuk alat front dan backend terus berkembang. Bukan hal yang aneh bahwa lingkungan penulisan dan pembacaan memiliki kumpulan persyaratan yang berbeda, sehingga dapat memilih alat yang menangani ini secara terpisah memberi Anda opsi yang lebih baik untuk kedua sisi.

Penyiapan berbasis jamstack diaktifkan oleh API sehingga sering dikaitkan dengan CMS headless. Membuat pilihan tanpa kepala tidak memerlukan front-end Jamstack . Tentu saja, Anda masih dapat menjalankan beberapa kode sisi server jika Anda mau.

Misalnya, saya telah membantu membangun beberapa situs yang menjalankan Node.js dan Express yang menggunakan API back-end seperti Wordnik.com dan pola populer ini bekerja dengan lancar. Memiliki akses ke data Anda melalui API memungkinkan untuk membuang kode sisi server Anda dalam produksi, sehingga Anda dapat dengan mudah merangkul pendekatan sisi klien seperti Jamstack jika itu masuk akal dalam proyek Anda.

Masalah dengan solusi "all-in-one" adalah bahwa masing-masing dari mereka memiliki banyak komitmen yang tertanam di dalamnya. Misalnya, Anda harus berkomitmen untuk mendukung database dan lingkungan pemrograman atau memilih dari vendor SaaS yang melakukannya; juga, perubahan desain Anda harus terjadi dalam tema dan plugin yang tersedia.

Dengan tanpa kepala, kami keluar dari terkunci dalam satu platform. Jadi, jika Anda perlu menggunakan kerangka kerja front-end baru untuk situs web Anda, atau Anda ingin menghapus infrastruktur produksi yang mahal dan menggunakan generator situs statis, atau mungkin ingin mengganti CMS Anda tanpa membangun kembali semua front-end Anda dari awal — dibandingkan dengan alternatif , Anda dapat mencapai semuanya dengan gesekan yang jauh lebih sedikit saat Anda menggunakan opsi tanpa kepala.

Mari kita lihat contoh sederhana. Bayangkan organisasi Anda muncul dengan inisiatif baru dan desain baru, dan alur dibuat dari awal untuk melayani kebutuhan pengguna baru. Tiba-tiba tumpukan teknologi baru perlu dirakit untuk memenuhi persyaratan ini.

Memilih opsi tanpa kepala akan membuat produk Anda lebih tahan lama, dan membuatnya lebih mudah untuk memindahkan konten Anda ke beberapa saluran pengiriman dengan lancar.

“

Dalam kasus seperti itu, Anda harus mencari solusi siap pakai yang sempurna sesuai dengan kebutuhan Anda, atau mengkompromikan beberapa desain dan persyaratan aliran pengguna sehingga berfungsi dengan cukup baik. Tetapi jika persyaratan desain atau kinerja Anda ketat, mungkin lebih mudah untuk memenuhi tujuan ini dengan tanpa kepala.

Intinya adalah bahwa ada banyak kasus penggunaan saat memilih opsi tanpa kepala yang akan memberikan produk Anda kesempatan yang lebih baik untuk umur panjang , serta membuatnya lebih mudah untuk membiarkan konten Anda berpindah ke beberapa saluran pengiriman dengan lancar. Mampu menggunakan konten Anda sebagai data terstruktur memungkinkannya berkembang di situs web Anda sendiri, di aplikasi asli Anda, dan disindikasikan ke sumber eksternal.

Tidak Semuanya Harus Tanpa Kepala

Mungkin terdengar bahwa tanpa kepala selalu merupakan pilihan yang lebih baik, tetapi sebenarnya tidak. Jika dalam proyek Anda saat ini, Anda tidak terlalu peduli dengan desain dan opsi teknis yang dijelaskan di atas, atau Anda hanya memerlukan situs web operasional yang berfungsi hari ini, maka Anda mungkin tidak perlu terlalu banyak menggunakan headless.

Tentu saja, kecepatan dari konsep hingga pengiriman adalah penting, jadi karena Anda hanya berjarak beberapa klik dari situs web yang tampak layak tanpa dukungan teknik yang tepat di pihak Anda, Anda mungkin ingin menunda opsi tanpa kepala untuk lain waktu. Anda dapat fokus pada pengoptimalan situs dan umur panjang setelah Anda merasa ide Anda mungkin berhasil.

Bagaimana Pilihan Tanpa Kepala Membantu Anda Pulih Dari Kesalahan Langkah

Memutakhirkan Backend

Bahaya Harga Per Pengguna

Beberapa waktu lalu, saya membantu membuat sistem blogging yang akan digunakan oleh puluhan penulis. Kami sangat terkesan dengan rangkaian fitur dari salah satu vendor CMS headless, memilihnya untuk CMS headless dan menikmati membangun frontend di atasnya yang menyatu dengan mulus ke dalam rangkaian produk kami. Akhirnya, perusahaan memutuskan bahwa jumlah penulis harus diperluas menjadi beberapa ribu.

Sebagian besar solusi CMS yang dihosting tidak mempublikasikan struktur harga untuk jumlah pengguna sebesar ini. Ketika kami menanyakan tentang biaya untuk melanjutkan menjalankan ini pada platform yang sama, kami tidak begitu menyukai jawabannya. Agar sistem ini terus masuk akal secara bisnis, kami harus menukar CMS kami. Kami dapat melakukan swap tanpa menghapus frontend juga karena arsitektur tanpa kepala.

Pembatasan API

Begitu banyak perusahaan rintisan yang berfokus murni pada lingkungan penulisan yang mampu membangun produk yang indah dengan API yang ramah pengembang. Airtable adalah contoh inovasi spreadsheet melalui UI yang ramah pengguna yang dikombinasikan dengan pengalaman pengembang yang bersih melalui API yang terdokumentasi dengan baik.

Saya membangun beberapa prototipe yang berguna di mana saya memasukkan data yang tergores ke Airtable yang diedit oleh ahli manusia, kemudian menggunakan API mereka untuk memberi daya pada tampilan konten yang berjalan di situs utama dan dalam penyematan yang berjalan di situs pihak ketiga. Saat menyiapkan sistem baca , saya menarik data Airtable ke dalam sistem siap produksi yang dapat menangani beban lalu lintas yang besar dan ini bekerja dengan baik untuk sementara waktu.

Saya mulai mengalami masalah dengan penulisan data. Panggilan gagal karena batas keras 5 permintaan per detik. Mencapai batas ini memberikan penguncian permintaan API lengkap selama 30 detik. Saya mencoba mengirim data dari sistem terdistribusi jadi saya menambahkan throttle dan membaginya menjadi basis terpisah.

Saat sistem berkembang dan jumlah data bertambah, kami melampaui alat ini. Saya dapat mengatasi ini dengan membangun fitur pengeditan data dasar ke dalam sistem berdasarkan instans AWS DynamoDB yang telah membaca dari airtable. Kami dapat dengan cepat menukar fitur UI authoring Airtable yang apik untuk skala yang lebih besar dan tagihan SaaS bulanan yang lebih rendah.

Ini adalah contoh lain tentang bagaimana pemisahan yang bersih antara frontend dan backend yang disediakan oleh API alat pembuat tanpa kepala memungkinkan Anda menargetkan titik nyeri dengan tepat.

Meningkatkan Frontend

Kerangka Kerja Baru yang Mengkilap

Organisasi yang telah ada untuk sementara waktu sering memiliki masalah kebutuhan untuk mendukung sistem produksi yang dibangun di atas berbagai tumpukan teknologi . Ada tekanan konstan untuk menyeragamkan perkakas tetapi juga untuk berinovasi. Saya adalah bagian dari tim yang ditugaskan untuk membangun tampilan dan widget yang akan diintegrasikan ke dalam produk yang ada berdasarkan CMS tanpa kepala. Kami bersenang-senang dengan cepat membangun prototipe dengan alat frontend ringan yang berbeda.

Kami menjalankan kontes internal untuk melihat teknisi mana di tim frontend yang dapat menyiapkan frontend terbaik berdasarkan konten yang dikirim dari endpoint CMS API tanpa kepala. Satu presentasi memiliki kumpulan fitur terbaik dan jejak kode terkecil sehingga pengembang mendapatkan proyek dan mengirimkan produk dengan membangunnya dengan Riot.js.

Riot.js adalah perpustakaan kecil yang keren yang mengemas banyak fitur ke dalam ukuran kecil. Ini membantu Anda menulis komponen file tunggal berbasis data seperti Vue.js. Ketika pengembang frontend ini meninggalkan perusahaan tidak lama setelah pengiriman versi 1.0, tim kehilangan satu-satunya orang yang antusias dengan perpustakaan itu.

Terkadang penurunan dari pola pengembangan yang menarik, baru, dan cepat ke utang teknologi terjadi dengan cepat.

“

Untungnya, sifat terpisah dari arsitektur CMS headless memberikan fleksibilitas untuk mengubah frontend Anda tanpa menyentuh backend . Kami dapat menulis ulang kode front-end dan menukar komponen front-end yang diperbarui berdasarkan pustaka berbeda yang lebih umum digunakan pada proyek lain.

Kecepatan mentah

Saya suka proyek Ghost. Saya adalah pelanggan awal karena itu keren untuk melihat solusi seperti WordPress yang dibangun di Node.js. Saya menghormati organisasi ini karena menawarkan layanan yang dibangun di atas alat sumber terbuka yang terus mereka perbaiki. Saya sangat senang dengan alat ini ketika saya menggunakannya untuk blog pribadi saya.

Ada satu aspek dari solusi yang tidak sempurna sekalipun. Waktu untuk Byte Pertama di blog saya yang dihosting oleh Ghost terlalu lambat. Karena saya dapat mengambil semua konten posting melalui API, saya dapat mengatur frontend saya sendiri yang dihasilkan secara statis di S3 + Cloudfront yang menggunakan semua konten posting yang telah saya tulis di Ghost tetapi memiliki waktu yang lebih cepat untuk byte pertama.

CMS Tanpa Kepala Sebagai Layanan

Ada banyak bisnis Perangkat Lunak Sebagai Layanan yang telah melakukan segalanya tanpa kepala. Mendaftar dengan salah satu vendor ini dapat segera memberi Anda lingkungan pengeditan konten yang ramah dan titik akhir API yang bersih untuk digunakan. Berikut adalah perbandingan singkat dari beberapa dari mereka yang semuanya memiliki rencana tingkat awal yang sangat murah dan fokus laser pada pengalaman CMS tanpa kepala.

Semua layanan ini memiliki serangkaian fitur dasar yang solid . Semuanya termasuk hosting aset statis, riwayat revisi yang disimpan, dan dukungan pelokalan yang terdokumentasi dengan baik. Mereka berbeda dalam antarmuka pengguna pembuatan konten dan fitur API.

Pola Tanpa Kepala yang Menyenangkan

Menggunakan CMS Berbasis GitHub

Mampu memanfaatkan manajemen pengguna, kontrol versi, dan alur kerja persetujuan di GitHub adalah keuntungan besar. Akan sangat membantu jika Anda tidak perlu membuat akun baru di sistem baru. Mampu melihat riwayat ulasan di samping pembaruan konten itu bagus.

Ada berbagai macam alat CMS berbasis GitHub. Ini adalah cara cepat untuk memutar situs dokumentasi: Spacebook Anda dapat mengintegrasikannya dengan Netlify untuk mendapatkan UI pengeditan penurunan harga yang lebih bersih atau menggunakannya langsung di GitHub.

Fitur pratinjau yang sekarang ada di editor web GitHub membuat beberapa alat ini lebih mudah diakses oleh orang yang tidak terbiasa dengan HTML. Saya suka opsi perbedaan tampilan kaya di mana GitHub menunjukkan perubahan penurunan harga dalam mode pratinjau penuh.

Ini adalah daftar yang sangat baik dari 85 alat CMS yang memungkinkan Anda untuk mengurutkan apakah mereka berbasis GitHub atau tidak.

API Untuk Alat yang Sudah Dikenal

Instalasi WordPress Anda dilengkapi dengan titik akhir API, sehingga Anda dapat terus menggunakan alat authoring yang berpengalaman tim Anda dengan cara tanpa kepala. WordPress memiliki dokumentasi yang bagus untuk REST API mereka. Ini diaktifkan pada penginstalan WordPress baru, jadi ketika Anda menjalankan lingkungan penulisan WordPress baru, Anda dapat mulai membaca JSON dari https://example.com/wp-json/wp/v2/posts .

Halaman pengaturan WordPress berisi bidang layanan pembaruan tempat Anda dapat memasukkan URL untuk layanan yang ingin Anda ping saat konten berubah. Ini sempurna untuk memicu alat tanpa server untuk mengambil pembaruan terbaru. WordPress v5 memiliki bidang ini di bagian Penulisan pengaturan

Menggabungkan Sumber Data

Menggunakan alat tanpa kepala untuk negara bagian California membantu kami membuat situs tanggap darurat yang meningkatkan standar kinerja. Kami memiliki kontrol penuh atas arsitektur frontend dan masih memungkinkan penulis menggunakan alat penulisan yang sudah dikenal.

Kami menggunakan WordPress tanpa kepala , menulis ke GitHub melalui FAAS. Kami juga menulis sumber data lain ke dalam repositori dan memicu pembuatan generator situs statis di setiap perubahan. Contoh data yang ditulis ke git selain konten editorial asli adalah data yang hanya berubah sekali sehari seperti statistik topline dan versi terjemahan manusia dari setiap halaman kami.

Menggunakan tindakan GitHub sebagai pemicu build memungkinkan kami mengintegrasikan beberapa sumber data berbeda ke dalam situs sehingga kami mendapatkan penerbitan cepat dan jejak infrastruktur produksi kecil. Kurangnya infrastruktur produksi membuat kami mudah bernapas saat kami mencapai lonjakan lalu lintas yang besar terkait dengan pengumuman pandemi pemerintah.

Bagian arsitektur WordPress -> FAAS -> GitHub repo dibuat oleh Carter Medlin. Dia menyambungkan pipa ini bersama-sama dari awal dalam beberapa hari sementara kami merancang dan membangun frontend situs. Ini berjalan pada fungsi MS Azure tanpa server sehingga ada biaya infrastruktur dan pemeliharaan yang rendah. Itu mendapat ping dari layanan pembaruan WordPress yang dijelaskan sebelumnya, menarik json dari API WordPress dan menulis konten baru ke GitHub. Kode untuk titik akhir tanpa server ini dapat dilihat di GitHub.

Bot keluar bekerja keras untuk menerbitkan semua pembaruan konten saat mereka menerima ping dari WordPress. Aktivitas ini membuat log yang dapat ditinjau dengan mudah dari setiap pembaruan dan kemampuan untuk mengembalikan perubahan dengan proses GitHub biasa.

Membangun frontend situs ini menggunakan generator situs statis 11ty cepat, menyenangkan, dan bekerja dengan sempurna. Kami mendapatkan lonjakan lalu lintas yang besar pada berita terkait pandemi dan mengetahui bahwa kami memiliki frontend statis mengurangi risiko ketika jumlah pengguna secara bersamaan mulai meningkat dan kami menerbitkan banyak pembaruan konten.

Saya suka bagaimana komunitas 11ty berfokus pada kinerja dan aksesibilitas dengan papan peringkat komunitas dan arsitekturnya yang ringan. Memastikan bahwa alat yang dibuat oleh negara berfungsi untuk semua orang California adalah penting. Kami ingin semuanya berfungsi di perangkat apa pun dalam kondisi bandwidth rendah dan mendukung semua teknologi bantu. Cukup keren bahwa kita dapat menggunakan alat seperti 11ty yang membuat pengiriman situs yang cepat dan mudah diakses menjadi lebih mudah. Kami menggunakan komponen web di frontend untuk menyediakan fitur tambahan sambil menjaga bobot kode tetap kecil.

Pertimbangan Saat Membuat Pilihan Tanpa Kepala

Bersemangat dengan kemampuan yang diberikan alat tanpa kepala kepada tim Anda? Jumlah opsi yang tersedia bisa sangat banyak. Ini adalah daftar fitur yang dapat membantu Anda mengurangi opsi:

Fitur Lingkungan Penulisan

• Kemudahan pembuatan dokumen
• Kemudahan menambahkan data terstruktur
• Opsi tata letak
• Fitur pratinjau
• Alur kerja persetujuan konten

Fitur API Konten

• Pertanyaan apa yang tersedia
• Seberapa granular struktur kontennya?
• Apakah ada batasan pada akses data (batas keras Airtable REST API)
• Skalabilitas : apakah Anda perlu meletakkan CDN di depan API konten Anda?
• Kemudahan menambahkan lokalisasi
• Mengeluarkan konten Anda, bagaimana jika Anda mengubah rencana, seberapa sulitkah mengekstrak semua data Anda?

Biaya

• Apakah Anda membayar per pengguna untuk solusi yang dihosting?
• Apakah Anda mengelola perangkat lunak sumber terbuka yang Anda instal di lingkungan Anda sendiri?
• Apakah akun pengguna mudah dikelola?
• Dapatkah Anda berintegrasi dengan solusi sistem masuk tunggal yang ada?
• Apakah produk telah lulus audit keamanan, apakah sudah termasuk otentikasi dua faktor ?

Aliran Kontrol/Persetujuan Sumber

• Apakah konten berversi , sehingga Anda dapat memutar kembali ke versi sebelumnya dan melacak apa yang diterbitkan dan pengeditan apa yang dibuat kapan?
• Bisakah Anda membagikan versi konten baru sebelum memublikasikannya? Dapatkah Anda membatasi akses ke pratinjau ini?

Manajemen File Statis

• Seberapa mudah bagi penulis Anda untuk menambahkan gambar baru, pdf, dll.?
• Kemudahan mengaitkan file yang diunggah penulis ke dalam alur pengoptimalan gambar?

Kemana Headless Menuju

Saat Anda melihat lebih dekat ke lanskap tanpa kepala, Anda akan menemukan bahwa alat tanpa kepala sengaja membatasi ruang lingkup fungsionalnya dan menyediakan cara untuk berintegrasi ke dalam sistem yang lebih besar. Memisahkan fitur spesifik bermanfaat ketika sistem menjadi lebih kompleks. Lebih mudah untuk membuat pilihan spesifik yang membatasi biaya, keamanan, pemeliharaan, persyaratan hosting dari jejak kode yang lebih besar saat Anda bekerja dengan alat yang lebih kecil dan terfokus.

Perlu dicatat bahwa opsi tanpa kepala biasanya memerlukan penulisan beberapa kode sendiri. Namun, karena frontend semakin menjadi sekumpulan komponen yang dibuat sebelumnya dan seringkali seluruh desain siap pakai yang diisi dengan data Anda sendiri, seharusnya tidak terlalu sombong untuk mengharapkan lebih banyak cara untuk memadukan dan mencocokkan alat khusus dan mengintegrasikan dengan mulus. opsi tanpa kepala tanpa menulis kode sendiri.

Backend yang sempurna untuk suatu proyek dapat berupa langganan SAAS atau proyek sumber terbuka yang diinstal. Ini dapat berintegrasi tanpa kode dengan frontend siap pakai yang memenuhi semua kebutuhan Anda. Saya melihat bahwa Stackbit sudah menggabungkan CMS tanpa kepala dengan frontend tanpa kode mereka. Saya dapat menyiapkan situs baru menggunakan alat pembuatan halaman tanpa kode WYSIWYG Stackbit dan kemudian saya dapat memilih dari serangkaian opsi CMS tanpa kepala dari vendor yang berbeda untuk mengelola data situs lengkap.

Dalam artikel ini, kami telah membahas beberapa kasus penggunaan di mana tanpa kepala membantu perusahaan tempat saya bekerja mengatasi perubahan. Pilihan tanpa kepala menarik apakah Anda tertarik pada mereka untuk fleksibilitas arsitektur aplikasi, kontrol pengalaman pengguna atau memikirkan dengan hati-hati tentang umur panjang layanan Anda.

Saya senang melihat bagaimana ruang ini terus berkembang dan akan terus mencari cara untuk menggunakan opsi ini guna menghadirkan produk yang lebih baik dan mempermudah pekerjaan saya sebagai pengembang.

Sumber Daya Lebih Lanjut

• CMS Tanpa Kepala, Daftar 85 alat CMS yang luar biasa yang memungkinkan Anda mengurutkan apakah alat tersebut berbasis GitHub atau tidak.
• “Cara Membuat Situs WordPress Tanpa Kepala di Jamstack,” Sarah Drasner & Geoff Graham
• Perdagangan Tanpa Kepala, Shopify
• “GoTrue JS: Membawa Otentikasi Ke Situs Statis Hanya Dengan 3kb JS,” Divya Sasidharan, Netlify
• Pengalaman Mengedit Untuk Situs Jamstack, Stackbit
• API Integrasi Wordpress, CAdotGov, GitHub

Artikel ini telah didukung dengan baik oleh teman-teman terkasih kami di Storyblok, CMS tanpa kepala yang ramah dengan editor visual, komponen bersarang, dan blok konten yang dapat disesuaikan untuk situs web dan aplikasi. Terima kasih!