Brief by evilfactorylabs

Brief by evilfactorylabs • Untuk obrolan makan siangmu seputar dunia pemrograman. Terbit sebelum jam 13.37 WIB setiap hari Senin & Selasa.

Tentang Jamstack

Business & Engineering value, the cost of in-house, and why Jamstack is the novel answer for your cost; security, performance, scalability and availability problem.

Software JavaScript is eating the world, katanya.

Lihat, sebagai contoh, sudah banyak tools yang dibuat menggunakan JavaScript, meskipun beberapa orang sudah ada yang mengkritisinya.

Yang maksudnya, JavaScript bukanlah sekedar "scripting language" yang hanya berguna untuk membuat sebuah halaman menjadi interaktif. JavaScript sekarang bisa digunakan untuk membuat server-side program via v8, aplikasi mobile (native) via React Native, dan sebagainya.

Selain itu, beberapa orang mencoba "reinventing" cara membuat aplikasi web yang mana salah satunya menjadikan JavaScript sebagai fondasinya. Arsitektur tersebut bernama "Jamstack", yang mana JAM nya tersebut adalah JavaScript, APIs, dan Markup yang dijadikan sebagai fondasi dalam membuat aplikasi web.

Sebelum kita menyelam lebih dalam tentang Jamstack, mari kita bahas "status quo" tentang bagaimana cara kita membuat aplikasi berbasis web.

Web App Today

Pada dasarnya aplikasi web adalah sebuah sistem informasi yang bertugas untuk memproses informasi. Ya, proses login; Pencarian, add to cart, follow, dll adalah tentang "mengirim informasi" dari aplikasi ke sistem yang mana informasi tersebut akan disimpan di basis data.

Mari kita ambil contoh dari E-Commerce, (kategori) aplikasi web yang lumayan besar di Indonesia.

Not affiliated, fyi

Sekarang mari kita coba "kategorikan" aplikasi tersebut menjadi aplikasi (layanan) yang lebih kecil lagi.

Pengkategorian diatas hanyalah sebagian kecil yang "terlihat" di halaman awal, antara lain:

  • Layanan pencarian
  • Layanan pengelola pengguna
  • Layanan pengatur halaman statis & dinamis
  • Layanan pengatur aset statis

Belum melingkupi layanan inti, layanan pengatur pembayaran, pengirim email, analitik, dll.

Ada biaya yang harus dibayar dalam membuat sebuah layanan—meyebut hal-hal teknis sedikit—mungkin kita harus berhadapan dengan Apache Solr atau Elasticsearch untuk pencarian, layanan "in-house" user management untuk autentikasi dan otorisasi, "in-house" internal CMS untuk mengatur halaman, dan penggunaan Swift (OpenStack Object Storage) dengan bantuan Hadoop untuk mengatur aset statis.

Biayanya ada di hardware, file system, pemeliharaan, keamanan, bandwidth, dsb yang pastinya sudah kamu hafal.

Dan ya, tanpa melupakan peran developer juga yang mengembangkan layanan yang dibuat diatas stack tersebut.

Karena membuat layanan tersebut pastinya tidak gratis, kebijakan dalam membuat pertimbangan "build vs buy" berperan disini. Ada biaya yang harus dibayar untuk membuat sebuah layanan, seperti: Jumlah pengembang yang dibutuhkan, nilai rata-rata untuk gaji mereka, lamanya waktu pengembangan yang dihabiskan, dan interval pemeliharaan yang dilakukan per waktu yang ditentukan (misal per-bulan).

Beberapa sudah aware dengan ini. Seperti, memilih menggunakan 3rd-party object storage daripada membuat sendiri diatas teknologi yang sudah ada. Pertimbangan tersebut bisa memotong biaya pemeliharaan, pengembangan, keamanan, dan perangkat keras untuk kebutuhan pengelolaan aset statis.

Business Value

Segala pertimbangan "engineering" pastinya selalu disandingkan dengan nilai bisnis. Sepengalaman saya, hal-hal engineering yang merefleksikan nilai bisnis antara lain (tidak sesuai urutan):

  • Biaya
  • Keamanan
  • Performa
  • Skalabilitas
  • Keberadaan

Yang berarti, pertimbangan terkait "engineering" harus memiliki ROI hijau yang mana memenuhi 5 faktor diatas.

The cost of "in-house"

Sederhananya, "in-house software" adalah peranti lunak yang dibuat oleh suatu organisasi yang mana untuk memenuhi kebutuhan organisasi tersebut. Contohnya, menggunakan "software buatan sendiri" dalam membuat search engine daripada menggunakan software yang sudah ada seperti Apache Solr.

Pastinya, organisasi sudah memiliki pertimbangan tersendiri yang terkait dengan 5 faktor yang sudah disebut diatas.

Mengapa membuat layanan sendiri? Jawabannya beragam. Entah karena belum adanya layanan tersebut/tidak memiliki fungsionalitas yang mereka inginkan (keunikan), tidak memenuhi skala mereka (skalabilitas), software yang sudah ada terlalu powerful untuk kebutuhan mereka (overhead), atau untuk keperluan "reinventing the wheel" dari hasil R&D.

Apapun.

Sedangkan ada beberapa biaya yang harus dibayar atas pertimbangan ini. Mungkin untuk organisasi yang lumayan besar biaya-biaya tersebut lebih murah daripada "menyewa" layanan yang sudah ada—mengingat memiliki banyaknya "sumber daya", keuangan, dll—namun untuk organisasi yang lebih kecil, mungkin bisa melakukan pertimbangan ulang.

The Jamstack

Kembali ke pembahasan utama, Jamstack bisa menjadi alternatif untuk kamu yang ingin membuat aplikasi web yang lebih mem-prioritaskan business value daripada engineering value.

Karena pertama, pada dasarnya aplikasi web—yang digunakan oleh pengguna akhir—adalah sebuah dokumen HTML yang dipercantik menggunakan CSS dan dibuat menjadi interaktif dengan sentuhan JavaScript.

Kedua, pengguna akhir (kebanyakan, atau semua?) tidak peduli apakah aplikasi web tersebut dibuat menggunakan React, ditenagai oleh Laravel, menggunakan basis data MongoDB, menggunakan Redis, ber-arsitektur Microservices, dll. Yang mereka pedulikan adalah apa yang bisa dilakukan oleh aplikasi tersebut, untuk membantu pekerjaan/aktivitas mereka.

Ketiga, pengguna akhir (sadar-tidak-sadar) peduli dengan performa, keamanan, keberadaan, dll. Banyak pengguna (bahkan tech and non-tech savvy) yang mengeluh ketika aplikasi web tersebut lambat, atau sering down, atau ada berita data breach.

Yang berarti, 3 kasus diatas saja sudah membahas seputar 5 faktor yang sudah disebut sebelumnya.

Pertanyaan nya, apakah Jamstack adalah sebuah solusi? Seperti yang kita tau jawaban untuk setiap pertanyaan yang terkait teknis: tergantung.

99.9% SLA — APIs

Hampir setiap layanan pihak ketiga memiliki Service-Level Agreement (SLA) sekitar 99.9%, yang singkatnya, keterjaminan layanan yang digunakan memiliki persentase yang disebutkan tersebut untuk faktor keberadaan.

Yang berarti, bila SLA tersebut memiliki persentase 99.99%, mereka menjanjikan:

  • Per-hari hanya memiliki down time selama 9 detik
  • Per-minggu hanya 1 menit
  • Per-bulan hanya 4 menit 23 detik
  • Per-tahun hanya 52 menit 36 detik

Jadi kita tidak perlu melakukan healthcheck, monitoring dashboard grafana, capek-capek setting Chat Ops, dsb karena itu sudah tugas & janji mereka. Untuk bagian ini, masalah khusus yang diselesaikan adalah di faktor keberadaan (reliabilitas).

Secure™ — Markup

Prinsip utama Jamstack salah satunya adalah semua dokumen merupakan halaman statis, yang artinya tidak ada server instance yang berjalan untuk mengatur halaman dokumen tersebut.

Yang berarti, kita tidak perlu mengkhawatirkan akan kerentanan yang ada di database ataupun server, karena kita tidak menggunakan itu. Bagian ini menyelesaikan masalah terkait faktor keamanan.

Fast™ — Markup

Dan karena statis tersebut, halaman bisa di serve oleh CDN yang singkatnya CDN melakukan cache di jaringan terdekat sehingga pengguna bisa mengakses halaman menjadi lebih cepat tanpa memusingkan lokasi geografis dimana pengguna tersebut berada.

Bagian ini menyelesaikan masalah terkait faktor performa (latensi), keberadaan (redundansi) dan skalabilitas (untuk bagian hardware, bandwidth, dll).

Cheap™ — APIs

Sebagai contoh, bayangkan mengembangkan layanan pencarian, membuat server cluster untuk Apache Solr & Hadoop, memeliharanya, membuatnya aman, dsb dibandingkan dengan membayar $20 untuk skala 250k operasi & 50k records di Algolia per-bulan.

Dan ya, biasanya kita butuh data "riwayat pencarian" untuk keperluan BI, bukan?

Bagian ini tidak ekslusif untuk Jamstack, namun termasuk menjadi fondasi untuk membuat aplikasi yang memiliki arsitektur Jamstack.

Pada dasarnya bagian APIs menyelesaikan masalah terkait 5 faktor diatas, karena singkatnya "itu bukan urusan kita".

Mengapa ada simbol ™ diatas? Karena poin tersebut bernilai relatif. Tergantung dengan layanan pihak ketiga apa yang kamu gunakan.

But at what cost?

Mari kita recall, Jamstack adalah:

  • Website yang dibuat tanpa server-side CMS
  • Aplikasi SPA yang menggunakan isomorphic rendering untuk membuat tampilan dari runtime server.
  • Aplikasi web "monolith" yang bergantung dengan bahasa program backend

Karena Jamstack pada dasarnya hanyalah sebuah halaman statis. Alur nya:

  • Website di generate berdasarkan data yang ada, entah data tersebut dari database, file JSON, apapun tergantung dengan rancangan yang ada.
  • Website tersebut di generate berdasarkan tools/framework/library yang digunakan, bisa Hugo; Jekyll, Eleventy, dll di build time.
  • Lalu, website tersebut didistribusikan ke layanan diatas jaringan layanan CDN.

Konteks website diatas adalah "kumpulan halaman/dokumen web", dan pastinya kamu sudah mengetahui itu.

Pertanyaan nya, apakah menggunakan arsitektur Jamstack relevan untuk skala saya?

Gatsby case: Generating 150k pages

Gatsby, sebuah framework untuk membuat website/aplikasi dapat meng-generate 150rb halaman sekitar 5 menit. Yang berarti, dalam 1 detik Gatsby bisa membuat 500 halaman tergantung spesifikasi hardware yang digunakan.

Yang artinya, bila website yang ingin dibuat adalah sebuah E-commerce, Gatsby bisa membuat ~150rb halaman produk dalam 5 menit!

Incremental Build

Biasanya, website yang menggunakan arsitektur Jamstack menggunakan Git sebagai version control. Website/aplikasi UGC (User-generated Content) merupakan hal yang kompleks, salah satunya dalam cache invalidation untuk view dalam konteks performa karena melibatkan database query dsb.

Dengan menggunakan Jamstack, single source of truth nya adalah "data source", entah itu berkas markdown, JSON, ataupun menggunakan layanan pihak ketiga yang bertindak sebagai "data content layer".

Karena itu, proses build yang terjadi hanyalah terhadap konten yang berubah saja, sebagaimana tugas utama version control seperti Git. Untuk kasus menggunakan layanan pihak ketiga, mereka biasanya sudah menawarkan fitur "versioning" dengan cara mereka sendiri.

Ambil contoh E-commerce, perubahan yang terjadi terhadap "konten" di E-commerce biasanya hanyalah informasi harga, gambar produk, dan deskripsi. Rating, feedback, dsb mungkin termasuk, namun "informasi utama" yang dibutuhkan pengguna adalah informasi terkait produk, bukan informasi "tambahan" yang sifatnya pendukung.

Juga, proses "cache invalidation" disini relatif tidak terlalu sulit, peramban menghormati header E-tag, dan di level CDN mereka sudah "pintar" untuk melakukan itu (biasanya dengan menggunakan fingerprinting, kurang lebih seperti E-tag).

Infrastruktur Content Mesh

Pada dasarnya halaman web adalah tentang menampilkan informasi, dan informasi tersebut diambil dari basis sumber data yang dipilih.

Biasanya data diambil dengan melakukan request ke API Endpoint yang sudah disiapkan, begitupula dengan di Jamstack.

Seperti, menggunakan Auth0 untuk user management, menggunakan Algolia untuk search engine, menggunakan Cloudinary untuk static media management, dsb.

Data pengguna adalah data yang paling sensitif, ingatkah kasus data breach dari suatu E-commerce di Indonesia yang mana data 13jt data pengguna termasuk alamat email, alamat IP, (hashed?) password, dan data lain seperti username dan Nama "dicuri" oleh "Hackers"?

Content mesh adalah seperti "microservices" tapi layanan tersebut tidak dimiliki & tidak dikontrol oleh kita (yes, probably you can say it SaaS). Segala resiko dan biaya (diluar biaya layanan) dibebankan kepada pemilik layanan.

Penutup

Jamstack tidak menyelesaikan semua masalah. Tapi, silahkan ganti kata Jamstack tadi menjadi kata apapun itu yang merefleksikan sebuah "solusi".

Jamstack hanya cocok untuk aplikasi yang lebih banyak memiliki informasi daripada interaksi (think like Spotify as a music discovery vs Spotify as a music player).

Juga, sangat bergantung dengan layanan pihak ketiga. Karena memang itu salah satu tujuannya.

Menggunakan arsitektur Jamstack bukan berarti tidak membutuhkan server, melainkan hanya "memindahkan" server tersebut ke orang lain, dan mengurangi "kerja" server hanya menjadi untuk serve static pages.

Karena selebihnya, proses-proses dilakukan di client-side (JavaScript) ataupun di pihak ketiga (APIs).

Silahkan pelajari selengkapnya tentang Jamstack di situs resmi dan semi-resmi nya.

Menikmati tulisan ini?

Blog ini tidak menampilkan iklan, yang berarti blog ini didanai oleh pembaca seperti kamu. Gabung bersama Loading... yang telah membantu blog ini agar terus bisa mencakup tulisan yang lebih berkualitas dan bermanfaat!

Pendukung

Dukung Mengapa saya harus mendukung?
You've successfully subscribed to Brief by evilfactorylabs
Great! Next, complete checkout for full access to Brief by evilfactorylabs
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.