Apa yang lebih cepat? Menggunakan REST API atau menanyakan database secara langsung?

16

Apa yang dimaksud dengan kinerja lebih cepat? Membuat REST API dan meminta aplikasi web Anda menggunakan REST API untuk melakukan semua interaksi dengan database Anda ATAU menanyakan database Anda secara langsung (yaitu menggunakan objek khas apa pun yang digunakan bahasa Anda untuk melakukan query pada database seperti JDBC untuk Java)?

Cara saya melihatnya dengan REST:

Anda membuat objek dalam kode Anda untuk memanggil metode REST
Panggil metode http
Kode di dalam REST API Anda menanyakan basis data
Database mengembalikan beberapa data
Kode API REST mengemas data ke Json dan mengirimkannya ke klien Anda
Klien menerima respons Json / XML
Respons peta terhadap objek dalam kode Anda

Di sisi lain, menanyakan database secara langsung:

Anda membuat objek dengan string kueri untuk query database
Database mengembalikan beberapa data
Respons peta terhadap objek dalam kode Anda

Jadi bukankah ini berarti menggunakan REST API akan lebih lambat? Mungkin itu tergantung pada jenis database (SQL vs NoSQL)?

database rest sql

— Mikro
sumber

3

API REST bukan protokol akses database, jadi pertanyaannya adalah kesalahan kategori besar. Api ISTIRAHAT adalah toko dokumen. BISA menggunakan database di sisi server (atau mungkin tidak). Jika Anda tidak membutuhkan REST API maka jelas tidak menggunakannya. Tapi itu berlaku untuk semuanya. Jika Anda tidak memerlukan database, jangan gunakan database, menulis ke sistem file akan lebih cepat daripada database. Jika Anda tidak memerlukan sistem file tidak menggunakannya, menulis ke RAM lebih cepat daripada disk. Jika Anda tidak membutuhkan RAM, jangan gunakan itu, menulis ke cache CPU lebih cepat dll dll

— Cormac Mulhall

1

"Di sisi lain" mengharuskan Anda untuk mengekspos database Anda ke dunia buruk besar.

— Pieter B

@PieterB: Tidak, "di sisi lain" mengekspos database ke aplikasi web yang tepercaya.

— JacquesB

@ JacquesB dan aplikasi web berjalan di komputer klien. Jadi itu tidak boleh dipercaya karena itu bisa menjadi versi yang dimodifikasi.

— Pieter B

@PieterB: Pertanyaannya tidak menyatakan apa pun tentang aplikasi web yang berjalan di server yang tidak terpercaya. Itu akan menjadi pengaturan yang sangat tidak biasa.

— JacquesB

18

Ketika Anda menambahkan kompleksitas, kode akan berjalan lebih lambat. Memperkenalkan layanan REST jika tidak diperlukan akan memperlambat eksekusi karena sistem melakukan lebih banyak.

Mengabstraksi database adalah praktik yang baik. Jika Anda khawatir tentang kecepatan, Anda bisa melihat cache data dalam memori sehingga database tidak perlu disentuh untuk menangani permintaan.

Sebelum mengoptimalkan kinerja meskipun saya akan melihat ke masalah apa yang Anda coba selesaikan dan arsitektur yang Anda gunakan, saya berjuang untuk memikirkan situasi di mana opsi basis data akan menjadi akses langsung vs REST.

— Klee
sumber

+1 untuk menyebutkan caching. Meskipun itu dilakukan extra work. Tetapi sebenarnya itu bisa lebih cepat dengan caching permintaan berulang.

— Yana Agun Siswanto

3

@ Tinggalkan Jawaban Anda tidak tepat. »Memperkenalkan layanan REST jika tidak diperlukan akan memperlambat eksekusi karena sistem melakukan lebih banyak.« Tidak dalam setiap kasus apakah ada lalu lintas ke titik akhir sama sekali, jika misalnya reverse-proxy dapat menangani hasil yang rumit.

— Thomas Junk

@klee Alasan saya mengajukan pertanyaan ini adalah dari programer SO post.stackexchange.com/questions/277701/… ini - satu jawaban berbicara tentang bagaimana Amazon sukses besar dengan menggunakan sistem yang sepenuhnya tenang, bukannya akses langsung. Baru saja membuat saya berpikir ...

— Micro

9

Jika Anda khawatir tentang kecepatan, maka ya layanan Istirahat akan lebih lambat karena alasan yang disebutkan di atas. Namun, kecepatan tipe yang Anda gambarkan jarang menjadi perhatian utama dan jika ya, dapat diatasi dengan cara lain. Optimalisasi prematur adalah akar dari semua kejahatan .

Pertimbangkan jika perhatian utama Anda adalah interoperabilitas (seluler, web, B2B), sekarang REST sangat menarik karena merupakan teknologi agnostik.

Misalkan Anda kode untuk basis data. Apa yang akan Anda lakukan jika Anda memilih untuk mengubah penyimpanan data yang mendasarinya. Seberapa sulit untuk dilakukan jika Anda tergabung erat dengan toko yang mendasarinya?

Jawaban sebenarnya tergantung , tapi mudah-mudahan saya telah memberi Anda beberapa hal untuk dipikirkan!

— Romski
sumber

6

Jika sulit menjawab pertanyaan ini.

Jawaban umum yang benar adalah: itu tergantung.

Cara saya melihatnya dengan REST:

Anda membuat objek dalam kode Anda untuk memanggil metode REST

Panggil metode http

Kode di dalam REST API Anda menanyakan basis data

Database mengembalikan beberapa data

Kode API REST mengemas data ke Json dan mengirimkannya ke klien Anda

Klien menerima respons Json / XML

Respons peta terhadap objek dalam kode Anda

Ada kesalahan dalam pikiran Anda.

Dan kesalahan ini berasal dari fakta, bahwa Anda tidak sepenuhnya memahami REST dan prinsip-prinsipnya. REST tidak ditemukan, karena beberapa kutu buku merasa keren (tentu saja) untuk mengirim objek Javascript melalui HTTP melalui kabel. Keuntungan utama menggunakan HTTP adalah kemungkinan menggunakan Caching . Jika Anda membuat hasil Anda dapat disimpan dalam cache , maka ada lebih sedikit permintaan untuk dibuat ke DB. Dan tidak ada marshalling yang terlibat. Jawabannya bisa disampaikan langsung.

Jawaban Insofar @Klees tidak tepat :

Ketika Anda menambahkan kompleksitas, kode akan berjalan lebih lambat. Memperkenalkan layanan REST jika tidak diperlukan akan memperlambat eksekusi karena sistem melakukan lebih banyak.

Ketika berhadapan dengan hasil cacheables, tidak ada dampak pada aplikasi Anda: memberikan jawaban yang diketahui untuk pertanyaan yang diketahui dapat dilakukan melalui proksi terbalik.

— Thomas Junk
sumber

4

Jika data dapat di-cache di lapisan layanan lainnya, maka itu bisa di-cache di aplikasi web, yang akan jauh lebih baik untuk kinerja.

— JacquesB

Cara tercepat adalah, tidak memukul aplikasi web sama sekali.

— Thomas Junk

1

Dan hanya untuk membuatnya lebih menarik, tidak semua "hit" ke database sama jika Anda dapat mengakses dalam memori v. Disk.

— JeffO

@ThomasJunk: Jika saya memahami pertanyaan asli dengan benar, klien adalah aplikasi web, dan pertanyaannya adalah apakah aplikasi web harus terhubung ke db secara langsung atau menelepon melalui layanan lain.

— JacquesB

1

Itu tidak mengubah apa pun pada jawaban saya. Memanggil REST-Service termasuk memanggil ke Web-Server yang mungkin berada di belakang proxy terbalik di mana kemungkinan jawaban bisa di-cache - seperti yang sudah saya katakan.

— Thomas Junk

2

Memperkenalkan tier layanan ekstra selalu memiliki biaya dalam kompleksitas dan overhead kinerja. Ada beberapa jenis arsitektur tertentu di mana memperkenalkan tier layanan bersama (seperti REST API) dapat meningkatkan daya karena caching bersama - tetapi sepertinya itu bukan jenis arsitektur yang Anda miliki.

Pertimbangkan arsitektur tempat Anda memiliki beberapa aplikasi web atau beberapa aplikasi desktop yang terhubung langsung ke database yang sama. Jika mereka sering melakukan permintaan yang sama, itu dapat meningkatkan kinerja untuk men-cache hasil query di layanan bersama. Terutama jika Anda telah mengatakan ratusan aplikasi desktop mengakses database yang sama secara langsung (bukan melalui aplikasi web!) Dan melakukan pertanyaan yang sama, mungkin ada peningkatan besar. Namun, bahkan dalam arsitektur ini, alasan utama untuk memperkenalkan layanan bersama mungkin adalah keamanan dan abstraksi data daripada kinerja.

Tapi sepertinya Anda memiliki satu aplikasi web yang terhubung ke database secara langsung. Dalam hal ini tidak ada manfaatnya untuk memperkenalkan lapisan layanan tambahan. Caching, abstraksi basis data, dll. Dapat ditangani pada lapisan akses data dalam aplikasi yang sama.

— JacquesB
sumber

1

Tergantung.

Jelas, semakin banyak lapisan dalam kode Anda semakin lambat. Tapi ... ada titik di mana kinerja ujung-ke-ujung langsung tidak masalah sebanyak skalabilitas. Jika Anda memiliki 1 pengguna yang mengakses database Anda di PC lokal, itu bisa berjalan cepat. Jika Anda memiliki seribu pengguna yang mengakses DB yang sama di PC yang sama, kemungkinan Anda akan melihat mereka semua merasa frustrasi. Solusinya adalah dengan memindahkan DB ke kotak lain, tambahkan layer di tengah dan meskipun untuk 1 pengguna, itu akan melakukan lebih lambat, ketika ribuan mengaksesnya, itu akan lebih cepat. (itu jawaban yang simplistis tetapi benar secara prinsip).

Ada alasan lain untuk menyembunyikan DB Anda di belakang lapisan tingkat menengah, seperti keamanan.

— gbjbaanb
sumber

-2

Saya tidak tahu di mana Anda tersesat, tetapi cukup jelas, ketika Anda menggunakan REST API Anda melakukan langkah ekstra, dan langkah tambahan "selalu" berarti lebih lambat ketika pemrograman terlibat.

Ada pro dan kontra, tetapi jika Anda dapat mengakses database langsung dari aplikasi Anda, lebih baik menyebutnya langsung daripada menggunakan Web API, tentu saja jika Anda menggunakan Web API Anda dapat dengan mudah mem-port aplikasi Anda ke platform yang berbeda.

— kirie
sumber

1

»Saya tidak tahu di mana Anda tersesat, tetapi cukup jelas, ketika Anda menggunakan REST API Anda melakukan langkah ekstra, dan langkah tambahan" selalu "berarti lebih lambat ketika pemrograman terlibat.« Jika itu berarti lebih lambat dalam eksekusi, itu tidak benar.

— Thomas Junk

1

Tidakkah ada situasi di mana mengakses database adalah ide yang buruk selain dari portabilitas saja? Terkadang memiliki REST API dll dapat menjaga lebih banyak logika (dan keamanan yang lebih baik?) Di sisi server, kan?

— J Trana

@JTrana yang bisa ya atau tidak, sangat tergantung pada bagaimana Anda melakukan sesuatu saat memperkenalkan lapisan tambahan dapat memberikan lapisan keamanan ekstra, menambahkan lapisan tambahan juga berarti bahwa Anda memiliki lebih banyak kesempatan untuk mengacaukan sesuatu dan mengekspos lubang keamanan. Saya pikir titik API Web adalah untuk mengekspos "API" Anda. Aplikasi besar seperti Facebook, Amazon, Google yang perlu menyediakan akses ke pihak ke-3 dan memiliki banyak platform harus memiliki Web API, tetapi untuk aplikasi kecil Anda harus berpikir dua kali sebelum melakukannya.

— kirie

-2

SISA:

terbuka untuk multi frontend dan 1 backend
perlu membuat API Anda sendiri (atau menggunakan yang seperti Loopback)
tidak bekerja offline

DB lokal:

tidak dibuka untuk 'tingkatan', mereka harus memiliki akses ke backend Anda untuk melakukan sinkronisasi
tidak perlu membuat API, gunakan antarmuka DB
bekerja offline

PERBEDAAN INI SANGAT BESAR, ORANG-ORANG YANG SERING LUPA

— Benjamin Fuentes
sumber

2

-1. Meskipun tidak ada "kebutuhan" untuk membuat API, tidak membuat DAL sering menyebabkan rasa sakit yang sangat besar jika perubahan backend database diperlukan. Juga tidak ada alasan mengapa jika Anda memiliki DB "offline" bahwa layanan Rest tidak dapat dibuat tersedia di sana juga.

— James Snell