Bagaimana menjaga agar aplikasi tidak memiliki kewarganegaraan


97

Ini mungkin pertanyaan yang berbelit-belit, tapi saya mencoba untuk mendapatkan pemahaman yang lebih baik tentang kewarganegaraan.

Berdasarkan apa yang saya baca, aplikasi web harus stateless, artinya setiap permintaan diperlakukan sebagai transaksi independen. Akibatnya, Sesi dan Cookies harus dihindari (karena keduanya stateful). Pendekatan yang lebih baik adalah dengan menggunakan Token, yang stateless karena tidak ada yang disimpan di server.

Jadi saya mencoba memahami, bagaimana aplikasi web bisa stateless ketika ada data yang disimpan untuk sesi saya (seperti barang-barang di keranjang belanja)? Apakah ini sebenarnya disimpan dalam database di suatu tempat dan kemudian secara berkala dibersihkan? Bagaimana cara kerjanya saat Anda menggunakan token alih-alih cookie?

Dan kemudian sebagai pertanyaan terkait, apakah situs web utama (Amazon, Google, Facebook, Twitter, dll.) Sebenarnya tanpa kewarganegaraan? Apakah mereka menggunakan token atau cookie (atau keduanya)?


38
Saya telah melihat dan berbicara dengan pengembang akhir-akhir ini yang terobsesi dengan kewarganegaraan sampai-sampai mengganggu. Menyenangkan memiliki kewarganegaraan untuk dapat digunakan kembali tetapi tidak realistis untuk mengejar tujuan itu dalam setiap situasi di atas setiap tujuan lain kecuali Anda memiliki banyak sumber daya untuk melakukan itu karena alasan tertentu, seperti penskalaan.
Mark Rogers

4
@ Markarkog Mengapa? Kewarganegaraan tidak ada hubungannya dengan reusablility. Dan menjadi tanpa kewarganegaraan tidak mengarah pada upaya yang lebih tinggi.
Paul Wasilewski

3
@ PaulWasilewski: Dan menjadi tanpa kewarganegaraan tidak mengarah pada upaya yang lebih tinggi. => ya, dengan aplikasi stateful Anda menyimpan semua yang ada dalam memori terikat pada sesi. Ini tidak skala dengan baik, meskipun bekerja dengan pinning sesi, tapi itu SANGAT sederhana. Ketika server perlu mulai bertukar informasi antara satu sama lain, masalah mulai.
Matthieu M.

6
Melihat amazon, Anda akan melihat bahwa keranjang Anda tetap ada meskipun Anda mengganti komputer, jadi keranjang itu tidak disimpan dalam cookie, melainkan dalam database.
njzk2

20
Jika Anda tidak sempat membaca jawaban saya. Ini versi singkatnya: Permintaan web pada dasarnya tidak memiliki kewarganegaraan. Aplikasi web tidak. (Tidak peduli apa yang dikatakan oleh beberapa dogmatis "stateless web"!)
svidgen

Jawaban:


95

"aplikasi web harus stateless" harus dipahami sebagai "aplikasi web harus stateless kecuali ada alasan yang sangat bagus untuk memiliki status" . "Keranjang belanja" adalah fitur stateful dengan desain, dan menyangkal bahwa itu cukup produktif. Inti dari pola keranjang belanja adalah untuk mempertahankan kondisi aplikasi di antara permintaan.

Alternatif yang dapat saya bayangkan sebagai situs web tanpa kewarganegaraan yang menerapkan keranjang belanja adalah aplikasi satu halaman yang membuat keranjang belanja sepenuhnya sisi-klien, mengambil informasi produk dengan panggilan AJAX dan kemudian mengirimkannya ke server sekaligus ketika pengguna melakukan checkout. Tapi saya ragu saya pernah melihat seseorang benar-benar melakukan itu, karena itu tidak memungkinkan pengguna untuk menggunakan beberapa tab browser dan tidak mempertahankan status ketika mereka secara tidak sengaja menutup tab. Tentu, ada solusi seperti menggunakan penyimpanan lokal, tetapi kemudian Anda memiliki negara lagi, hanya pada klien, bukan pada server.

Setiap kali Anda memiliki aplikasi web yang mengharuskan untuk bertahan data antara tampilan halaman, Anda biasanya melakukannya dengan memperkenalkan sesi. Sesi permintaan milik dapat diidentifikasi oleh cookie atau dengan parameter URL yang Anda tambahkan ke setiap tautan. Cookie harus disukai karena mereka membuat URL Anda lebih praktis dan mencegah pengguna Anda berbagi URL tanpa sengaja dengan id sesi mereka di dalamnya. Tetapi memiliki token URL sebagai cadangan juga penting untuk pengguna yang menonaktifkan cookie. Sebagian besar kerangka kerja pengembangan web memiliki sistem penanganan sesi yang dapat melakukan ini di luar kotak.

Di sisi server, informasi sesi biasanya disimpan dalam database. Caching dalam-sisi-server adalah opsional. Ini dapat sangat meningkatkan waktu respons, tetapi tidak akan memungkinkan Anda untuk mentransfer sesi antara server yang berbeda. Jadi Anda akan membutuhkan database persisten sebagai cadangan.

apakah situs web utama (Amazon, Google, Facebook, Twitter, dll.) sebenarnya tanpa kewarganegaraan? Apakah mereka menggunakan token atau cookie (atau keduanya)?

Apakah mereka mengizinkan Anda untuk masuk? Ketika Anda kemudian menutup tab dan mengunjungi kembali situs tersebut, apakah Anda masih masuk? Jika ya, maka mereka menggunakan cookie untuk menjaga identitas Anda di antara sesi.


46
Saya pikir salah satu kebingungan di sini adalah perbedaan antara "aplikasi web" dalam arti luas dari perspektif pengguna, dan "aplikasi web" dalam arti sempit "kode yang berjalan di server web". Yang terakhir inilah yang sering diargumentasikan sebagai stateless bukan yang pertama. Seperti yang Anda katakan, tidak masuk akal bagi mantan untuk menjadi kewarganegaraan secara umum karena negara biasanya merupakan bagian dari logika bisnis. Agar yang terakhir menjadi tanpa kewarganegaraan berarti keadaan yang harus disimpan pada klien atau server basis data atau keduanya dan bukan pada server web.
Derek Elkins

16
"[...] tetapi kemudian kamu memiliki status lagi, hanya pada klien dan bukan pada server." Ini tentang tidak memiliki status di sisi server, untuk mencapai skalabilitas dan ketersediaan yang lebih baik. Jika keadaan disimpan di sisi klien tidak masalah.
Paul Wasilewski

5
@ njzk2 dapatkah Anda menguraikan sehingga ini kedengarannya tidak masuk akal? Pengguna tidak pergi ke Amazon untuk membeli lebih banyak nama. Dan, setelah mereka melakukan pembelian, sesuatu menghilang yang hanya ada saat mereka berbelanja. Jika sesuatu itu bukan "keadaan aplikasi", lalu apa itu? Jika aplikasi tidak memiliki status, apa yang mereka miliki?

3
@nocomprende: Saya pikir inti umum njzk2 adalah bahwa isi keranjang Anda, seperti nama lengkap Anda, adalah data yang tetap ada di webapp di sisi server. Ketika orang mengatakan, "webapps harus stateless", mereka biasanya berarti sesuatu yang berbeda dari "webapps tidak boleh mengakses database yang berisi nama lengkap Anda yang terkait dengan nama pengguna Anda". Justru apa yang mereka lakukan maksud dengan "stateless" mungkin tidak sepele didefinisikan, karena setelah Anda memiliki database yang ada segala macam omong kosong bahwa Anda bisa bertahan dalam sana, untuk mendukung negara aplikasi terlalu kompleks, tetapi seharusnya tidak ;-)
Steve Jessop

4
@nocomprende: menguraikan telur dengan memutar kembali basis data: karena webapp kami tidak memiliki kewarganegaraan, ia dapat dilanjutkan seperti sebelumnya ;-)
Steve Jessop

56

Memang benar bahwa aplikasi web harus stateless. Namun, variabel sesi, cookie, dan token tidak melanggar ini ketika mereka semua disimpan di klien (browser web). Mereka bisa menjadi parameter dalam permintaan.

Berikut model yang disederhanakan:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

Ini bisa berfungsi untuk Pertukaran Stack Rekayasa Perangkat Lunak . Jawaban yang saya ketikkan ini adalah bagian dari kondisi browser web saya. Selama itu satu-satunya tempat di mana itu berada, itu tidak dapat diakses oleh siapa pun kecuali aku. Tetapi segera setelah saya menekan Post your Answerbrowser saya mengirimkannya ke server web. Server web memproses pos tanpa menggunakan statusnya sendiri. Ia belajar siapa saya dari browser saya dan dari database. Setelah selesai memeriksa posting saya, dan menambahkannya ke database, server web segera melupakan saya.

Itulah arti kewarganegaraan. Server tidak bertanggung jawab untuk mengingat semua ini. Itu bukan tugasnya.

Melakukan ini memiliki banyak keuntungan. Jika server web memiliki kebocoran memori, itu dapat dideteksi karena jejak memorinya tidak boleh bertambah. Jika server web mogok, identitas saya tidak sesuai dengan itu. Jika seseorang mencoba melakukan serangan penolakan layanan, mereka tidak dapat menggunakan sumber daya status server web untuk melakukannya, karena server web tidak mengalokasikan status apa pun untuk mereka di antara sesi. Ini semua bertujuan untuk membuat server web stabil. Dengan begitu, ketika mulai berjalan, ia tetap berjalan.

Sekarang tentu saja, saya mengonsumsi sumber daya dalam basis data, tetapi sumber daya tersebut pertama-tama telah diperiksa terhadap kelonggaran saya oleh sesuatu yang stabil yang dapat kita andalkan untuk melindungi basis data dari web liar dan wol: server web yang memberlakukan aturan bisnis dan tanpa kewarganegaraan.


8
Saya tidak tahu ... Jawaban ini agak mirip dengan mengatakan: " Excel tidak menyimpan spreadsheet Anda, disk drive!" Ha ha, bukankah bagian basis data dari server web, sejauh menyangkut kebanyakan orang? Jelas negara tidak disimpan dalam CPU atau kode server, dan menyimpannya dalam memori cukup konyol.

7
@nocomprende Tidak, database biasanya bukan bagian dari server web Anda. Ya, menyimpan status dalam database sangat mungkin membatasi skalabilitas aplikasi secara keseluruhan, tetapi ada relatif sedikit aplikasi yang dapat membongkar semua statusnya (atau bahkan semua status "per pengguna") ke klien. Server database secara khusus dirancang untuk menangani keadaan secara scalably dan, seperti yang disebutkan oleh CandiedOrange, mereka biasanya lebih terlindungi, disediakan, dan diperiksa dibandingkan server web. Ada manfaat untuk dapat dengan mudah mengukur server web meskipun itu tidak menyelesaikan semua masalah skalabilitas.
Derek Elkins

9
@nocomprende: Maksud mengatakan bahwa basis data bukan bagian dari server web adalah Anda dapat memiliki satu basis data (atau kumpulan basis data) untuk 1, 2, 3, .... webservers. Ini adalah bagaimana menjadi tanpa kewarganegaraan dimaksudkan untuk meningkatkan skalabilitas: Anda dapat skala cluster database dan jumlah webservers secara mandiri.
Matthieu M.

6
"Benar bahwa aplikasi web harus stateless." Tidak. Ini omong kosong.
svidgen

4
Jawaban ini adalah yang paling saya sukai karena ini menggambarkan penggunaan "stateless" di web dev. Server tidak mempertahankan status di antara permintaan. Semua negara harus berasal dari klien (yaitu, bagian dari permintaan) atau dari database (kemungkinan berdasarkan permintaan). Selain itu, sering kali ada beberapa keadaan dalam aplikasi web (misalnya, hal-hal statis), tetapi secara umum, Anda ingin merancang sesuatu menjadi tanpa kewarganegaraan. Jawaban ini tampaknya lebih baik daripada yang diterima untuk benar-benar menjelaskan gagasan tentang kewarganegaraan.
Kat

30

aplikasi web harus stateless

Omong kosong. Permintaan web harus tanpa kewarganegaraan. Atau lebih tepatnya, permintaan web tidak memiliki kewarganegaraan.

Tapi, mengatakan bahwa seluruh aplikasi harus stateless adalah omong kosong.

setiap permintaan diperlakukan sebagai transaksi independen.

Ya persis . Atau lebih tepatnya, ya, tentu saja . Melalui HTTP, setiap permintaan secara inheren tidak tergantung dari semua permintaan lainnya. Menambahkan "status" ke HTTP mengharuskan Anda secara eksplisit mengidentifikasi, menyimpan, dan mengambil "status" untuk setiap permintaan "status". Dan itu membutuhkan upaya, menurunkan kinerja, dan menambah kompleksitas.

Dan, untuk alasan itu, setiap permintaan yang bisa stateless "harus" stateless.

Akibatnya, Sesi dan Cookies harus dihindari (karena keduanya stateful). Pendekatan yang lebih baik adalah menggunakan Token

Beberapa hal: Token dapat dikaitkan dengan penyimpanan sesi juga. Cookie tidak perlu dikaitkan dengan penyimpanan sesi. Token sering disimpan dalam cookie. Dan, terkadang sesi hanyalah alat yang tepat untuk pekerjaan itu.

Itu berarti bahwa setidaknya kadang-kadang , sesi dan cookie sama "lebih baik" dengan token!

[Token] tidak memiliki kewarganegaraan karena tidak ada yang disimpan di server.

Baiklah, itu saja. Itulah dogma "tanpa kewarganegaraan" sebenarnya. Meskipun, untuk lebih jelasnya, ini bukan tentang menyimpan "tidak ada" di server, ini tentang tidak menyimpan status sesi di server.

Kotak masuk Gmail saya dalam keadaan, misalnya. Dan sebaiknya disimpan di server! Tapi, ini bukan status sesi .

Jadi, alih-alih memiliki server yang dapat mengambil pengenal kecil dan mencari tahu siapa Anda dan sebagainya, aplikasi kewarganegaraan ingin diingatkan siapa Anda dan apa yang Anda lakukan dengan setiap permintaan berdarah. Status aplikasi masih ada, klien hanya bertanggung jawab untuk memegangnya.

Sekarang, jika keadaan itu kecil, itu mungkin OK. Dalam beberapa kasus itu sangat bagus.

Dan kemudian, tentu saja, ada hal-hal yang kita harapkan menjadi negara ...

bagaimana aplikasi web bisa stateless ketika ada data yang disimpan untuk sesi saya (seperti barang-barang di keranjang belanja)? Apakah ini sebenarnya disimpan dalam database di suatu tempat dan kemudian secara berkala dibersihkan?

Dua pilihan. Entah Anda memiliki sesi, atau Anda menyangkal!

... Tapi serius. Anda biasanya tidak menyimpan keranjang dalam cookie. Sesuatu seperti kereta belanja akan disimpan dalam sesi "tradisional", atau akan disimpan sebagai Cartobjek, dengan semacam ID yang digunakan server untuk menariknya ke permintaan berikutnya. Agak seperti .. uhh ... ... err ... sesi.

Untuk yang benar-benar serius: Ada tingkat besar di mana "keadaan" adalah apa yang kita sebut ketika dua agen yang berkomunikasi dapat mengontekstualisasikan pesan dalam percakapan. Dan sebuah sesi, secara tradisional dipahami, adalah apa yang biasanya kita sebut mekanisme yang dengannya hal ini terjadi.

Saya berpendapat bahwa, terlepas dari apakah Anda menggunakan token atau "sesi," untuk setiap permintaan yang ditangani oleh server Anda, Anda harus mengontekstualisasikan permintaan untuk memenuhinya, atau tidak. Jika konteksnya tidak perlu, jangan ambil. Jika konteksnya adalah diperlukan, Anda lebih baik memilikinya terdekat!

Dan kemudian sebagai pertanyaan terkait, apakah situs web utama (Amazon, Google, Facebook, Twitter, dll.) Sebenarnya tanpa kewarganegaraan? Apakah mereka menggunakan token atau cookie (atau keduanya)?

Mungkin keduanya. Tetapi, secara umum, mereka melakukan persis apa yang Anda lakukan: Mereka mengatur cookie untuk mengidentifikasi catatan "status" dalam database "sesi" besar-besaran.

Jika memungkinkan, saya menduga mereka mendorong klaim identitas dasar menjadi "token" berumur pendek untuk menghindari pertengkaran yang tidak perlu pada penyimpanan terpusat. Tetapi, fakta bahwa banyak dari layanan ini mengizinkan saya untuk "keluar dari semua lokasi lain" adalah indikator yang baik bahwa, jika mereka menggunakan token sama sekali, mereka setidaknya "didukung" oleh model sesi semi-tradisional .


3
Setuju. Itu mengingatkan saya pada ide "data abadi". Jika tidak berubah, ukir di batu, jangan sia-siakan komputer untuk melakukannya. Biarkan komputer melakukan hal-hal dengan data! Itu sebabnya kami membangunnya! Aplikasi bekerja dengan data. Data yang konstan tidak berguna.

@nocomprende FYI, saya akan membuat lampiran untuk ini nanti. Saya merasa jawaban saya hilang dari pertanyaan mendasar OP. Karena, ada adalah kekhawatiran legit mengambang di balik ide "aplikasi stateless". Tapi, jawabannya adalah sepanjang garis, ketika orang mengatakan 'stateless', apa yang mereka maksud katakan adalah 'bergantung minimal pada sesi server-side.'
svidgen

4
@nocomprende: struktur data yang tidak dapat diubah adalah sesuatu yang berbeda, dan merupakan alat yang digunakan untuk mengelola siklus hidup objek memori.
whatsisname

1
Sukai penjelasan pertama Anda. Ketika kita membahas sesuatu, setiap pernyataan verbal yang kita buat langsung lenyap hingga terlupakan. Tapi entah bagaimana, kita masih bisa melakukan percakapan, eh? Itu sihir!

1
@nocomprende Ini adalah diskusi yang menarik, tapi saya kira kita tidak harus melanjutkannya di sini.
pabrams

14

Statefulness tidak selalu merupakan hal yang buruk, tetapi Anda perlu memahami perbedaan antara aplikasi stateful dan stateless. Singkatnya, aplikasi stateful menjaga informasi tentang sesi saat ini, dan aplikasi stateless tidak. Informasi yang disimpan secara permanen sebagai bagian dari akun pengguna mungkin atau mungkin tidak disimpan dalam suatu sesi, tetapi menyimpan informasi yang terkait dengan akun pengguna tidak dengan sendirinya membuat aplikasi menjadi stateful. Statefulness mengharuskan server mempertahankan informasi tentang sesi pengguna saat ini di luar apa yang dipertahankan oleh browser klien. Misalnya, klien dapat mengotentikasi dan diberi cookie JSESSIONID, yang kemudian dikirimkan ke server dengan setiap permintaan. Jika server mulai menyimpan hal-hal dalam lingkup sesi aplikasi berdasarkan JSESSIONID ini, itu menjadi stateful.

Kewarganegaraan

Dengan stateless, maksud kami adalah server dan klien tidak menjaga informasi terkini tentang sesi pengguna. Klien dan server dapat menggunakan beberapa bentuk token untuk menyediakan otentikasi antara permintaan, tetapi tidak ada informasi terkini lainnya yang disimpan. Kasus penggunaan yang umum untuk solusi semacam itu mungkin adalah situs berita tempat sebagian besar pengguna (konsumen baru) mengonsumsi informasi tetapi tidak menghasilkan informasi yang kembali ke situs tersebut. Dalam kasus seperti itu, situs tidak perlu menyimpan informasi tentang sesi pengguna saat ini. Perhatikan bahwa situs tersebut mungkin masih menggunakan cookie untuk mengidentifikasi pengguna dan menyimpan informasi tentang penggunaan situs tersebut oleh pengguna tersebut, tetapi itu mungkin masih dianggap sebagai stateless karena semua yang direkam dapat bersifat transaksional, misalnya tautan apa yang diklik pengguna, yang mungkin direkam oleh server, tetapi tidak dikelola dalam sesi pengguna.

Statefulness di server

Di server, aplikasi stateful menyimpan informasi status tentang pengguna saat ini. Pendekatan ini umumnya melibatkan penggunaan cookie untuk mengidentifikasi sistem pengguna sehingga keadaan dapat dipertahankan di server di antara permintaan. Sesi dapat diotentikasi atau tidak, tergantung pada konteks aplikasi. Aplikasi server stateful menawarkan keuntungan dari caching informasi status pengguna di server, mempercepat pencarian dan waktu respons halaman. Di sisi bawah, menyimpan informasi dalam ruang lingkup sesi mahal, dan pada skala itu menjadi sangat intensif sumber daya. Ini juga menciptakan vektor serangan potensial bagi peretas untuk mencoba dan membajak pengidentifikasi sesi dan mencuri sesi pengguna. Aplikasi server stateful juga memiliki tantangan melindungi sesi pengguna terhadap gangguan layanan yang tidak terduga, misalnya kegagalan server.

Statefulness pada klien

Menggunakan JavaScript dan teknologi browser modern seperti sessionStorage, aplikasi sekarang dapat dengan mudah menyimpan informasi status tentang sesi pengguna pada perangkat pengguna itu. Secara keseluruhan, aplikasi mungkin masih dianggap stateful, tetapi pekerjaan mempertahankan status telah dipindahkan ke klien. Pendekatan ini memiliki keuntungan besar (untuk pemelihara aplikasi Web) dibandingkan mempertahankan status pada server karena setiap pengguna, pada dasarnya, mempertahankan status mereka sendiri, dan tidak ada beban pada infrastruktur server. Pada skala web, pilihan arsitektur semacam itu memiliki dampak besar untuk biaya perangkat keras dan listrik. Harganya jutaan dolar per tahun untuk mempertahankan status di server. Pindah ke sistem yang mempertahankan status klien dapat menghemat jutaan dolar per tahun.

Token v. Cookie

Cookie bertindak sebagai pengidentifikasi untuk perangkat / browser klien. Mereka dapat digunakan untuk menyimpan segala macam hal, tetapi umumnya mereka menyimpan beberapa bentuk pengidentifikasi, seperti CFID / CFTOKEN di aplikasi CFML. Cookie dapat diatur untuk hidup di browser pengguna untuk waktu yang lama, memungkinkan untuk melakukan hal-hal seperti mempertahankan otentikasi pada aplikasi di antara sesi browser. Cookie juga dapat diatur ke memori saja sehingga mereka kedaluwarsa ketika pengguna menutup browser.

Token umumnya semacam mengidentifikasi informasi tentang pengguna yang dihasilkan di server (menggunakan enkripsi untuk mengacak informasi), diteruskan ke klien, dan dikembalikan ke server dengan permintaan berikutnya. Mereka mungkin diteruskan di header permintaan dan tanggapan, yang merupakan pola umum dalam aplikasi satu halaman. Idealnya, setiap permintaan / respons menghasilkan pembuatan token baru, sehingga token tidak dapat dicegat dan digunakan nanti oleh penyerang.

Aplikasi Halaman Tunggal dan status klien

Dengan SPA, informasi status dimuat ke browser klien dan dipertahankan di sana. Ketika keadaan berubah, misalnya Anda memposting pembaruan ke akun media sosial Anda, klien menyampaikan transaksi baru itu ke server. Dalam hal ini, server menyimpan pembaruan itu ke penyimpanan data yang persisten seperti database, dan menyampaikan informasi apa pun kembali ke klien yang perlu disinkronkan dengan server berdasarkan pembaruan (misalnya ID untuk pembaruan).

Perhatikan bahwa pola penyimpanan ini pada klien menawarkan keuntungan untuk pengalaman online / offline di mana Anda dapat terputus dari server sementara masih memiliki aplikasi yang agak dapat digunakan. Twitter adalah contoh yang bagus untuk kasus ini, di mana Anda dapat meninjau apa pun yang dimuat sisi klien dalam umpan Twitter Anda, bahkan jika Anda terputus dari aplikasi server Twitter. Pola ini juga menciptakan kompleksitas dalam sinkronisasi antara server dan klien, yang merupakan subjek tersendiri. Kompleksitas dari solusi adalah tradeoff untuk dapat mempertahankan keadaan pada klien.

Statefulness pada klien membuat aplikasi web merasa dan berperilaku lebih seperti aplikasi desktop tradisional. Tidak seperti aplikasi desktop, Anda biasanya tidak akan memiliki semua informasi akun Anda dimuat ke dalam sesi klien Anda di browser. Melakukan hal itu dalam banyak kasus akan menjadi tidak praktis dan menghasilkan pengalaman buruk. Bisakah Anda bayangkan mencoba memuat seluruh kotak Gmail ke browser? Sebagai gantinya, klien menyimpan informasi seperti apa label / folder yang Anda lihat dan di mana dalam daftar email di folder yang Anda cari. Menyeimbangkan informasi negara mana yang harus dipertahankan dan apa yang diminta sesuai kebutuhan adalah tantangan rekayasa lain dari pola ini, dan sekali lagi, ini mewakili pertukaran antara kepraktisan dan memberikan pengalaman pengguna yang baik.

Kereta belanja dan sejenisnya

Adapun spesifik seperti gerobak belanja, itu sangat tergantung pada solusinya. Keranjang belanja dapat disimpan dalam database di server, mungkin hanya disimpan dalam ruang lingkup sesi di server, atau bahkan dapat disimpan di klien. Amazon memiliki gerobak belanja persisten untuk pengguna yang masuk, dan gerobak "sementara" untuk pengguna anonim, meskipun gerobak ini persisten sampai batas tertentu.

Ketika Anda berbicara tentang sesuatu seperti Google, yang sebenarnya adalah sekelompok aplikasi berbeda yang hidup di bawah merek yang sama, mereka mungkin tidak berbagi arsitektur yang sama, dan masing-masing dibangun dengan cara yang paling memenuhi kebutuhan penggunanya. Jika Anda ingin mempelajari cara membangun situs, buka alat pengembang di browser Anda dan lihatlah. Periksa kuki, tonton lalu lintas jaringan, dan lihat cara kerjanya.

Maaf jika jawaban ini sedikit mengoceh, tetapi status adalah subjek yang kompleks.


6

Sesi dan cookie tidak harus dihindari. Anda masih dapat memilikinya dengan aplikasi web stateless.

Ada perbedaan besar antara Java dan Ruby on Rails. Aplikasi Java akan menyimpan sesi dalam memori menggunakan kunci sesi yang disimpan dalam cookie. Ini cepat untuk mengambil status pengguna dan keranjang belanja. Namun, Anda harus selalu menekan server yang sama dengan sesi Anda.

Aplikasi Rails menyimpan id pengguna dalam cookie yang ditandatangani dan dienkripsi. Itu tidak bisa dirusak. Saat Anda memuat halaman, aplikasi web mengambil status, pengguna, dan keranjang belanja Anda dari database. Ini lebih lambat, tetapi kuncinya adalah, Anda dapat menekan instance apa pun ! Ini memungkinkan Anda untuk memulai kembali, menskala, mematikan contoh sesuka hati. Sangat mudah. Itu juga dapat dibuat lebih cepat dengan database cache bersama, dalam memori, seperti Redis. Atau Anda dapat menyimpan keranjang belanja di cookie, asalkan cukup kecil.

Jadi Anda bisa mencapai kewarganegaraan, melalui teknik-teknik pintar, dan menambahkan kemampuan untuk mengukur sesuka hati.



5

Ketika merujuk pada stateless - mis. Dalam Layanan HTTP RESTful - ini akan menghindari menyimpan keadaan di sisi server. Paling-paling, itu termasuk juga menghindari menyimpan negara dalam database atau penyimpanan persisten lainnya di backend. Untuk memperjelas saya berbicara tentang keadaan bukan data secara umum. Tampaknya beberapa pria mencampuradukkan semuanya.

Komunikasi tanpa kewarganegaraan memiliki beberapa manfaat terutama mengenai skalabilitas dan ketersediaan.

Pendekatan yang lebih baik adalah dengan menggunakan Token, yang stateless karena tidak ada yang disimpan di server.

Itu benar (untuk protokol otentikasi dan otorisasi tertentu). Token dapat (tetapi tidak secara langsung) memberikan semua informasi dalam permintaan yang diperlukan untuk mengotentikasi pengguna atau mengotorisasi tindakan. Sebagai contoh, lihat JWT .

Jadi saya mencoba memahami, bagaimana aplikasi web bisa stateless ketika ada data yang disimpan untuk sesi saya (seperti barang-barang di keranjang belanja)? Apakah ini sebenarnya disimpan dalam database di suatu tempat dan kemudian secara berkala dibersihkan? Bagaimana cara kerjanya saat Anda menggunakan token alih-alih cookie?

Mengenai contoh keranjang belanja. Tidak ada masalah untuk menyimpan semua item keranjang di sisi klien tanpa menggunakan sesi atau cookie. Anda dapat menemukan contohnya di smashingmagazine.com . Tetapi mungkin juga untuk mewujudkan keranjang belanja tanpa kewarganegaraan dengan cookie (setidaknya jika bermacam-macam Anda tidak begitu besar dan penyimpanan 4kb sudah cukup untuk Anda).

Jangan salah paham, itu tidak berarti Anda harus menerapkan keranjang belanja tanpa kewarganegaraan dengan harga berapa pun. Amazon atau platform belanja online besar lainnya menggunakan implementasi kereta belanja stateful karena pengalaman pengguna dan kegunaan lebih penting bagi mereka daripada menyesuaikan persyaratan teknis non-fungsional seperti skalabilitas.

Secara umum, token tidak digunakan untuk menyimpan informasi seperti item keranjang. Mereka digunakan untuk otentikasi dan otorisasi tanpa kewarganegaraan.

Dan kemudian sebagai pertanyaan terkait, apakah situs web utama (Amazon, Google, Facebook, Twitter, dll.) Sebenarnya tanpa kewarganegaraan? Apakah mereka menggunakan token atau cookie (atau keduanya)?

Jika Anda bertanya apakah mereka menggunakan cookie atau token untuk otentikasi, jawabannya adalah mereka menggunakan keduanya. Untuk pengguna sebagian besar cookie untuk klien teknis sebagian besar token digunakan.


-2

Oke, aturan yang Anda kutip secara teknis salah. Semua lapisan aplikasi web memiliki status.

Maksud aturan ini adalah "jangan pegang sisi server negara bagian per sesi".

Yakni, variabel sesi dalam ASP , yang biasanya digunakan untuk melakukan hal-hal seperti item dalam keranjang / nama pengguna, dll.

Alasannya adalah Anda kehabisan memori di server karena aplikasi Anda mendapatkan lebih banyak pengguna. Memindahkan penyimpanan ke database atau cache bersama tidak menyelesaikan masalah karena Anda masih mengalami hambatan.

Untuk mempertahankan status aplikasi per pengguna tanpa memukul masalah ini, pindahkan status ke sisi klien. Misalnya, masukkan item keranjang ke dalam cookie atau penyimpanan sisi klien yang lebih canggih.

Karena jumlah klien berskala dengan jumlah pengguna, aplikasi Anda secara keseluruhan tidak akan mengalami hambatan dan skala akan baik.


2
Sementara kebocoran memori dan penolakan masalah layanan merupakan faktor, saya pikir driver yang lebih signifikan saat ini adalah elastisitas dan ketahanan terhadap kegagalan server web yang, tentu saja, juga terkait dengan skalabilitas. Idenya adalah jika sebuah server kelebihan beban atau bahkan crash, saya hanya bisa mengubah rute permintaan masa depan (dan dengan sedikit lebih hati-hati bahkan memutar ulang permintaan yang gagal) ke server web baru tanpa koordinasi atau kehilangan negara (seperti yang dilihat pengguna).
Derek Elkins

jenis hmm. Jika Anda memiliki per info pengguna di server, meskipun didistribusikan, Anda masih memiliki masalah skalabilitas.
Ewan

Ada banyak yang dapat Anda lakukan jika menarik data dari disk adalah hambatan seperti caching.
JeffO

tidak, ada masalah bawaan jika Anda memegangnya per data sesi. baik Anda memindahkannya dari server web ke sistem ketersediaan tinggi sendiri atau membuang semuanya bersama-sama dengan memindahkannya ke klien
Ewan

1
Semua diskusi tentang mencoba menghindari kentang panas ini benar-benar membingungkan saya. Apa yang terjadi pada pepatah lama, "Uang berhenti di sini"? Sesuatu harus mengelola data, bank saya tidak ingin saya menyimpan semua informasi transaksi keuangan saya hanya di laptop saya. Mengapa semua orang melarikan diri menjerit dari data? Itu sebabnya kami memiliki komputer! Gila.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.