it-swarm-id.com

Keuntungan / kerugian dari aplikasi web "terpisah"

Saya sedang dalam proses mendesain aplikasi web PHP/MySQL yang agak besar. Saya telah sampai di persimpangan jalan sejauh arsitektur internal; Saya dapat membangun situs web sebagai aplikasi web "tradisional" di mana, ketika Anda membuat permintaan, server membuat Anda sebuah halaman HTML, mengirimkan Anda seluruh halaman, dan browser merendernya, atau, saya dapat membangunnya sebagai "terpisah" "aplikasi web di mana seluruh struktur HTML dan kode aplikasi disediakan untuk browser saat memuat awal, dan aplikasi menggunakan JavaScript callback untuk mendapatkan data spesifik atau mengeluarkan perintah melalui API terpadu. Juga, saya bermaksud ada beberapa versi situs (desktop, ponsel, iPhone/Android mobile, mesin pencari ramah, dll.) Dan di beberapa titik, mungkin bahkan aplikasi mobile atau desktop mandiri juga.

Apa keuntungan/kerugian yang Anda miliki, sebagai pengembang web, hadapi dengan masing-masing arsitektur ini? Adakah alasan yang jelas mengapa saya harus pergi dengan yang lain? Apakah ini lebih merupakan hal yang disukai pengembang?

3
Adam Maras

Pertama, apakah Anda menggunakan situs web Asynchronous yang berat atau tidak tidak akan banyak mempengaruhi kemampuan Anda untuk membangun aplikasi iPhone/Mobile dan desktop karena tidak ada hubungannya dengan mereka. Bagaimanapun, Anda tidak akan dapat menggunakan kembali kode Anda.

Juga, situs Asynchronous bisa sama lambat atau lebih lambat dari situs normal. Biasanya, fungsi semacam itu ditambahkan karena suatu alasan, khususnya untuk pengalaman pengguna yang diperkaya. Menggunakan JavaScript cenderung menyakiti Anda dalam SEO karena webcrawlers tidak dapat sepenuhnya memahami maksud dari JavaScript dan mengabaikannya.

Saya pikir apa yang Anda cari adalah cara untuk mengurangi overhead pengembangan Anda dengan hanya menulis tingkat fungsional (menengah) Anda sekali dan menggunakan yang sama untuk semua aplikasi Anda. Dalam hal ini saya pikir ada nilai tetapi terus terang jenis arsitektur ini lebih sulit untuk diatur dan membutuhkan banyak waktu. Saya berpendapat bahwa Anda harus mengembangkan situs web Anda sebaik mungkin dan menjaga kode tingkat menengah Anda sekuat yang Anda bisa. Dengan begitu ketika tiba saatnya untuk menambahkan aplikasi iPhone atau apa pun yang Anda dapat pindah ke model dengan tingkat menengah umum lebih mudah

Apa yang sebenarnya saya anjurkan di sini adalah mengambil langkah kecil. Jangan mencoba menulis kode sekarang untuk menangani hal-hal yang belum Anda ketahui. Cukup tulis kode yang Anda butuhkan dan buat sefleksibel mungkin.

4
Ben Hoffman

Saya pikir ide aplikasi "terpisah" yang sangat bergantung pada JavaScript/AJAX akan membawa Anda ke banyak masalah. Beberapa hal dari kepala saya:

  1. Ini akan buruk untuk SEO karena Google akan kesulitan mengindeks apa pun.
  2. Ini akan sulit untuk membuatnya "dapat di-bookmark"
  3. Anda akan mengalami kesulitan dengan perangkat seluler karena banyak dari mereka memiliki dukungan javascript yang sangat terbatas (atau rusak).
5
Eric Petroelje

Pertama, jangan tersinggung jika jawaban ini terlalu jelas atau mendasar. Penggunaan Anda "terpisah" alih-alih istilah seperti Ajax atau jQuery membuat saya menganggap kurang pengalaman dengan topik ini. Tentu saja saya bisa salah membaca pertanyaan, jadi saya minta maaf jika itu masalahnya.

Gunakan keduanya, tetapi dengan bijak

Pikirkan pilihan tugas sisi server atau sisi klien Anda dalam hal di mana dan bagaimana tugas dilakukan dengan paling efisien. Ini akan membantu Anda merender halaman dengan cepat (di server), tetapi membongkar berfungsi untuk browser yang masuk akal untuk melakukannya. Dan, akan ada area abu-abu di mana Anda hanya perlu membuat panggilan penilaian. Tugas Anda adalah menemukan pembagian kerja yang cerdas.

Apa yang termasuk sisi server?

(Ini adalah contoh ekstrem untuk mengilustrasikan poin.) Katakanlah Anda sedang menulis aplikasi web yang melakukan beberapa jenis pencarian. Anda tidak menulis Javascript sisi-peramban untuk memanggil layanan web sisi-server PHP untuk mengambil seluruh basis data 2GB untuk "membebaskan server Anda" dan membongkar pencarian ke mesin pengguna. Apa yang Anda lakukan adalah mendapatkan istilah pencarian dari pengguna dengan formulir, POST kembali ke server untuk menanyakan database secara langsung, kemudian mengirim hasilnya kembali dari server ke browser.

Logikanya di sini adalah bahwa DB sendiri tahu cara terbaik melakukan kueri, server lebih dekat ke sumber data, dan lebih sedikit data yang harus dipindahkan di antara komponen. Browser hanya membutuhkan apa yang ditampilkannya, jadi jangan kirim semuanya ke browser. (Belum lagi kinerja bahasa relatif.)

Apa yang ada di browser?

Kode sisi browser adalah skenario "dipisahkan" Anda (jika saya mengerti dengan benar). Tetapi agar browser dapat melakukan sebagian besar hal yang cerdas, ia harus memiliki kerja sama server.

Oke, aplikasi pencarian Anda berfungsi, tetapi Anda ingin merapikannya dengan beberapa celana mewah Ajax. Tulis layanan web PHP untuk mengambil beberapa huruf dan mengembalikan istilah pencarian yang cocok, a la fitur "search suggest" dari Bing , Google, dll. Tulis kode browser Anda hanya untuk menyarankan istilah setelah pengguna mengetik tiga atau empat huruf, sehingga daftar saran Anda kecil. Kembali ke server, indeks database Anda pada bidang itu sehingga pencarian cepat cepat cepat.

Di sini pemikirannya adalah bahwa "saran pencarian" adalah fitur yang harus dibagi antara server dan klien. Peramban dapat dengan cepat menangani tumpukan data kecil yang ditargetkan. Server dapat memperoleh tumpukan data kecil yang ditargetkan dan memberikannya kepada klien. Pembagian yang buruk akan membuat server membuat daftar monster (katakanlah, 500.000 item) dari nilai bidang yang mungkin sebagai pulau XML yang disematkan di halaman HTML, kemudian minta pencarian di browser itu sebagai tipe pengguna. (a) mengirim semua data ke browser lambat, (b) mencarinya di Javascript akan tidak pernah secepat membiarkan DB mencarinya, dan (c) Anda cenderung meledakkan mesin pengguna dengan menjejalkan semua data itu ke ruang aplikasi browser mereka. Di sisi lain, Anda perlu memastikan yakin bahwa panggilan Ajax ke server, dan permintaan dan pengembalian berikutnya super cepat. Tidak berlengah-lengah di sekitar.

Di mana area abu-abu?

Sekali lagi ini adalah panggilan penilaian. Di atas, saya berbicara tentang server melakukan pencarian, lalu mengirimkan hasilnya ke browser. Tetapi, muncul pertanyaan, apakah Anda membiarkan browser mengirimkan istilah pencarian dengan formulir dan meminta server membuat halaman hasil, atau apakah Anda menggunakan Ajax/Javascript sisi klien untuk mengirim istilah pencarian dan mengambil hasilnya, lalu merendernya dalam DIV untuk menghindari penyegaran halaman? Keduanya valid. Dari sisi sumber daya, tidak ada manfaat nyata. Cara Ajax dapat memberikan pengalaman pengguna yang lebih baik tetapi, tergantung pada aplikasi Anda dan keadaannya, mungkin menghadirkan beberapa tantangan lain (mis. Keamanan).

Intinya

Gunakan keduanya dengan tepat. Jangan berhemat dalam berpikir dan belajar tentang kinerja dan efisiensi arsitektur. Pindahkan lebih sedikit data, lebih sedikit kali. Anda akan mengambil beban dari server Anda, database Anda, dan browser pengguna Anda.

2
b w

Agar dapat menggunakan kembali kode Anda selalu dapat melihat XSLT untuk pembuatan halaman arahan dan kemudian memiliki antarmuka XML/JSON untuk AJAX (menggunakan antarmuka XML untuk halaman arahan XSLT).

Anda biasanya membiarkan konten dan interaksi berfungsi pada antarmuka RESTful dengan awalan/json/... dan/xml/... dan Host konten utama Anda, dikonversi menjadi mark-up melalui XSLT pada/...

Dengan cara ini orang dapat mendarat di halaman mana saja dan tiba-tiba memiliki situs web AJAXyang penuh sesak nafas. Laba-laba dapat merayapi situs Anda dan Anda telah berkonsentrasi pada konten/antarmuka pertama dan terutama - sepertinya menang/menang.

Situs web seluler kadang-kadang memerlukan tata letak yang berbeda (hanya ada situs khusus iPhone?) Konversi XSLT sederhana di sini atau di sana untuk klien pengguna yang berbeda dapat menggunakan kembali semua yang telah Anda lakukan sejauh ini.

Ingatlah untuk merancang output dan navigasi HTML sederhana, penyederhanaan AJAX dapat mengikuti.

PS - Lakukan transformasi sisi server XSLT

1
Metalshark