Keuntungan apa yang diberikan dengan menggunakan rendering halaman sisi server?

19

Saya sedang mengembangkan aplikasi web dan saat ini saya telah menulis seluruh situs web dalam html / js / css dan di backend saya memiliki servlets yang meng-host beberapa layanan RESTFUL. Semua logika presentasi dilakukan melalui mendapatkan objek json dan mengubah tampilan melalui javascript.

Aplikasi ini pada dasarnya adalah mesin pencari, tetapi akan memiliki akun pengguna dengan peran yang berbeda.

Saya telah meneliti beberapa kerangka kerja seperti Play dan Spring. Saya cukup baru dalam pengembangan web, jadi saya bertanya-tanya apa keuntungan menggunakan rendering halaman sisi server?

Apakah itu: Kecepatan? Pengembangan dan alur kerja yang lebih mudah? Akses ke perpustakaan yang ada? Lebih? Semua yang di atas?

javascript  web-applications  frameworks 
— pengguna1303881
sumber
4
Keamanan adalah yang besar. Terutama ketika aplikasi itu dinamis dan perlu berkomunikasi dengan database.
— Oded
2
@Oded - Mengapa keamanan lebih mudah dilakukan ketika Anda merender halaman vs di API? Saya selalu berpikir bahwa apa yang Anda harus program sama dengan cara apa pun, tetapi secara psikologis lebih mudah (setidaknya bagi saya) untuk mengingat untuk tidak mempercayai klien ketika melakukan API. Saya bertanya karena jika saya mengabaikan sesuatu saya benar-benar ingin tahu.
— psr
1
@psr. Dia mungkin tidak mengacu pada keamanan data sebanyak keamanan pengguna (Misalnya eksploitasi MITM). Tapi tebak saja.
— maple_shaft
1
@psr - Setuju. Namun, baru kemarin saya menjawab pertanyaan di mana OP memiliki string koneksi yang tertanam di JS ...
— Oded
1
@maple_shaft - MITM adalah sesuatu untuk dipikirkan, tapi sekali lagi saya tidak yakin mengapa itu membuat perbedaan untuk HTML yang dihasilkan API vs. Saya kira API lebih nyaman untuk diprogram melawan, jadi itu akan menjadi sedikit lebih mudah retak, tapi saya ragu itu yang Anda maksud.
— psr

Jawaban:

16

Rendering HTML sisi server:

  • Perenderan browser tercepat
  • Caching halaman dimungkinkan karena peningkatan kinerja yang cepat dan kotor
  • Untuk aplikasi "standar", banyak fitur UI sudah dibuat sebelumnya
  • Terkadang dianggap lebih stabil karena komponen biasanya tunduk pada validasi waktu kompilasi
  • Bersandar pada keahlian backend
  • Terkadang lebih cepat berkembang *

* Ketika persyaratan UI cocok dengan kerangka kerja dengan baik.

Rendering HTML sisi klien:

  • Penggunaan bandwidth yang lebih rendah
  • Membuat laman awal lebih lambat. Bahkan mungkin tidak terlihat di browser desktop modern. Jika Anda perlu mendukung IE6-7, atau banyak peramban seluler (webkit seluler tidak buruk), Anda mungkin menemui hambatan.
  • Membangun API-pertama berarti klien dapat dengan mudah menjadi aplikasi berpemilik, thin client, layanan web lain, dll.
  • Bersandar pada keahlian JS
  • Terkadang lebih cepat berkembang **

** Ketika UI sebagian besar khusus, dengan interaksi yang lebih menarik. Juga, saya menemukan pengkodean di browser dengan kode yang ditafsirkan terasa lebih cepat daripada menunggu kompilasi dan restart server.

Anda mungkin juga mempertimbangkan model hybrid dengan implementasi backend ringan menggunakan sistem templating front-end / back-end seperti kumis .

— peteorpeter
sumber
1
Whoah, benar-benar lupa tentang peluang caching!
— Michael K
"Untuk aplikasi" standar ", banyak fitur UI yang dibuat sebelumnya" Itu tidak relevan, baik server maupun klien memilikinya.
— Raynos
@ Raynos Dia tidak menyebutkan menggunakan kerangka kerja sisi klien , tetapi jika dia menggunakannya, itu poin yang bagus.
— peteorpeter
1
Terima kasih, ini sebagian besar jawaban yang saya cari. Saya belum melakukan terlalu banyak dengan kerangka kerja sisi klien, tapi saya sedang melakukan penelitian tentang dust.js berdasarkan pilihan LinkedIn. Saya tahu bahwa kumis adalah alternatif, tetapi saya akan lebih banyak meneliti. Saya mungkin akan melakukan semacam hybrid, terutama saya ingin mendorong sesuatu ke sisi server jika itu dapat meningkatkan kinerja. Terima kasih lagi.
— user1303881
Saya tidak akan benar-benar mempertimbangkan apa pun yang terdaftar untuk "rendering HTML sisi klien" sebagai keuntungan. "Terkadang lebih cepat berkembang" terbang keluar jendela sekali lagi dari yang dipertimbangkan oleh browser canggih (IE 8, dll.).
— null
3

generasi HTML sisi server:

  • lebih mudah untuk di-debug;
  • tidak ada masalah dengan kompatibilitas browser;
  • dengan generasi sisi server satu halaman penuh lebih sulit untuk men-cache HTML, bahkan jika ia memiliki bagian-bagian yang berbeda; (solusinya adalah mengambil fragmen HTML melalui panggilan AJAX);
  • tidak memanfaatkan caching-proxy dan CDN untuk HTML dinamis;

generasi HTML sisi klien:

  • lebih sulit untuk di-debug;
  • beberapa masalah dengan browser yang usang;
  • tidak ada masalah dalam cache HTML-templates sisi klien;
  • memanfaatkan caching-proxy dan CDN untuk templat HTML dan kode JS;
  • penggunaan jaringan yang jauh lebih rendah;

Perhatikan, bahwa generasi sisi klien adalah cara yang dilakukan dalam kasus situs seluler yang sukses, karena tampaknya itu lebih efisien dengan browser modern (browser berbasis WebKit memiliki sekitar 70-80% pasar ponsel).

LinkedIn memiliki artikel tentang keuntungan pendekatan sisi klien menggunakan dust.js sebagai contoh: "Membiarkan JSP di debu: memindahkan LinkedIn ke templat sisi klien dust.js"

— vartec
sumber
1
+1 Pada smartphone modern (terutama menggunakan webkit mobile), JS tidak cenderung mengalami bottleneck, sedangkan bandwidth jaringan-sel adalah .
— peteorpeter
1

Itu tergantung pada apa kebutuhan Anda. Jika Anda membutuhkan kinerja tinggi, solusi latensi rendah yang bergantung pada banyak tugas kecil, Anda dapat menggunakan struktur yang serupa dengan yang Anda gambarkan. Solusi paling umum, di Java, PHP, dan C # tidak default untuk ini.

Sebagian besar aplikasi web sangat bergantung pada database - kebanyakan dari mereka sangat banyak sehingga halaman tidak dapat membuat tanpa setidaknya satu panggilan. Jelas Anda tidak ingin mengekspos database Anda secara publik, karena beberapa alasan:

  • Keamanan (seperti yang disebutkan Oded ) - Anda pasti tidak ingin mengekspos jaringan Anda secara publik! Idealnya satu-satunya antarmuka ke sistem Anda dari luar harus https ke server Anda.
  • Kemudahan pengembangan - Anda benar- benar , benar - benar tidak ingin menulis SQL dalam Javascript, dan bahasa yang dirancang untuk presentasi web tidak bekerja dengan baik dengan RDB. Mereka tidak memiliki konsep negara, misalnya.

Jadi, ketika Anda membutuhkan database, Anda menggunakan bahasa yang cocok dengan mereka seperti Java, C #, PHP, dll. Cara termudah untuk menghasilkan halaman ternyata adalah sebagai berikut: Anda menggunakan bahasa templating (paling terkenal PHP, tetapi JSP dan ASP adalah dua bahasa lain yang sangat umum) untuk membangun halaman. Bahasa ini menyediakan konstruksi yang memanggil ke modul lain. Dalam PHP ini biasanya di halaman atau dalam file PHP lain, menggunakan pola MVC. Di JSP Anda menggunakan scriptlets atau Bahasa Ekspresi JSP. Modul-modul lain ini dapat bekerja keras untuk menyambung ke DB, melakukan logika, dan mengembalikan nilai ke lapisan tampilan Anda. Hasil akhirnya adalah halaman HTML yang dihasilkan, diberikan di server dan dikirim ke klien.

Ketika database Anda berada di jaringan yang sama dengan renderer halaman Anda, Anda juga mendapatkan kinerja yang lebih baik. Klien hanya perlu melakukan satu permintaan dan menerima halaman - Anda mungkin perlu melakukan 10-15 permintaan DB sebelum Anda memiliki semua informasi yang dibutuhkan pengguna. Latensi milidetik di jaringan Anda akan menjadi detik hingga menit jika klien harus melakukan semuanya.

Ketika sistem tumbuh lebih besar, pemisahan masalah dan kompetensi inti menjadi sangat penting. HTML bagus untuk tampilan. Javascript bagus untuk konten dinamis. SQL sangat bagus untuk menanyakan basis data, dan bahasa lainnya bagus dalam logika bisnis. Tugas kita sebagai pengembang adalah menggunakan semua alat yang tersedia untuk membangun sistem yang dapat dipelihara. Kemudahan pengembangan adalah bagian besar dari sistem yang baik. Dalam pikiran saya, ini hampir sama pentingnya dengan kinerja dan kegunaan. Sistem hebat berkembang seiring waktu. Sistem yang buruk ditulis dengan buruk sejak awal dan tidak pernah diperbaiki.

— Michael K.
sumber
you can't write SQL in Javascript Betulkah?! Pernahkah Anda melihat pertanyaan StackOverflow untuk Javascript? Sayangnya saya mohon untuk berbeda. Memang itu adalah hal terburuk yang dapat Anda lakukan dalam kode klien tetapi ...
— maple_shaft
... juga saya lupa tentang Node.JS, tapi kemudian server JS yang merupakan hewan yang sama sekali berbeda.
— maple_shaft
Tampaknya Anda bisa - TIL! Tapi ... wow. Namun, bicarakan penyalahgunaan bahasa!
— Michael K
2
Antarmuka REST adalah cara klien saat ini mengakses data database melalui objek json. Itu tidak memaparkan segalanya dan aplikasi ini adalah bagian dari jaringan perusahaan swasta. Salah satu keunggulan antarmuka adalah kemampuan aplikasi lain dalam perusahaan untuk memanfaatkan layanan apa pun yang mereka inginkan. Dari perspektif pengembangan, saya dapat membiarkan pengembang front-end melakukan apa yang mereka inginkan dalam html / js / css dan kemudian mereka bisa melakukan ping dari antarmuka RESTful yang dirancang oleh pengembang java. Namun, kebanyakan dari kita memiliki seperangkat keterampilan campuran dan pembagian itu mungkin tidak diperlukan.
— user1303881
3
-1: @MichaelK: Anda sedang berdiskusi dengan seorang pria bodoh yang Anda bayangkan, tetapi sama sekali tidak ada hubungannya dengan kehidupan nyata. RESTful tidak menggunakan HTTP. Tidak ada yang perlu menulis SQL di JS, untuk itulah antarmuka yang tenang. Juga RESTful tidak berarti, ada pemetaan 1-ke-1 dengan permintaan DB. Jawaban Anda mungkin valid pada 1990-an, tetapi kami pada 2012 sekarang.
— vartec
0

Klien seluler biasanya dibatasi oleh daya, bandwidth, dan memori. Mungkin lebih baik membuat halaman untuk mereka di server.

Untuk klien desktop, Anda dapat mempertimbangkan mengirim js + json untuk merender halaman pada klien, menjadikannya dapat diperbarui secara dinamis, dll.

— 9000
sumber
Namun dalam praktiknya, kebalikannya sering kali benar. Proyek Mobile jQuery, pada kenyataannya, sepenuhnya didasarkan pada ide rendering sisi klien.
— Runcing
@Pointy: ya, ini bisa menjadi sebaliknya. Orang harus menguji bagaimana halaman tertentu berperilaku pada klien tertentu. Memberikan tautan ke alternatif (seperti tautan versi 'seluler' dan 'desktop') juga dapat bermanfaat bagi pengguna.
— 9000
Mobile saat ini lebih banyak ditandai oleh latensi tinggi daripada bandwidth rendah atau daya pemrosesan. Dalam proyek yang saya kerjakan baru-baru ini, kami lebih mementingkan ukuran halaman daripada kecepatan rendering - ponsel modern cukup bagus.
— Michael K
@Pointy proyek jQuery Mobile juga merupakan tumpukan besar kode mengerikan yang tidak boleh digunakan. Popularitas! == nilai
— Raynos
@ Raynos Kami sebenarnya menggunakan Jquery Mobile, dengan kesuksesan yang cukup bagus juga. Apakah Anda tahu sesuatu yang tidak kami ketahui? ;)
— Michael K
0

Satu keuntungan besar dari rendering sisi server adalah aksesibilitas - aplikasi berbasis javascript masih menjadi masalah besar bagi orang-orang yang tidak memiliki penglihatan. Itu dan ada orang buta ini bernama "googlebot" yang mungkin ingin Anda penuhi. Dia juga tidak melakukan javascript dengan baik.

— Wyatt Barnett
sumber
Poin bagusnya, walaupun aplikasi ini tidak memerlukan SEO karena sifatnya pribadi, saya juga mengembangkan beberapa aplikasi pribadi dan itu adalah pertimbangan di arena itu.
— user1303881
Googlebot menafsirkan JS / AJAX selama beberapa waktu: searchenginewatch.com/article/2122137/…
— vartec
@ vartec: Saya pikir kalimat kunci dalam artikel itu adalah "sekarang dapat membaca dan memahami komentar dinamis tertentu yang diterapkan melalui AJAX dan JavaScript." Dugaan saya adalah ini mencakup disqus dan facebook tetapi bukan pengaturan ajax khusus Anda.
— Wyatt Barnett
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.