- Middleware di Next.js memiliki pengaturan logging yang terbatas, dan logging bawaan hanya aktif di lingkungan pengembangan sehingga pelacakan masalah di produksi menjadi sulit
- Di middleware, hanya header yang bisa diteruskan, dan chaining beberapa middleware tidak dimungkinkan sehingga implementasi logging yang kompleks menjadi terbatas
- Logging dengan AsyncLocalStorage menunjukkan perilaku tak terduga di runtime Edge, dan berbagi konteks antara halaman dan middleware tidak berfungsi dengan baik
- Bahkan dengan custom server, masalah logging sulit diselesaikan, dan batasan desain Next.js memaksa pengembang ke cara tertentu
- SvelteKit milik Vercel menyediakan middleware yang fleksibel dan mekanisme pengiriman data, menunjukkan desain yang lebih ramah pengembang dibanding Next.js
Latar belakang masalah logging di Next.js
- Saat mengoperasikan layanan Next.js dan mencoba melakukan pencatatan log produksi, diketahui bahwa fitur log bawaan hanya aktif di lingkungan pengembangan
- Dalam situasi yang membutuhkan implementasi sistem logging yang cocok untuk lingkungan operasional, keterbatasan Next.js pun muncul
Keterbatasan middleware
- Menurut dokumentasi resmi, middleware dijalankan sebelum routing dan cocok untuk mengimplementasikan fitur seperti autentikasi, logging, dan redirect
- Dalam praktiknya, parameter yang bisa diteruskan ke middleware dibatasi menjadi 4, dan pada kenyataannya hanya header yang benar-benar bisa diteruskan
- Tidak mendukung struktur untuk meng-chain atau menggabungkan beberapa middleware
- Di Node.js sudah ada praktik middleware yang mapan seperti di Express, tetapi di Next.js hal itu tidak bisa diterapkan dengan baik
Upaya mengakali dengan AsyncLocalStorage
- Mencoba mengelola instance logging di level middleware dengan menggunakan pino dan AsyncLocalStorage
- Di middleware, log bisa disimpan dengan konteks unik untuk setiap request, tetapi teramati bahwa hal ini hanya berjalan normal di lingkungan browser
- Ini karena middleware Next.js pada dasarnya menggunakan runtime edge, dan meskipun diatur ke runtime nodejs, perilakunya tetap tidak stabil tergantung situasi proyek
Kendala di komponen halaman
- Saat fungsi logging dipanggil di halaman atau komponen layout yang sebenarnya, logger() mengembalikan null
- Ada masalah struktural di mana konteks logger yang dibuat di middleware tidak diteruskan ke konteks rendering asinkron
- Satu-satunya solusi adalah membawa informasi logging seperti requestId lewat header, yang membuat kode menjadi rumit dan struktur import membingungkan
- Di komponen client pun diperlukan pemisahan struktural serupa
Upaya memakai custom server
- Mengikuti contoh custom server di dokumentasi resmi, dilakukan eksperimen dengan memanfaatkan http.createServer dan app.getRequestHandler dari next.js
- Di lingkungan ini juga dicoba kembali penggunaan AsyncLocalStorage, tetapi fenomena konteks yang tidak bisa terhubung antara middleware–halaman–custom server kembali terjadi
- Pada dasarnya hanya di dalam Next.js sendiri AsyncLocalStorage digunakan dengan benar, sementara pengembang tidak diberi wewenang yang sama
- Cara yang bisa digunakan untuk meneruskan dari middleware ke halaman pada praktiknya hanya header respons (change) serta perpindahan jalur redirect/rewrite
- Dari sudut pandang pengguna, sangat sulit melakukan ekstensi yang fleksibel atau pengiriman konteks kustom
Perbandingan dengan SvelteKit
- SvelteKit milik Vercel menyediakan sistem middleware yang lebih fleksibel dibanding Next.js
- Melalui objek event.locals, data request bisa diteruskan dengan bebas
- Bisa mendefinisikan beberapa fungsi handle untuk di-chain, sehingga logika kompleks lebih mudah diimplementasikan
- SvelteKit menunjukkan desain yang ramah pengembang, berlawanan dengan berbagai batasan di Next.js
- SvelteKit adalah produk Vercel juga, tetapi meskipun dianggap sebagai proyek sekunder dibanding Next.js, pengalaman yang diberikan justru lebih baik
Kritik terhadap issue tracker dan budaya ekosistem
- Issue tracker GitHub resmi Next.js berada dalam kondisi hampir tidak merespons umpan balik pengguna
- Bahkan issue atau bug populer pun sering dibiarkan lama tanpa jawaban atau penyelesaian
- Walau sudah menyiapkan kode reproduksi minimal dan mengajukan issue, tidak ada respons nyata atau tindak lanjut
Kesimpulan dan refleksi
- Bug dan batasan struktural yang ditemukan di Next.js berulang kali merusak produktivitas pengembang, dan tampak membutuhkan perbaikan mendasar
- Dibanding framework lain seperti SvelteKit, Next.js tertinggal dalam kemudahan penggunaan meskipun merupakan produk utama
- Belum mudah untuk segera mengganti Next.js, tetapi untuk proyek mendatang muncul keinginan untuk mempertimbangkan pilihan lain
7 komentar
Sepertinya dia belum sadar kalau React juga merusak produktivitas.
Kali ini saya mencoba web development hanya karena ketertarikan pribadi, padahal bidang ini sama sekali tidak berhubungan dengan bidang yang biasa saya geluti. Saya membuat papan diskusi dengan next.js v15 app router, tetapi setiap kali melihat tulisan seperti ini, rasanya motivasi untuk mencoba hal baru di ranah web jadi berkurang. Kenapa ekosistemnya tidak stabil seperti ini? Nanti kalau muncul hal baru lagi, apakah orang-orang akan berbondong-bondong pindah, memakainya sebentar, lalu mengeluh lagi sambil mencari yang lain? Dunia web development sepertinya memang sulit.
Karena sifat industri ini, perubahan yang cepat bisa jadi kelebihan sekaligus kekurangan, hehe. Tapi masalah di isi artikel ini pada dasarnya disebabkan oleh ulah Vercel. Kalau mau mengerjakan frontend, sebaiknya agak mewaspadai Vercel T_T
Mungkin karena saya memulai karier di web, pengembangan web memang pada dasarnya seperti itu (terutama frontend), ada sensasi khasnya sendiri saat mengembangkan haha
Rasanya serba cepat berubah...
Sisi JS memang terasa agak seperti itu. Ada banyak hal yang katanya bagus, tapi masing-masing sedikit banyak punya masalah, dan cepat sekali berubah mengikuti tren...
Mungkin saya merasa begitu karena dulu fokus utama saya adalah Java, EJB, dan Struts.
Komentar Hacker News
Saya 100% setuju, saya juga mengalami masalah yang sama, dan ke depan saya tidak akan pernah lagi memakai Next.js, bahkan saya akan merekomendasikan semua tim di perusahaan untuk memakai alternatif lain
Next.js punya lapisan abstraksi yang sangat besar dan tidak diperlukan untuk 99.9999% proyek, dan untuk sedikit kasus yang benar-benar membutuhkan hal seperti itu, menurut saya lebih baik membuat solusi kustom dengan komponen level bawah
Dari semua teknologi yang pernah saya pakai, Next.js sejauh ini yang paling buruk
Lega rasanya saya bukan satu-satunya yang berpikir begini
Saya membangun aplikasi production penghasil pendapatan dengan kompleksitas menengah menggunakan Next.js, awalnya memakai Vercel dan Google Firebase lalu kemudian pindah ke self-hosting dan menggantinya dengan Pocketbase
Hanya Pocketbase yang terasa sebagai pengalaman yang layak, sisanya benar-benar mengerikan
Kompleksitas tanpa akhir, breaking change yang terus-menerus, dokumentasi yang sulit diakses, tidak ada satu pun yang mudah
Saya yakin kalau 5 tahun terakhir tren FE diputar ulang dan fokusnya diarahkan untuk mengajarkan teknologi yang memang sudah ada saat itu dengan benar, keadaan sekarang akan lebih baik
Saya juga pernah membuat frontend React yang kompleks, dan walau saya juga tidak terlalu suka React, Next.js jauh lebih parah
Saya juga pernah membuat CMS dengan Go dan vanilla JS, dan meskipun DX-nya mungkin sedikit lebih rendah, setidaknya saya bisa merasa benar-benar paham apa yang sedang terjadi
Saya tidak mengerti kenapa di React dan Next.js, bahkan setelah 6 tahun, saya masih harus selalu menebak-nebak apa yang akan terjadi
Saya memang jadi berpengalaman dalam membereskan kekusutan framework ini, tetapi secara keseluruhan rasanya tetap sangat berantakan dan desainnya buruk
Di Go, selain 6 bulan pertama, hampir tidak ada kejutan, dan codebase lama pun tetap kokoh
Sayangnya pengalaman seperti ini sulit didapat di sisi frontend
Dari pengalaman saya, bagian-bagian kasar di Next.js itu bukan bug, melainkan fitur
Semuanya terasa seperti memang dirancang agar pengguna menyerah lalu terikat ke hosting Vercel
Saya rasa ke depan situasinya akan makin buruk
Saat ini kursus online seperti PluralSight juga hanya mendorong Next.js untuk materi React
Saya tidak tahu kenapa situasi seperti ini bisa terjadi, tapi ya kita sudah sampai di sini
Dalam kasus saya, Sharepoint meninggalkan kenangan yang lebih buruk, jadi Next.js ada di posisi kedua terburuk
Hal yang paling membuat frustrasi dari Next.js adalah ia berpura-pura menyediakan semuanya seperti framework full-stack semacam Rails, Wordpress, atau Meteor, tetapi pada kenyataannya ia hanya punya opini pada bagian paling tidak menarik dan paling terbatas seperti middleware, image resizing, SSR, dan sebagainya, sementara keputusan yang benar-benar bernilai seperti database, ORM, protokol komunikasi, dan lainnya justru dilempar ke pengguna
Pada praktiknya ini sangat berbeda dari Rails/Wordpress/Meteor, dan framework seharusnya mendefinisikan infrastruktur, tapi di sini justru infrastrukturnya yang mengendalikan framework
Di dashboard saya, "Fluid Active CPU" dan "ISR Writes" adalah item penggunaan teratas, dan saya cuma bisa membayar $20 lalu berharap tidak melewati 100%
Nama item-itemnya penuh istilah teknis ala Star Trek, dan rasanya akan berubah lagi di major version berikutnya sehingga saya bahkan tidak ingin mempelajarinya
Cukup banyak kenalan saya yang dulu sangat antusias pada Zeit akhirnya memindahkan proyek dan klien mereka ke tempat lain
Kalau Vercel bertanya kepada saya apa yang harus diubah di major release berikutnya, satu-satunya jawaban saya adalah, "Semua keputusan sejak App Router, termasuk App Router sendiri, itu salah"
Saya tidak tahu bagaimana ini bisa dipulihkan
Saya rasa banyak masalah Next.js berasal dari tidak jelasnya kode itu sebenarnya dijalankan di mana
Browser, middleware, edge dan node, SSR, semuanya bercampur dan menciptakan kompleksitas yang luar biasa
Kasus serumit ini hanya cocok jika
Anda mengoperasikan layanan B2C global dan ingin menurunkan latensi dengan semantik edge
Anda siap memakai hosting Vercel yang mahal
Anda hanya butuh arsitektur yang tidak rumit tanpa pekerjaan background
Selain itu, react-vite SPA atau SSR tradisional seperti Rails jauh lebih aman dipilih
Saya bahkan tidak setuju dengan syarat-syarat di atas
Bahkan jika memang cocok dengan Next.js, penurunan produktivitas dan maintainability sama sekali tidak terasa sepadan
Saya memakai Lustre dari Gleam dan tidak berniat menoleh ke belakang
Saya juga menganggap keynote dari pendiri Elm sebagai contoh yang berlawanan dengan Next.js
https://www.youtube.com/watch?v=sl1UQXgtepE
Saya menyebut Vercel sebagai kanker web modern
Mereka menyusup ke setiap ekosistem framework dan menyalahgunakannya untuk menjual paket berbayar, sambil berpura-pura mendukung open source, persaingan, dan kemajuan web
Bahkan untuk kondisi pertama sekalipun, sulit rasanya percaya bahwa memakai Vercel dan SSR akan benar-benar menyelesaikan bottleneck performa
Sebagian besar penurunan performa biasanya berasal dari hal-hal dasar seperti ukuran bundle yang terlalu besar, terlalu banyak panggilan API yang lambat, dan sebagainya
Melakukan profiling dasar, optimasi, dan penyederhanaan terlebih dulu jauh lebih efektif daripada memperumit arsitektur
Saya setuju dengan bagian soal "masalah tidak tahu kode berjalan di mana"
Dulu saya menganggap serba-JavaScript itu kelebihan, tapi sekarang justru terasa sebagai masalah
Perusahaan kami memakai Inertia.js + Vue, dan secara keseluruhan strukturnya sederhana, kekuatan render frontend tetap ada, routing ditangani 100% di sisi server, dan tidak perlu API terpisah
Inertia juga bisa dipakai di React dan Svelte
Awalnya kami memakai Nuxt, tetapi terlalu rumit sampai harus menjalankan server backend dan server frontend sekaligus, dan sulit mengetahui kode berjalan di mana
Sekarang berkat pemisahan jelas bahwa PHP itu server dan JS itu browser, kami sama sekali tidak perlu memikirkannya lagi
Itu keuntungan besar bagi kami
Menurut saya poin utamanya dirangkum dengan baik
Vercel mengejar optimasi performa lewat React Server Components, Partial Pre-rendering, server edge, streaming, dan sebagainya
Semua keputusan desain atau API yang aneh pada dasarnya berasal dari sini
Kalau memang dibutuhkan, itu bisa membantu, tetapi dengan memanfaatkan edge function secukupnya untuk SSR saja pun hasilnya sudah bisa jauh lebih baik
Terima kasih sudah meninggalkan feedback
Kami menyadari ada isu DX di Middleware, dan di versi 15.5 kami menghadirkan dukungan Node runtime sebagai kemajuan besar[1]
Kalau bisa kembali, kami mungkin akan mengganti namanya menjadi Routing Middleware atau Routing Handler, sebagai advanced escape hatch yang dipakai pada tahap routing dan bisa diteruskan ke CDN edge
Kalau Anda butuh logging, itu bisa ditangani memakai OpenTelemetry sesuai praktik
instrumentation.ts[2][1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation
Terima kasih atas jawabannya
Tapi ketika Anda membawa pembicaraan ke instrumentation dan observability, itu terdengar seperti memecahkan masalah logging sederhana dengan lapisan kompleksitas lain
Tidak semua aplikasi membutuhkan OpenTelemetry
Saya tidak mengerti kenapa pendekatan biasa seperti
logger().info()tidak bisaSemua bahasa dan framework lain punya itu, jadi saya tidak paham kenapa di sini jadi begitu sulit
Karena suasananya di sini negatif, saya ingin menegaskan dulu: Next.js adalah software yang bagus dan sangat cocok untuk tujuan nyatanya
Menurut saya mereka berhasil membangun software yang menopang jutaan situs
Masalahnya datang dari kurangnya referensi rinci dan dokumentasi, karena dokumentasinya memang memberitahu apa saja yang ada, tetapi tidak banyak membahas cara pakainya dalam praktik, kapan ia dieksekusi, jebakan umum, dan sebagainya
Ramah untuk pemula, tetapi kurang memberi panduan tentang konteks runtime yang kompleks atau kompleksitas turunan
Ini tren yang saya lihat di banyak proyek belakangan ini
Menyeimbangkan sifat user friendly dengan penjelasan yang rinci itu sangat sulit
Saya berharap proyek ini terus berkembang
Saya ingin menambahkan satu kalimat lagi
Penulis artikel ini gagal mengenali perbedaan domain dan mencoba memanggil fungsi yang sama di semua tempat
Masalah di Next.js berasal dari upaya memaksa domain-domain yang pada dasarnya berbeda agar tampak menyatu
Kalau edge, SSR, Node, dan client dicampur seperti ini, yang bertambah hanya kompleksitas
Dokumentasi pun tidak bisa menyelesaikannya, malah hanya menambah kebingungan
Saya pernah direkomendasikan metode instrumentation dari komentar Reddit
Kalau dalam waktu yang sama saya sedang menyiapkan opentelemetry di Next, meskipun dokumentasinya berbeda, saya mungkin juga akan menulis blog post setelah mengalami itu
Ini bukan sepenuhnya salah kalian, tetapi hampir semua paket opentelemetry diberi label eksperimental, jadi sulit merasa percaya diri memakainya di production
Menyiapkan instrumentation pino juga sangat sulit
Saya harus menambahkan pino ke
serverExternalPackagesagar bisa berfungsi dengan benarAuto-instrumentation juga sangat sensitif terhadap urutan import, dan hanya default export pino yang bisa diinstrumentasi
Variabel lokal modul juga tidak bekerja seperti yang diharapkan sehingga saya harus memakai
globalThisBahkan setelah itu saya tetap terkena https://github.com/vercel/next.js/issues/80445
Pada akhirnya memang bisa berjalan, tetapi setup-nya benar-benar tidak nyaman
Itu pengalaman saya karena memakai router manual (= tidak memakai
vercel/otel)Kalau keputusan untuk mendukung middleware sisi server sudah dibuat, saya tidak mengerti kenapa sampai sekarang tetap tidak ada middleware chain, jadi hanya mendukung satu saja
Itu fitur yang disediakan semua framework server lain
Saya curiga apakah benar "tidak bisa chain beberapa middleware"
https://nextjs.org/docs/messages/nested-middleware
Kalau memang beberapa middleware harus digabung ke satu file agar dijalankan, itu benar-benar sulit dipercaya
Kalau saya membacanya dengan benar, berarti Next.js justru menyuruh agar middleware tidak distrukturkan ke beberapa file, melainkan digabung jadi satu?
Apakah ini karena masalah scoping sehingga sulit memakai banyak file? Sebagai framework, tuntutan seperti ini sungguh tidak masuk akal
Sulit menghilangkan kecurigaan bahwa sebagian besar keputusan konyol seperti ini diambil bukan karena menguntungkan framework, tetapi karena lebih menguntungkan Vercel
Saat pertama melihat Next.js, saya langsung teringat pada Meteor.js
Saya memang berinvestasi cukup banyak untuk mempelajarinya lewat proyek pribadi, tetapi karena abstraksinya terlalu berlebihan dan terlalu kaku, sulit dipakai lebih jauh dari sekadar prototipe
Solusi "batteries included" seperti ini akan terus bermunculan karena setup-nya memang nyaman
Baru-baru ini di Hacker News juga ada diskusi Laravel vs Symphony yang menyinggung bahwa saat mulai kompleks semuanya jadi rusak
Jika pendekatan seperti ini dibandingkan dengan pendekatan rakit-sendiri seperti NodeJS/React SPA dulu, maka tiap komponennya berdiri sendiri sebagai abstraksi level rendah sehingga lebih fleksibel dan lebih mudah diganti sebagian
Memang ada kekurangannya, tetapi tetap terasa lebih mulus daripada overengineering, yaitu kompleksitas yang ditumpuk
Saya sangat paham kenapa solusi batteries included populer
Merangkai berbagai tool dan library lalu memastikan semuanya kompatibel memang sangat merepotkan
Pendekatan rakitan seperti ini biasanya berjalan baik jika ada orang yang lebih berpengalaman yang menyiapkan semuanya
Saya terbiasa dengan asp.net, dan di komunitas developer startup framework ini sering dipandang buruk, tetapi kenyataannya ini framework yang dirancang sangat baik
Memang batteries included, tetapi saya selalu bisa keluar dari framework dan melakukan override kapan pun saya mau, dan tidak pernah sekalipun merasa sedang berperang dengan framework
Blazor Server maupun Blazor Webasm memungkinkan frontend ditulis dengan C#, dan keduanya bagus untuk panel internal atau aplikasi SaaS
Yang terpenting, semuanya juga bisa diselesaikan dengan server-side rendering tradisional
Kalau ada yang frustrasi dengan web framework, saya sangat menyarankan untuk mencobanya
Sekarang dukungan cross-platform-nya juga bagus, cepat, dan mudah dipelajari
Memang ada learning curve, tetapi setelah memahami struktur modulnya, saya langsung bisa meng-override sesuka hati
Dibanding framework lain, sangat jarang saya benar-benar mentok karena batasan framework
Di NodeJS/React SPA, ide merakit komponen seperti itu terasa asing di Angular
Angular adalah framework, bukan sekadar library, jadi kebanyakan hal yang dibutuhkan sudah tersedia di dalamnya
(RxJS memang punya sedikit learning curve, tetapi setelah menguasai dasarnya, itu sangat kuat)
Biasanya saya hampir tidak pernah merasa harus bergulat dengan framework saat membuat SPA
Dokumentasi dan tutorialnya juga sangat bagus, termasuk Tour of Heroes
https://v17.angular.io/tutorial/tour-of-heroes
Dokumentasi terbaru tersedia di https://angular.dev/
Laravel adalah contoh sukses dari abstraksi overengineering
Berkat Laravel, saya tidak pernah menyesal memakainya di production
Agak di luar topik, tetapi pekerjaan saya memang sepenuhnya soal terus-menerus menyambungkan tool dan library kecil yang saling tidak kompatibel sedikit demi sedikit
Tim kami kecil, jadi kami menghabiskan banyak sekali waktu hanya untuk update dan maintenance, dan masalah paket yang dukungannya sudah lama dihentikan juga sering muncul
Bukan cuma pengalaman, waktu awal membangun sistem dan biaya maintenance yang dibutuhkan juga jauh lebih besar daripada yang dibayangkan
Setelah menjalaninya sendiri, saya merasa produktivitas Rails bisa 10 kali lebih tinggi daripada menempelkan library satu per satu di Node
Masalah baru muncul kalau Anda memang tidak suka fondasi dan filosofi framework itu sendiri, misalnya jika Anda membenci ActiveRecord
Kalimat "kalau kompleksitas naik semuanya pasti rusak" itu cuma tanda kemampuan teknis yang kurang
Saya termasuk orang yang sangat membela React, dan saya juga suka perubahan dari class component ke hooks
Tetapi setiap kali memakai Next.js, saya sama sekali tidak bisa menebak dari mana semuanya mulai salah
Saya juga suka banyak framework dan bahasa yang unik, tetapi hanya di Next.js saya mengalami situasi tidak paham bahkan separuh error message-nya
Terutama waktu yang saya habiskan karena hydration issue yang aneh itu sangat besar
Saya sendiri tidak memakai React ataupun Next.js
Secara pribadi saya lebih suka HTML+CSS dengan sedikit vanilla JS
Saya juga pernah mengalami landing page Next.js sederhana rusak di Firefox
Yang lebih parah, bentuk kegagalannya adalah hanya muncul layar hitam dengan tulisan putih di atas seluruh konten: "An application client side error has occurred"
Saya terkejut karena landing page sederhana saja bisa gagal dirender, dan setelah tahu penyebabnya adalah framework frontend JS, reaksi saya cuma, "Ya, masuk akal juga"
Mungkin itu bisa diterima oleh orang-orang yang sedang mencoba meyakinkan pengguna, tetapi bagi orang di luar industri hal seperti itu bisa membingungkan
Saya rasa Next sudah menjadi contoh yang merusak dirinya sendiri
Tempat yang sudah melewati siklus VC memang akhirnya begini
Sekarang saya tidak bisa memakainya lagi, dan Vite menjadi opsi default saya
Saya selalu lebih menyukai solusi yang ringan
Istilah "middleware" di Next.js mudah menimbulkan kesalahpahaman
Pada kenyataannya, itu adalah edge function ringan yang dijalankan sebelum request mencapai aplikasi, misalnya untuk pengecekan header, routing, atau guard sederhana
Ia berjalan di edge runtime, lingkungan yang terpisah dari server aplikasi
Penulisnya juga tampak mencampuradukkan edge dan server runtime
Saya pun awalnya bingung dengan batas-batas itu, dan karena semuanya serba JavaScript, perbedaannya terasa kabur
Menurut saya perlu model mental yang jelas
Menyalahkan kompleksitas Next.js terasa seperti menyalahkan kotak alat karena di dalamnya ada lebih dari sekadar palu
Masalahnya, kompleksitas Next.js adalah sesuatu yang mereka ciptakan sendiri
Istilah middleware sudah punya makna yang sangat jelas di hampir semua framework
Secara umum middleware adalah chain fungsi yang dipanggil sebelum request di runtime, dengan asumsi semuanya berjalan dalam proses yang sama
Next.js malah menaruhnya di edge dan hanya mengizinkan satu
Untuk kebanyakan aplikasi, kemampuan edge seperti ini seharusnya tidak perlu dipakai kecuali ketika memang di-opt-in
Kalau memakai analogi kotak alat, mestinya Anda hanya menambahkan alat yang benar-benar dibutuhkan
Istilah "middleware" tidak seharusnya dipakai dalam konteks seperti ini di Next.js
Ini bukan hanya penggunaan yang salah, tetapi juga penyalahgunaan istilah
Middleware sudah punya definisi lama di industri web app, jadi kalau artinya benar-benar berbeda, istilah itu seharusnya tidak dipakai
Saya memakai app router Next.js dan cukup puas
Dengan Next.js sangat mudah berpindah antara frontend dan backend, sehingga orang-orang tampaknya jadi salah paham seolah bagian ini juga sudah diabstraksikan sepenuhnya
Padahal sebenarnya ini sistem yang sangat kompleks, dan kompleksitas itu tetap harus Anda tanggung sendiri
Kompleksitas yang tinggi tidak selalu berarti lambat atau tidak produktif
Sistem dengan frontend dan backend terpisah memang jauh lebih mudah ditangani, tetapi juga lebih merepotkan
Meski sudah tahu React, belajar Next.js terasa seperti belajar sesuatu yang benar-benar baru, dan ada banyak hal yang tidak akan dipahami tanpa mengalaminya sendiri
Meski begitu, kalau sudah cukup terbiasa, ini sistem yang sangat nyaman karena memudahkan keluar-masuk frontend dan backend
Banyak orang memberi downvote pada komentar saya, tetapi saya ingin tahu alasannya
Saya selalu ingin belajar
Daripada cuma menolak secara membabi buta dalam diskusi seperti ini, saya berharap kita bisa benar-benar berdiskusi
Rasanya akhirnya saya melihat pendapat yang masuk akal
Misalnya, ini seperti sembarangan mencampuradukkan konsep package/module di Python dengan konsep module di Go lalu mengeluh bahwa Go itu buruk
Apa pun teknologinya, pemahaman dasar tentang alat yang dipakai tetap diperlukan
Sejak Next.js beralih ke app router, rasanya seperti perbaikan express API diserahkan kepada lulusan bootcamp
Semua antarmuka server seperti servlet, rack, plug, dan sebagainya punya desain ala boneka Rusia yang terakumulasi selama bertahun-tahun, dan dari sudut itu express API masih termasuk pendekatan yang matang
Selain middleware API yang buruk, keputusan menghilangkan parameter request dan menggantinya dengan fungsi global seperti
cookies()/headers()juga sangat anehSepertinya ada keterbatasan desain mendasar yang tersembunyi di baliknya, tetapi dari luar ini tampak seperti membuang semua pelajaran lama lalu mengulangi kesalahan yang sama
Ditambah lagi dukungan edge runtime lowest common denominator, sehingga batasannya jadi makin parah
Saya selalu berusaha mencoba berbagai stack untuk proyek baru
Saya sudah memakai express+react, angular, vue, next, nuxt, go, .net, node, php, dan lain-lain, baik untuk frontend maupun backend
Di hampir semua framework saya bisa menemukan kelebihan dan kekurangan, dan ada kesenangan tersendiri saat belajar hal baru
Hanya Next.js yang menjadi pengecualian: saat membangun aplikasi yang cukup besar, dari awal sampai akhir setiap bagiannya terasa aneh, lambat, tidak nyaman, atau dirancang secara tidak masuk akal
Saya masih harus memeliharanya sampai sekarang, dan ini satu-satunya "sesuatu" yang benar-benar saya benci
Katanya ekosistemnya bagus dan populer, tetapi dari pengalaman nyata saya, kesannya sudah negatif sampai tidak bisa dipulihkan
Aneh, tapi itulah kenyataannya
Ada yang tahu alamat surat-menyurat Vercel?
Masalah ini tahun depan sudah cukup umur masuk SD, jadi saya ingin mengirim kartu ke perusahaan bertuliskan "Selamat menempuh kehidupan sekolah!"
https://github.com/vercel/next.js/issues/10084
Perkataan di komentar Hacker News di bawah itu memang tepat.
"Next.js punya lapisan abstraksi besar yang tidak diperlukan untuk 99,9999% proyek, dan untuk sedikit kasus yang benar-benar membutuhkannya, menurut saya jauh lebih baik membuat solusi kustom dengan komponen level rendah"
API yang terlalu rumit tanpa alasan, tidak stabil dan belum matang tetapi tetap ngotot dipromosikan sebagai production ready, serta ketergantungan yang sangat besar pada Vercel sehingga kalau bukan di Vercel, menjalankannya secara serius pun jadi sulit.