Peringatan: pos besar, beberapa pendapat, tidak jelas kesimpulan 'lakukan yang terbaik untuk Anda'
Secara umum, ini dilakukan sebagai sarana untuk mengimplementasikan 'arsitektur heksagonal' di sekitar basis data Anda. Anda dapat memiliki aplikasi web, aplikasi seluler, aplikasi desktop, importir massal, dan pemrosesan latar belakang semua menggunakan database Anda dengan cara yang seragam. Tentu saja Anda dapat mencapai hal yang sama sampai batas tertentu dengan menulis perpustakaan yang kaya untuk mengakses database Anda, dan meminta semua proses Anda menggunakan perpustakaan itu. Dan memang, jika Anda berada di sebuah toko kecil dengan sistem yang sangat sederhana, itu sebenarnya mungkin rute yang lebih baik untuk ditempuh; Ini adalah pendekatan yang lebih sederhana dan jika Anda tidak membutuhkan kemampuan canggih dari sistem yang lebih rumit, mengapa harus membayar kompleksitasnya? Namun, jika Anda bekerja dengan satu set besar, sistem canggih yang semuanya perlu berinteraksi dengan basis data Anda dalam skala besar, ada
Kemandirian & pemeliharaan platform
Jika Anda memiliki database, dan Anda menulis perpustakaan Python untuk berinteraksi dengan database itu, dan semua orang menarik di perpustakaan itu untuk berinteraksi dengan database, itu hebat. Tapi katakanlah tiba-tiba Anda perlu menulis aplikasi seluler, dan aplikasi seluler itu sekarang perlu berbicara dengan basis data. Dan insinyur iOS Anda tidak menggunakan Python, dan insinyur Android Anda tidak menggunakan Python. Mungkin orang-orang iOS ingin menggunakan bahasa Apple dan para insinyur Android ingin menggunakan Java. Maka Anda akan terjebak menulis dan memelihara perpustakaan akses data Anda dalam 3 bahasa yang berbeda. Mungkin iOS dan Android devs memutuskan untuk menggunakan sesuatu seperti Xamarin untuk memaksimalkan kode yang dapat mereka bagikan. Sempurna, kecuali Anda mungkin masih harus mem-port pustaka akses data Anda ke .NET. Dan kemudian perusahaan Anda baru saja membeli perusahaan lain yang Aplikasi web adalah produk yang berbeda tetapi terkait, dan bisnis ingin mengintegrasikan beberapa data dari platform perusahaan Anda ke dalam platform anak perusahaan yang baru diakuisisi. Hanya ada satu masalah: Anak perusahaan adalah perusahaan baru dan memutuskan untuk menulis sebagian besar aplikasi mereka di Dart. Plus, untuk alasan apa pun (alasan mungkin di luar kendali Anda) tim seluler yang mengemudikan Xamarin memutuskan itu bukan untuk mereka, dan bahwa mereka lebih suka menggunakan alat dan bahasa khusus untuk perangkat seluler yang akan mereka kembangkan. Tetapi ketika Anda berada dalam fase itu, tim Anda sudah mengirimkan sebagian besar pustaka akses data Anda di .NET, dan tim lain di perusahaan itu sedang menulis beberapa hal integrasi Salesforce yang gila dan memutuskan untuk melakukan semua itu di .NET karena ada sudah menjadi perpustakaan akses data untuk.
Jadi sekarang, karena pergantian peristiwa yang sangat realistis, Anda memiliki pustaka akses data Anda yang ditulis dalam Python, .NET, Swift, Java, dan Dart. Mereka juga tidak sebaik yang Anda inginkan. Anda tidak dapat menggunakan ORM seefektif yang Anda inginkan, karena setiap bahasa memiliki alat ORM yang berbeda, jadi Anda harus menulis lebih banyak kode daripada yang Anda inginkan. Dan Anda belum dapat mencurahkan banyak waktu untuk setiap inkarnasi seperti yang Anda inginkan, karena ada 5 dari mereka. Dan versi Dart perpustakaan sangat berbulu karena Anda harus menggulung sendiri barang-barang transaksional Anda untuk sebagian karena perpustakaan dan dukungan tidak benar-benar ada. Anda mencoba menjelaskan bahwa karena hal ini, aplikasi Dart seharusnya hanya memiliki fungsi baca-saja untuk basis data Anda, tetapi bisnis itu telah memutuskan bahwa fitur apa pun yang mereka rencanakan pantas dilakukan. Dan ternyata ada bug dalam beberapa logika validasi yang ada di semua inkarnasi pustaka akses data Anda ini. Sekarang Anda harus menulis tes dan kode untuk memperbaiki bug ini di semua pustaka ini, dapatkan ulasan kode untuk perubahan Anda ke semua pustaka ini, dapatkan QA pada semua pustaka ini, dan lepaskan perubahan Anda ke semua sistem menggunakan semua perpustakaan ini. Sementara itu, pelanggan Anda tidak senang dan telah dibawa ke Twitter, merangkai kombinasi vulgar yang tidak pernah Anda bayangkan bisa dipahami, apalagi ditargetkan pada produk andalan perusahaan Anda. Dan pemilik produk memutuskan untuk tidak memahami situasi sama sekali.
Harap dipahami bahwa di beberapa lingkungan, contoh di atas tidak ada yang dibuat. Juga pertimbangkan bahwa urutan peristiwa ini dapat berlangsung selama beberapa tahun. Secara umum, ketika Anda sampai pada titik di mana arsitek dan pebisnis mulai berbicara tentang menghubungkan sistem lain ke database Anda, saat itulah Anda akan ingin mendapatkan 'menempatkan REST API di depan database' ke peta jalan Anda. Pertimbangkan jika sejak awal, ketika sudah jelas bahwa database ini akan mulai dibagikan oleh beberapa sistem, bahwa layanan web / REST API diletakkan di depannya. Memperbaiki bug validasi Anda akan jauh lebih cepat dan mudah karena Anda melakukannya sekali, bukan 5 kali. Dan melepaskan perbaikannya akan jauh lebih mudah untuk dikoordinasikan, karena Anda
TLDR; Lebih mudah untuk memusatkan logika akses data dan mempertahankan klien HTTP yang sangat tipis daripada mendistribusikan logika akses data ke setiap aplikasi yang perlu mengakses data. Bahkan, klien HTTP Anda bahkan dapat dihasilkan dari meta-data. Dalam sistem besar, REST API memungkinkan Anda mempertahankan lebih sedikit kode
Performa dan skalabilitas
Beberapa orang mungkin percaya bahwa berbicara dengan basis data secara langsung alih-alih melalui layanan web lebih cepat. Jika Anda hanya memiliki satu aplikasi, itu tentu benar. Tetapi dalam sistem yang lebih besar, saya tidak setuju dengan sentimen. Pada akhirnya, pada tingkat tertentu, akan sangat bermanfaat jika menaruh semacam cache di depan basis data. Mungkin Anda menggunakan Hibernate, dan ingin menginstal kisi Infinispan sebagai cache L2. Jika Anda memiliki sekelompok 4 server gemuk untuk meng-host layanan web Anda terpisah dari aplikasi Anda, Anda dapat memiliki topologi tertanam dengan replikasi sinkron dihidupkan. Jika Anda mencoba meletakkannya di 30 server aplikasi, overhead untuk mengaktifkan replikasi dalam pengaturan itu akan terlalu banyak, jadi Anda harus Anda harus menjalankan Infinispan dalam mode terdistribusi atau dalam beberapa jenis topologi khusus, dan tiba-tiba Hibernate harus keluar melalui jaringan untuk membaca dari cache. Plus, Infinispan hanya berfungsi di Jawa. Jika Anda memiliki bahasa lain, Anda membutuhkan solusi caching lainnya. Overhead jaringan karena harus pergi dari aplikasi Anda ke layanan web Anda sebelum mencapai database dengan cepat diimbangi dengan kebutuhan untuk menggunakan solusi caching yang jauh lebih rumit yang umumnya datang dengan overhead mereka sendiri.
Selain itu, lapisan HTTP API REST Anda menyediakan mekanisme caching lain yang berharga. Server Anda untuk REST API Anda dapat menempatkan header caching pada respons mereka, dan respons ini dapat di-cache di lapisan jaringan, yang skalanya sangat baik. Dalam pengaturan kecil, dengan satu atau dua server, taruhan terbaik Anda adalah dengan hanya menggunakan cache memori dalam aplikasi ketika berbicara ke database, tetapi dalam platform besar dengan banyak aplikasi yang berjalan di banyak server, Anda ingin memanfaatkan jaringan untuk menangani caching Anda, karena ketika dikonfigurasi dengan benar sesuatu seperti squid atau pernis atau nginx dapat keluar ke tingkat gila pada perangkat keras yang relatif kecil. Ratusan ribu atau jutaan permintaan per detik dari throughput jauh lebih murah untuk dilakukan dari cache HTTP daripada dari server aplikasi atau database.
Selain itu, memiliki banyak klien yang menunjuk ke basis data Anda, alih-alih mengarahkan semua ke beberapa server yang pada gilirannya menunjuk ke basis data, dapat membuat penyetelan basis data dan koneksi menyatukan lebih sulit. Secara umum, sebagian besar beban kerja aktual pada server aplikasi adalah hal-hal aplikasi; menunggu data untuk kembali dari database seringkali memakan waktu, tetapi umumnya tidak terlalu mahal secara komputasi. Anda mungkin memerlukan 40 server untuk menangani beban kerja aplikasi Anda, tetapi Anda mungkin tidak perlu 40 server untuk mengatur pengambilan data dari database. Jika Anda mendedikasikan tugas itu untuk layanan web, layanan web mungkin akan berjalan pada server yang jauh lebih sedikit daripada aplikasi lainnya, yang berarti Anda akan memerlukan koneksi jauh lebih sedikit ke database. Yang penting, karena basis data umumnya tidak
TLDR; Lebih mudah untuk mengatur, mengukur, dan menyimpan akses data Anda ketika itu adalah sesuatu yang terjadi di dalam satu layanan web khusus daripada ketika itu adalah sesuatu yang terjadi di banyak aplikasi yang berbeda menggunakan berbagai bahasa dan teknologi
Pikiran terakhir
Tolong jangan menyimpang dari pemikiran ini "Oh wow, saya harus selalu menggunakan REST API untuk mendapatkan data saya" atau "Idiot ini mencoba mengatakan kami melakukan kesalahan karena aplikasi web kami berbicara langsung ke database, tetapi barang-barang kami bekerja dengan baik! " . Poin utama yang saya coba sampaikan adalah bahwa sistem dan bisnis yang berbeda memiliki persyaratan yang berbeda; Dalam banyak kasus, menempatkan REST API di depan basis data Anda benar-benar tidak masuk akal. Ini adalah arsitektur yang lebih rumit yang membutuhkan pembenaran kompleksitas itu. Tetapi ketika kompleksitas dibenarkan, ada banyak manfaat untuk memiliki REST API. Mampu menimbang masalah yang berbeda dan memilih pendekatan yang tepat untuk sistem Anda adalah apa yang membuat seorang insinyur yang baik.
Selain itu, jika REST API menghalangi debugging sesuatu, kemungkinan ada sesuatu yang salah atau hilang dalam gambar itu. Saya tidak percaya memiliki lapisan abstraksi yang ditambahkan secara intrinsik membuat debugging lebih sulit. Ketika saya bekerja dengan sistem n-tier yang besar, saya ingin memastikan bahwa saya memiliki konteks logging terdistribusi. Mungkin ketika pengguna memulai permintaan, buat GUID untuk permintaan itu dan catat nama pengguna pengguna itu dan permintaan yang mereka buat. Kemudian, operasikan GUID itu saat aplikasi Anda berbicara ke sistem lain. Dengan agregasi dan pengindeksan log yang tepat, Anda dapat meminta seluruh platform Anda untuk pengguna melaporkan masalah, dan memiliki visibilitas ke semua tindakan mereka dan mereka menetes melalui sistem untuk dengan cepat mengidentifikasi di mana terjadi kesalahan. Sekali lagi, ini adalah arsitektur yang lebih rumit,
Sumber:
http://alistair.cockburn.us/Hexagonal+architecture
https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing