Bagaimana kita mencapai tingkat kerumitan saat ini, langkah demi langkah

Pengembangan web, khususnya frontend, tidak diragukan lagi merupakan salah satu profesi paling menantang dalam pengembangan perangkat lunak. Lanskapnya terus berkembang. Peralatan dan teknologi menjadi usang dan digantikan dengan peralatan baru dengan kecepatan yang mencengangkan. Ini juga telah menjadi bidang yang luas, jauh melampaui HTML, CSS dan Javascript. Kembali ke sepuluh tahun yang lalu, dapatkah Anda membayangkan bahwa pengembang frontend, yang menggunakan bahasa interpretasi untuk menulis kode, perlu mengotak-atik semua jenis alat kompilasi dalam pekerjaan sehari-hari mereka? Cukup gila, bukan?

Namun Roma tidak dibangun dalam sehari. Mari kita kembali ke masa lalu untuk melihat bagaimana kita sampai di sini selangkah demi selangkah.

“Sejarah tidak bisa memberi kita program untuk masa depan, tapi sejarah bisa memberi kita pemahaman yang lebih lengkap tentang diri kita sendiri, dan tentang kemanusiaan kita, sehingga kita bisa menghadapi masa depan dengan lebih baik.”

—Robert Penn Warren

Server File yang Bahagia​

Arsitektur web dimulai dengan, tanpa arsitektur. Situs web paling awal hanyalah server file yang dapat diakses publik yang memahami permintaan HTTP dan mengembalikan file HTML ke klien.

Yang mengejutkan banyak orang, situs web seperti itu masih ada dan berjalan dengan sangat baik. Misalnya, “Craigslist” tampak seperti fosil hidup — konten yang sepenuhnya statis, file HTML murni, tanpa gambar, tanpa desain; namun, ia masih berada di peringkat #78 dalam lalu lintas di antara semua situs web di seluruh dunia. Ini adalah bukti kekuatan kesederhanaan.

Namun tidak semua bisnis dapat mempertahankan dirinya sebagai fosil hidup. Data yang dimiliki perusahaan online segera menjadi terlalu rumit untuk dikelola sebagai file biasa. Pada saat yang sama, pengguna menjadi tidak puas dengan partisipasi pasif di internet; mereka menginginkan interaksi. Kedua faktor ini menyebabkan lompatan pertama dalam arsitektur web.

Pergeseran ke Konten Dinamis​

Ada dua perubahan signifikan. Salah satunya adalah database mulai dilibatkan — jauh lebih fleksibel daripada file statis. Yang kedua adalah server mulai menjalankan program untuk menghasilkan dokumen HTML, memungkinkan klien yang berbeda untuk melihat konten yang berbeda.

Dari sudut pandang klien, semuanya hampir sama. Halaman web diisi oleh satu permintaan dokumen HTML. Saat pengguna menavigasi atau mengirimkan data, seluruh halaman akan disegarkan. Portal dan situs berita adalah contoh bagus dari arsitektur tersebut. Mereka menyimpan dan menghasilkan banyak konten dan dapat menyediakan penyampaian yang disesuaikan berdasarkan profil pengguna. Mereka juga mengizinkan beberapa interaksi tetapi minimal dibandingkan dengan aplikasi web modern.

Ini semua berfungsi dengan baik untuk sementara waktu hingga situs web memiliki begitu banyak interaksi sehingga halaman yang terus-menerus diperbarui menjadi sangat mengganggu. Jadi lompatan arsitektur web berikutnya adalah membuat interaksi menjadi lebih lancar.

Bangkitnya SPA​

Seperti yang Anda lihat, segalanya tiba-tiba menjadi liar, baik di sisi klien maupun server. Kerumitan ini dibenarkan karena beberapa alasan:

  1. Web telah menjadi saluran komunikasi dua arah yang cerewet. Interaksi pengguna selalu terjadi, menyebabkan konten halaman ikut berubah. Ini melibatkan banyak pertukaran data dinamis dan manipulasi cepat elemen halaman.
  2. Banyak situs web yang mendapatkan lalu lintas dan data dalam jumlah besar, dan kemampuan “menskalakan” telah menjadi topik penting.

Beberapa kemajuan teknologi terjadi tepat pada waktunya dan memungkinkan lompatan ini:

  • Browser telah berkembang jauh lebih kuat, terutama dalam pengambilan data dinamis (“AJAX”) dan manipulasi DOM.
  • Infrastruktur jaringan menjadi lebih kuat dan cepat, dengan CDN yang kini menjadi komoditas.
  • Teknologi virtualisasi sisi server (Docker, Linux Container, dll.) telah matang.
  • Awal mula kerangka komponen UI — Angular, React, Vue.

Berbeda dengan arsitektur sebelumnya, SPA (Single Page Applications) adalah aplikasi asli yang berjalan di dalam browser. Mereka mempunyai kerangka pengembangannya sendiri, diterapkan secara terpisah, mempunyai negara bagian yang kaya, dan bisa rumit hingga jutaan baris kode. Portal Microsoft Azure mengklaim sebagai SPA terbesar di dunia, dan ini adalah LOC-nya pada tahun 2016.

Cara kerja SPA juga sangat berbeda dengan website sebelumnya. Aplikasi frontend digabungkan ke dalam beberapa file Javascript besar. Browser memuatnya dari CDN, menjalankannya untuk mengambil data dari API backend, lalu merender UI.

Ini adalah saat ketika pikiran para pengembang frontend meledak, dan pekerjaan mereka mulai berantakan. Masa lalu yang indah telah berlalu. Ada begitu banyak hal yang perlu dipelajari, alat yang harus dijalankan, dan masalah yang perlu di-debug. Akibatnya, kompleksitas pengembangan frontend telah mencapai tingkat yang baru.

Era Hibrida​

SPA memang keren, tapi bukannya tanpa kekurangan. Inilah dua masalah utama:

  • Meskipun mereka memberikan pengalaman interaksi yang luar biasa, waktu pemuatan awalnya bisa sangat lambat. Keseluruhan aplikasi harus diunduh dan dijalankan sebelum konten bermakna pertama dirender. Mereka juga cenderung menampilkan spinner demi spinner karena banyaknya pemuatan data dinamis.
  • Itu buruk untuk SEO karena yang dikembalikan server bukanlah HTML. Bahkan saat ini, crawler mesin pencari masih tidak dapat menangani sebagian besar situs SPA.

Jika ragu, kembangkan arsitektur 😄.

Idenya cukup sederhana: mari gunakan server file statis lama untuk menyajikan dokumen HTML awal dan biarkan SPA mengambil alih sisanya. Dengan cara ini, waktu pemuatan awal berkurang secara signifikan, dan masalah SEO teratasi.

Hal-hal baru yang memungkinkan paradigma baru ini adalah “meta-framework” seperti Next.js, Nuxt.js, dll. Mereka membungkus kerangka komponen UI dan mengubahnya menjadi kerangka aplikasi. Mereka merespons permintaan HTTP dan mengirimkan HTML yang telah dirender sebelumnya. Mereka juga menyediakan cara untuk melakukan pra-render halaman statis dan memasukkannya ke CDN pada waktu pembuatan.

Satu efek samping yang luar biasa terjadi di sini: frontend sudah mulai memiliki “backend” sendiri. Haruskah kita menyebutnya “fronckenend” atau “middle-end”? Meskipun tanggung jawab utamanya adalah melakukan pra-render halaman, seiring berjalannya waktu, orang-orang menjadi kreatif dan membiarkannya mengambil lebih banyak tanggung jawab. Kami secara bertahap memasuki tahap berikutnya dalam arsitektur web.

Tanpa Server Adalah Warna Hitam Baru​

Sekarang kita berada pada iterasi terbaru dari perkembangan arsitektur. Sejujurnya, menurut saya “tanpa server” adalah istilah yang buruk di sini karena bisa berarti banyak hal dan hanya sebagian tumpang tindih dengan apa yang terjadi di sini, tapi saya akan tetap menggunakannya.

Semuanya dimulai dengan pertanyaan bodoh: “Karena frontend saya sekarang memiliki backend tersendiri yang mengkilap, mengapa saya masih memerlukan backend terpisah?” Jawabannya adalah Anda tidak melakukannya. Dalam banyak kasus, kerangka meta dapat memenuhi semua kebutuhan Anda akan backend.

Beberapa perubahan penting:

  • Backend terpisah telah hilang.
  • Backend frontend kami sebagian besar digantikan oleh "edge". Edge adalah generasi baru node komputasi yang diterapkan secara global. Mereka seperti CDN tetapi dapat mengeksekusi kode khusus, menjadikannya ideal untuk menangani komputasi web.
  • Penyimpanan ditangani oleh database “tanpa server” generasi baru (dihosting secara terpisah), yang dirancang untuk bekerja dengan baik dengan konektivitas dari edge.

Arsitektur baru ini menghadirkan dua peningkatan:

  • Dengan hilangnya backend terpisah, komponen yang bergerak menjadi lebih sedikit, dan sistem menjadi jauh lebih sederhana dalam hal pengembangan, penerapan, dan pengoperasian.
  • Karena komputasi terjadi di edge, rendering halaman sisi server dan pemuatan data dinamis jauh lebih cepat karena kedekatannya yang lebih baik.

Biaya? Sekarang Anda tidak hanya perlu mengadopsi kerangka meta tetapi juga perlu menerapkan aplikasi Anda ke platform tanpa server yang kompatibel — “Vercel”, “Netlify”, “Fly.io”, dll.

Arsitektur Berkembang, dan Tanggung Jawab Bergeser​

Sekarang saatnya semakin banyak pengembang frontend yang dengan bangga menyebut diri mereka pengembang full-stack. Mereka bebas dari ikatan tim backend dan dapat melakukan pengiriman end-to-end secara mandiri. Namun, dengan kekuatan yang besar, terdapat pula tanggung jawab yang besar pula. Apa yang diperlukan untuk menjadi full-stack developer jauh melampaui HTML/CSS/JavaScript. Ketika arsitektur terkonsolidasi, demikian pula tugas-tugasnya:

Apakah ini saat yang terbaik atau yang terburuk? Mungkin keduanya. Alat dan kerangka kerja yang kita miliki saat ini tidak terbayangkan sepuluh tahun yang lalu. Sementara itu, seiring dengan meningkatnya ekspektasi pengguna dan kebutuhan bisnis yang semakin canggih, kompleksitas intrinsik yang harus dihadapi oleh pengembangan full-stack semakin meningkat.

Masyarakat menjadi lebih sadar akan betapa rumitnya hal-hal yang telah berkembang dan mulai melakukan penyederhanaan secara sistematis alih-alih memindahkan masalah ke mana-mana. Itu juga alasan kami membangun ZenStack untuk menyederhanakan konstruksi bagian backend aplikasi web sehingga pengembang dapat lebih fokus pada hal yang penting — pengalaman pengguna dan nilai bisnis.

Suka atau tidak suka, evolusi arsitektur akan terus berjalan dengan kecepatan yang semakin meningkat. Meskipun semua perubahan pasti disertai dengan ketidaknyamanan, belajar dan bekerja di bidang yang begitu dinamis adalah sebuah keberuntungan besar.

Want to Connect?

I'm the creator of ZenStack.

Our goal is to let you save time writing boilerplate code
and focus on building what matters - the user experience.