Di tempat kerja, kami memiliki aplikasi internal besar yang telah dalam pengembangan selama hampir 2 tahun sekarang; Saya baru saja bergabung dengan proyek ini dan beberapa arsitekturnya membuat saya sedikit bingung, jadi saya berharap seseorang di sini dapat memberikan beberapa saran sebelum saya keluar untuk menanyakan kepada arsitek pertanyaan-pertanyaan yang sama (sehingga saya dapat berdiskusi dengan mereka tentang hal itu) ).
Saya minta maaf jika di bawah ini agak panjang, saya hanya ingin mencoba melukis gambar yang bagus tentang apa sistemnya sebelum saya mengajukan pertanyaan saya :)
Cara pengaturan sistem adalah bahwa kami memiliki satu aplikasi web utama (asp.net, AngularJS) yang sebagian besar hanya mengumpulkan data dari berbagai layanan lainnya. Jadi pada dasarnya itu adalah host untuk aplikasi AngularJS; secara harfiah ada satu pengontrol MVC yang mem-bootstrap sisi klien, dan kemudian setiap pengontrol lainnya adalah pengontrol WebAPI.
Panggilan dari sisi klien ditangani oleh pengontrol ini, yang selalu dikerahkan ke kotak yang tidak melakukan apa pun selain meng-host Aplikasi Web. Saat ini kami memiliki 4 kotak seperti itu.
Namun, panggilan tersebut pada akhirnya dialihkan ke set aplikasi WebAPI yang lain (biasanya ini adalah per area bisnis, seperti keamanan, data pelanggan, data produk, dll). Semua WebAPI ini bisa digunakan bersama-sama ke kotak khusus; kami juga memiliki 4 kotak ini.
Dengan satu pengecualian, WebAPI ini tidak digunakan oleh bagian lain dari organisasi kami.
Akhirnya WebAPI ini membuat satu set panggilan ke layanan "back end", yang biasanya merupakan layanan asmx atau wcf lama yang ditampar di atas berbagai sistem ERP dan penyimpanan data (di mana kami tidak memiliki kendali).
Sebagian besar logika bisnis aplikasi kami ada di WebApis ini, seperti mengubah data lawas, menggabungkannya, menjalankan aturan bisnis, jenis hal yang biasa.
Apa yang membuat saya bingung adalah apa manfaat yang mungkin ada dalam memiliki pemisahan antara Aplikasi Web dan WebAPI yang melayani itu. Karena tidak ada orang lain yang menggunakannya, saya tidak melihat manfaat skalabilitas (yaitu tidak ada gunanya memasukkan 4 kotak API lain untuk menangani peningkatan beban, karena peningkatan beban pada server API harus berarti ada peningkatan beban di server Web - oleh karena itu harus ada perbandingan 1: 1 dari server Web ke server Api)
Saya juga tidak melihat manfaat sama sekali dari harus membuat panggilan HTTP tambahan Browser => HTTP => WebApp => HTTP => WebAPI => HTTP => Layanan backend. (panggilan HTTP antara WebApp dan WebAPI adalah masalah saya)
Jadi saya saat ini ingin mendorong agar WebAPI saat ini pindah dari solusi terpisah, ke hanya proyek terpisah dalam solusi WebApplication, dengan referensi proyek sederhana di antaranya, dan model penyebaran tunggal. Jadi mereka pada akhirnya hanya akan menjadi perpustakaan kelas.
Dari segi penyebaran, ini berarti kami akan memiliki 8 kotak web "tumpukan penuh", berbeda dengan 4 + 4.
Manfaat yang saya lihat dari pendekatan baru adalah
- Peningkatan kinerja karena ada satu siklus serialisasi / deserialisasi yang kurang antara aplikasi Web dan server WebAPI
- Banyak kode yang dapat dihapus (yaitu tidak perlu dipelihara / diuji) dalam hal DTO dan pemetaan di batas keluar dan masuk Aplikasi Web dan server WebApi masing-masing.
- Kemampuan yang lebih baik untuk membuat Tes Integrasi otomatis yang bermakna, karena saya dapat dengan mudah mengejek layanan back-end dan menghindari kekacauan di sekitar lompatan HTTP tingkat menengah.
Jadi pertanyaannya adalah: apakah saya salah? Apakah saya melewatkan beberapa "keajaiban" mendasar karena memisahkan kotak WebApplication dan WebAPI?
Saya telah meneliti beberapa bahan arsitektur N-Tier tetapi tampaknya tidak dapat menemukan apa pun di dalamnya yang dapat memberikan manfaat nyata bagi situasi kita (karena skalabilitas tidak menjadi masalah sejauh yang saya tahu, dan ini adalah aplikasi internal sehingga keamanan dalam hal aplikasi WebAPI tidak menjadi masalah.)
Dan juga, apa yang akan saya kehilangan dalam hal manfaat jika saya mengatur ulang sistem ke pengaturan yang saya usulkan?
sumber
Jawaban:
Salah satu alasannya adalah keamanan - jika (haha! Kapan ) seorang hacker mendapatkan akses ke server web front-end Anda, ia mendapatkan akses ke semua yang dimilikinya. Jika Anda telah menempatkan tingkat menengah Anda di server web, maka dia memiliki akses ke semua yang dimilikinya - yaitu DB Anda, dan selanjutnya Anda tahu, dia hanya menjalankan "pilih * dari pengguna" pada DB Anda dan membawanya dari offline pemecahan kata sandi.
Alasan lain adalah penskalaan - tingkat web tempat laman dibuat dan dirusak serta XML diproses dan semua itu membutuhkan lebih banyak sumber daya daripada tingkat menengah yang seringkali merupakan metode yang efisien untuk mendapatkan data dari DB ke tingkat web. Belum lagi mentransfer semua data statis yang berada (atau di-cache) di server web. Menambahkan lebih banyak server web adalah tugas sederhana setelah Anda melewati 1. Tidak boleh ada rasio 1: 1 antara web dan tingkatan logika - Saya telah melihat 8: 1 sebelumnya sekarang (dan rasio 4: 1 antara logika tingkat dan DB). Itu tergantung apa yang dilakukan tingkatan Anda dan berapa banyak caching terjadi di dalamnya.
Situs web tidak terlalu peduli dengan kinerja pengguna-tunggal karena mereka dibuat untuk mengukur, tidak masalah bahwa ada panggilan tambahan yang memperlambat sedikit jika itu berarti Anda dapat melayani lebih banyak pengguna.
Alasan lain adalah baik untuk memiliki lapisan-lapisan ini karena memaksa lebih banyak disiplin dalam pengembangan di mana API dikembangkan (dan mudah diuji karena mandiri) dan kemudian UI dikembangkan untuk mengkonsumsinya. Saya bekerja di tempat yang melakukan ini - tim yang berbeda mengembangkan lapisan yang berbeda dan itu bekerja dengan baik karena mereka memiliki spesialis untuk setiap tingkatan yang dapat mengubah perubahan dengan sangat cepat karena mereka tidak perlu khawatir tentang tingkatan lainnya - yaitu javscript UI UI dapat menambahkan bagian baru ke situs hanya dengan mengonsumsi layanan web baru yang dikembangkan orang lain.
sumber
Saya pikir tidak ada jawaban benar / salah di sini. Sudahkah Anda bertanya kepada kolega Anda tentang tujuan arsitektur ini?
Dari cara saya memahami deskripsi Anda, " WebAPI " dalam Arsitektur Anda berfungsi sebagai jenis Middleware buatan sendiri. Sekarang Anda dapat meneliti keuntungan apa yang ada dalam penggunaan Middleware. Pada dasarnya Webapp Anda tidak perlu diadopsi jika Anda mengubah sistem backoffice Anda (selama antarmuka WebAPI tetap sama).
Untuk melangkah lebih jauh: Bayangkan Anda memiliki basis data pelanggan (layanan backend) dan Anda memiliki 5 aplikasi web yang berkomunikasi dengan basis data itu. Jika Anda mengganti sistem basis data pelanggan dengan sistem baru (seperti dari vendor lain dan Anda tidak dapat memengaruhi antarmuka layanan web), kemungkinan besar Anda perlu mengubah lapisan komunikasi dari semua 5 aplikasi web. Jika Anda berkomunikasi melalui WebAPI Anda, Anda hanya perlu mengubah lapisan komunikasi WebAPI .
Pada dasarnya, Arsitektur Layer saat ini dianggap sebagai: Pola dan Anti-Pola. (Lihat: Lasagna-Code ) Jika Anda hanya memiliki 1 sistem tanpa rencana untuk memperluas ini lebih lanjut dalam beberapa tahun ke depan saya lebih suka menganggap ini sebagai anti-pola. Tapi ini akan menjadi hakim yang tidak realistis karena saya tidak tahu keadaan / situasi yang sebenarnya :)
sumber