React adalah framework full-stack (atau sedang menjadi itu)

• React yang menambahkan Server Components dan Server Actions sedang berevolusi menjadi framework full-stack

Awal perang framework pada 2010

• Perang framework yang dimulai pada 2010 dengan Backbone, Knockout, dan Ember segera diikuti oleh Angular dan React, dan tak seorang pun bisa memprediksi hasilnya
• Untuk waktu yang lama, aplikasi JavaScript client-side rendering (CSR) mendominasi
• Aplikasi semacam ini juga disebut single-page application (SPA), dan umumnya terdiri dari file HTML kecil serta file JavaScript besar
• Begitulah sebelum code splitting diperkenalkan

Pemisahan frontend dan backend

• Selama periode ini, pengembangan frontend didominasi oleh berbagai framework dan library JavaScript
• Backend umumnya tidak terikat pada bahasa tertentu, dan REST menjadi standar untuk komunikasi API
• Sebagai pengembang web lepas, saya terutama bekerja dengan backend .NET, Java, Python, dan PHP
• Saya hanya melihat TypeScript/JavaScript di backend pada proyek greenfield atau proyek kecil tempat saya bisa mengendalikan backend
• Namun, kebangkitan full-stack React bisa mengubah hal ini
• Menarik bahwa persepsi pengembang terhadap periode 2010 hingga 2020 berbeda-beda tergantung kapan mereka memulai karier
• Pengembang yang memulai sebelum 2010 berada dalam lingkungan server-side rendering (SSR), dan tampak lebih nyaman dengan kembalinya teknologi server-side belakangan ini
• Sementara itu, banyak orang lain hampir selama 10 tahun hanya bekerja dengan aplikasi client-side rendering (CSR) dan REST API
• Kini mereka tidak tahu bagaimana harus menerima dunia full-stack React yang baru ini

TypeScript muncul sebagai standar industri

• Dalam beberapa tahun terakhir, TypeScript muncul sebagai standar industri
• TypeScript memberi pengembang frontend bahasa pemrograman yang bertipe dan kuat
• Saat para pengembang menerima TypeScript, mereka sampai pada titik tanpa jalan kembali
• Menarik melihat bagaimana perubahan kecil dalam kode bisa berdampak besar pada individu maupun industri secara keseluruhan

Kesulitan TypeScript dan REST

• Dampak TypeScript terhadap REST melahirkan banyak solusi sementara
• OpenAPI (sebelumnya Swagger) memang ada untuk dokumentasi REST API, tetapi kini lebih sering dipakai untuk menghasilkan interface API bertipe
• Meski kita bisa membuat interface bertipe yang sempurna dalam arsitektur client-server, banyak proyek gagal menerapkannya dengan benar sejak awal

• Catatan pribadi: "Mungkin ada pengembang yang punya pengalaman baik dengan arsitektur berbasis OpenAPI, tetapi sayangnya penulis bukan salah satunya"

TypeScript mengubah suasana

• Cukup menarik melihat bagaimana TypeScript mengubah suasana di sini
• Di satu sisi, SPA tak bertipe yang menggunakan REST (dengan OpenAPI untuk tujuan dokumentasi) tampak "baik-baik saja"
• Namun, ketika TypeScript menjadi standar dan dianggap sebagai norma, interface bertipe hasil generate terasa tidak enak dipakai karena basis kode frontend sudah terbiasa dengan standar yang lebih tinggi
• Kekurangan interface bertipe hasil generate sangat jelas:
  • selalu melibatkan langkah generate
  • output hasil generate rumit
  • tergantung pengaturan awal, kode yang dihasilkan tidak selalu benar

Munculnya RPC dan tRPC

• RPC bukan konsep baru, tetapi berkat tRPC, ia menjadi populer di ekosistem React
• Berdasarkan pengalaman selama 6 bulan sebagai solo developer pada aplikasi dengan 80 ribu baris kode, memanggil fungsi di backend untuk membaca dan menulis data terasa seperti pencerahan
• Saya belum pernah merasa seproduktif ini di kedua sisi stack yang sama-sama menggunakan TypeScript
• Secara pribadi, saya hanya pernah merasa seproduktif ini beberapa tahun lalu dengan arsitektur GraphQL bertipe (hasil generate)
• Sepanjang 2023, saya tak bisa membayangkan ada yang lebih baik daripada tRPC
• Memanggil fungsi di backend untuk membaca dan menulis data terasa revolusioner
• Tapi apakah itu saja yang saya butuhkan? Ternyata tidak

Inovasi Server Components dan Server Actions

• Bagi saya, terobosan sesungguhnya datang pada 2024 lewat Server Components dan Server Actions
• Keduanya tidak hanya memanggil server, tetapi juga menjembatani kesenjangan dengan memungkinkan implementasi dan eksekusi kode di sisi lain
• Server Components memungkinkan komponen React dijalankan di server, sehingga bisa mengakses langsung sumber data (misalnya database) sebelum mengembalikan UI dalam JSX
• Server Actions membuat HTTP API endpoint di balik layar, sehingga fungsi dapat dipanggil dan dijalankan seperti remote procedure call
• Server Components dan Server Actions mengubah React menjadi framework full-stack
• Ini adalah masa yang sangat menarik untuk mengubah frontend menjadi lingkungan full-stack

Dukungan React untuk Server Components dan Server Actions

• React sendiri hanya menyediakan fondasi dan spesifikasi untuk Server Components dan Server Actions
• Meta-framework yang dibangun di atas React dapat menjembatani kesenjangan sebagai bundler yang menafsirkan directive antara client dan server
• Next.js memimpin implementasi Server Components dan Server Actions
• Next.js sebelumnya sudah mendukung server-side rendering (SSR), tetapi kini lewat Server Components dan Server Actions, pengembang bisa mengakses sumber daya sisi server seperti database dan message queue

Awal pengembangan full-stack

• Pengembangan full-stack dengan React baru saja memasuki tahap awal
• Ketika pengembang mulai mengakses database secara langsung lewat Server Components dan Server Actions, akan ada proses menjinakkan kompleksitas yang melampaui aplikasi CRUD sederhana
• Melalui pembelajaran yang mendalam, pengembang frontend akan segera menguasai implementasi arsitektur backend dengan menggunakan layer, design pattern, dan best practice
• Sejujurnya, karena tidak ada yang ingin melihat pemanggilan fungsi ORM di dalam komponen React

Harapan terhadap pergeseran paradigma

• Saya sangat antusias dengan pergeseran paradigma ini
• Bersiaplah untuk era baru ketika pengembang React mengimplementasikan fungsionalitas vertikal dari UI hingga database

[t7vonn]

Sudah mengurus semua hal full-stack, kan

[wan2land]

Jika mempertimbangkan kompatibilitas dengan bahasa lain seperti pada pengembangan aplikasi, saya rasa tRPC bukan pilihan yang terlalu bagus. 😅
Menurut saya, GraphQL adalah pilihan terbaik.

[click]

Server Action di Next.js punya masalah karena secara publik mengekspos endpoint API acak yang tidak bisa dikendalikan oleh developer, dan menurut saya ini adalah bagian yang sangat rentan.

[pasg0725]

Boleh tahu kerentanan yang Anda maksud itu yang mana? Saya sempat mencari dan yang muncul adalah kerentanan SSRF, tapi saya kurang yakin apakah itu yang dimaksud. Saya sedang belajar Next.js, jadi penasaran dan ingin bertanya.

[savvykang]

Sejak awal, apa sebenarnya niat orang-orang yang mendorong SPA? Jauh lebih baik daripada era ketika memanipulasi DOM dengan jquery, tetapi konsep yang dibutuhkan untuk perancangan dan pengembangan backend serta frontend tampaknya tidak hilang, hanya berpindah tempat. Bahkan untuk routing saja, sempat dipindahkan dari server ke klien, lalu karena tren server-side rendering, sekarang malah ingin dipindahkan kembali ke server.

Saya juga ragu apakah 3 tahun lagi kursus atau pelatihan coding masih akan mengajarkan React bergaya SPA.

[superwoou]

Bukankah keunggulan terbesarnya adalah kelancaran saat berpindah halaman (setidaknya pada waktu itu)

[xguru]

Bagian akhir tulisan asli ditutup dengan promosi untuk kursus pendidikan pengembangan web full-stack The Road to Next yang rencananya akan dibuka oleh penulis ^^;