Next.js: Gunakan sistem file sebagai REST API orang miskin

Dibuat pada 10 Nov 2016 · 3Komentar · Sumber: vercel/next.js

Saya melihat banyak orang di Slack dan di berbagai Masalah GitHub meminta semacam solusi backend. Meskipun saya dapat bersimpati dengan pernyataan @rauchg bahwa "Pengambilan data terserah pengembang", memiliki solusi dasar yang dengan cepat membantu pemula memulai dengan next.js saja akan bernilai emas. Dengan ekstensi sederhana dari ide bagus "sistem file sebagai API", kami dapat memperkenalkan folder api/ yang berisi file .json, yang kemudian akan secara otomatis diekspos sebagai JSON REST API.

Jadi /api/posts.json akan secara otomatis membuat titik akhir koleksi GET http://example.com/api/posts/. Bergantung pada apakah koleksi posts.json berisi larik atau kamus tingkat atas, item koleksi individual juga akan diekspos sebagai titik akhir GET dari formulir http://example.com/api/posts/123/ atau http:// example.com/api/posts/abc/.

Bergantung pada keinginan untuk kompleksitas di sisi pelaksana (yaitu @nkzawa dan tim zeit lainnya), API REST dasar ini dapat berupa hanya-baca atau juga dapat ditulisi, dalam kasus terakhir berfungsi sebagai basis data orang miskin. Ini mungkin akan mengalami keterbatasan yang mengerikan (masalah konkurensi?), Tetapi tetap dapat digunakan untuk situs kecil dengan volume rendah dan berharga untuk pemula.

Ini akan memungkinkan next.js menjadi solusi webdev full-stack lengkap untuk pemula, dan menghilangkan kelebihan kognitif karena harus memilih dan mempelajari cara menggunakan salah satu mikro, ekspres, koa/koa2, hapi atau feathersJS untuk membuat API sendiri (dengan asumsi kita ingin menggunakan node.js untuk backend), atau memilih dan mempelajari cara menggunakan beberapa Backend-as-a-Service seperti RethinkDB+Horizon, Firebase, Parse, Graph.cool atau database lain yang memaparkan JSON REST API atau GraphQL API. Beberapa dari pendekatan ini tentu saja akan menjadi pilihan yang jauh lebih baik untuk penerapan produksi, tetapi begitu pengguna memulai dengan JSON REST API berbasis file bawaan, mereka akan dengan mudah dapat bermigrasi ke API buatan sendiri pihak ketiga yang sebenarnya.

Mungkin ini dapat dikoordinasikan dengan proposal @rauchg untuk API komponen, yang dirinci di sini: #149.

Sumber

olifante

👎3 ❤1

Komentar yang paling membantu

Saya memiliki pengalaman yang cukup bagus dengan Meteor. Kerangka kerja tumpukan penuh tidak akan berfungsi dalam jangka panjang. Kami mempelajarinya dengan cara yang sulit.

Ini akan menjadi solusi yang cukup bagus untuk tahap pembuatan prototipe, tapi saya harap bukan itu yang akan kita lakukan dengan proyek ini.
Backend/data adalah pekerjaan yang cukup kompleks. Itu selalu lebih baik untuk membiarkan sesuatu yang lain melakukan itu.

Saya pikir fokus kita harus ini seperti yang disebutkan pada deskripsi Next.

Kerangka kerja minimalis untuk aplikasi React yang dirender oleh server

arunoda pada 11 Nov 2016

👍14 ❤3

Semua 3 komentar

Saya memiliki pengalaman yang cukup bagus dengan Meteor. Kerangka kerja tumpukan penuh tidak akan berfungsi dalam jangka panjang. Kami mempelajarinya dengan cara yang sulit.

Saya pikir fokus kita harus ini seperti yang disebutkan pada deskripsi Next.

Kerangka kerja minimalis untuk aplikasi React yang dirender oleh server

arunoda pada 11 Nov 2016

👍14 ❤3

Saya memahami keberatannya, tetapi faktanya tetap bahwa kelebihan kognitif adalah kenyataan, dan banyak orang lumpuh karena pilihan. Pendatang baru di node.js bingung dengan banyaknya opsi untuk membangun JSON REST API. Memiliki sesuatu yang minimal di next.js akan memungkinkan banyak pemula untuk segera mulai menggunakan next.js sebagai salah satu generasi baru dari fullstack (dalam arti mendukung backend dan frontend, bukan dalam arti maksimal) alat webdev React universal yang sepenuhnya merangkul ECMAScript 6.

Jangan lupa bahwa mikro memang mikro: sekitar 100 baris kode. Akan mudah untuk menggabungkan atau menggabungkan mikro ke next.js untuk mendukung pembuatan REST API minimal.

Ini sangat menarik ketika Anda mempertimbangkan bahwa next.js sangat jelas telah memukul saraf yang tidak dimiliki mikro. Jumlahnya tidak bohong: dalam waktu kurang dari 2 minggu sejak dirilis, next.js telah menghasilkan 241 masalah dan menarik permintaan di GitHub. Bandingkan angka-angka itu dengan mikro: 73 masalah dan permintaan tarik (dan saat ini tidak ada yang terbuka), untuk proyek yang komit pertamanya dibuat hampir dua tahun lalu.

Saat ini ada kekosongan besar di dunia kerangka kerja web node.js minimal. Tak satu pun dari Express, Koa, Koa2, Hapi, FeathersJS merangkul ES6, React, rendering universal, dan perutean intuitif seperti yang dilakukan next.js. Untuk tidak mengatakan fakta bahwa pengembangan Express tampaknya sudah mati, dan Koa terperosok dalam transisi ke Koa 2 dan tampaknya tidak menghasilkan banyak energi pengembang, melihat grafik komitnya. FeathersJS terikat dengan Express, dan bahkan pindah ke Koa hanya akan membawa warisan masalah Koa sendiri. Itu meninggalkan Hapi, yang saat ini tampaknya menargetkan lebih banyak aplikasi web perusahaan, dan sejauh yang saya lihat masih belum merangkul ES6, apalagi mendukung React universal atau bahkan React biasa.

Ada jendela peluang untuk proyek next.js menjadi sangat besar. Saya sudah melihatnya memberi Facebook sendiri buat-bereaksi-aplikasi untuk mendapatkan uangnya dalam hal daya tarik pengembang.

Sebagai poin terakhir, pertimbangkan apa yang terjadi di dunia Python ketika Armin Ronacher merilis Flask, kerangka web minimalnya sebagai lelucon bodoh April. Dalam pikirannya, itu tidak lebih dari gula sintaksis yang mengawinkan server Werkzeug-nya dengan bahasa templating Jinja2. Untungnya, dia cukup gesit untuk mengenali popularitas Flask yang langsung bahwa dia sedang melakukan sesuatu. Hasilnya adalah datang (sepertinya) entah dari mana, Flask dengan cepat menjadi pilihan kedua yang kuat bagi Django untuk web dev di dunia Python (dan pilihan pertama bagi banyak orang yang menghindari raksasa terintegrasi monolitik seperti Django).

Dengarkan pengguna. Ada banyak orang yang menuntut fungsionalitas sisi server, sebuah ide yang dapat dengan mudah diperluas untuk menyertakan dukungan built-in untuk JSON REST API berbasis file yang mendukung etos ramah pengguna yang sama dari pemanfaatan kembali ide terbaik PHP yang brilian: sistem file sebagai API.

olifante pada 11 Nov 2016

👍6

Saya setuju sepenuhnya dengan @arunoda. _Fitur_ terbesar dari Next.js adalah _bukan backend_. Itu lebih dekat dengan apa yang @getify panggilan _middle-end_. Tampilan depan rendering universal.

Arsitektur terbaik yang digabungkan dengan ini adalah layanan data Next.js _queries_ di getInitialProps . Layanan mikro REST, API, dan GraphQL adalah pelengkap yang bagus untuk arsitektur ini.

Ini mengatakan, harap perhatikan # 25 karena itu akan memungkinkan Anda untuk mencapai ini di userland. Anda dapat secara otomatis mendaftarkan rute dan memasangkannya ke server khusus yang Anda inisialisasi.