Gerbang API vs. proxy balik

Untuk menangani arsitektur microservice, itu sering digunakan bersama Reverse Proxy (seperti nginx atau apache httpd) dan untuk masalah lintas sektor implementasi pola API gateway digunakan . Terkadang Proksi terbalik melakukan pekerjaan gateway API.
Akan baik untuk melihat perbedaan yang jelas antara kedua pendekatan ini. Sepertinya manfaat potensial dari penggunaan gateway API adalah meminta beberapa layanan mikro dan menggabungkan hasilnya. Semua tanggung jawab lain dari API gateway dapat diimplementasikan menggunakan Reverse Proxy. Seperti:

• Otentikasi (Dapat dilakukan menggunakan skrip nginx LUA);
• Keamanan transportasi. Itu sendiri tugas Reverse Proxy;
• Penyeimbang beban
• ....

Jadi berdasarkan ini ada beberapa pertanyaan:

1. Apakah masuk akal untuk menggunakan API gateway dan Reverse proxy secara bersamaan (sebagai contoh request-> Api gateway-> reverse proxy (nginx) -> konkret mictoservice)? Dalam kasus apa?
2. Apa perbedaan lain yang dapat diimplementasikan menggunakan API gateway dan tidak dapat diimplementasikan oleh Reverse proxy dan sebaliknya?

Lebih mudah untuk memikirkannya jika Anda menyadari bahwa mereka tidak saling eksklusif. Pikirkan gateway API sebagai implementasi proxy balik jenis tertentu.

Berkenaan dengan pertanyaan Anda, tidak jarang melihat keduanya digunakan bersama saat gateway API diperlakukan sebagai tingkat aplikasi yang berada di belakang proxy terbalik untuk load balancing dan health check. Contohnya adalah sesuatu seperti arsitektur sandwich WAF di mana Aplikasi Web Anda Firewall / API Gateway diapit oleh tingkatan proxy terbalik, satu untuk WAF itu sendiri dan yang lainnya untuk masing-masing layanan mikro yang diajak bicara.

Mengenai perbedaannya, mereka sangat mirip. Itu hanya nomenklatur. Saat Anda melakukan penyiapan proxy balik dasar dan mulai mengaktifkan lebih banyak bagian seperti autentikasi, pembatasan kecepatan, pembaruan konfigurasi dinamis, dan penemuan layanan, orang-orang lebih cenderung menyebutnya sebagai gateway API.

Saya yakin, API Gateway adalah proxy balik yang dapat dikonfigurasi secara dinamis melalui API dan berpotensi melalui UI, sedangkan proxy balik tradisional (seperti Nginx, HAProxy atau Apache) dikonfigurasi melalui file konfigurasi dan harus dimulai ulang saat konfigurasi berubah. Jadi, API Gateway harus digunakan ketika aturan perutean atau konfigurasi lain sering berubah. Untuk pertanyaan Anda:

1. Masuk akal selama setiap komponen dalam urutan ini memenuhi tujuannya.
2. Perbedaan tidak ada dalam daftar fitur tetapi pada cara perubahan konfigurasi diterapkan.

Selain itu, API Gateway sering kali disediakan dalam bentuk SAAS, seperti Apigee atau Tyk misalnya.

Juga, inilah tutorial saya tentang cara membuat API Gateway sederhana dengan Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Semoga membantu.

API Gateways biasanya beroperasi sebagai konstruksi L7.

API Gateways menyediakan fungsionalitas tambahan dibandingkan dengan reverse proxy biasa. Jika Anda mempertimbangkan beberapa portal di luar sana, mereka dapat menyediakan:

• Manajemen Siklus Hidup API lengkap termasuk dokumentasi
• portal yang dapat digunakan sebagai sumber kebenaran untuk berbagai aplikasi klien dan tempat Anda dapat menyediakan tata kelola klien, pembatasan tarif, dll.
• perutean ke berbagai versi API termasuk versi canary / beta
• mendeteksi pola penggunaan, mendaftarkan aplikasi, mengambil kredensial klien, dll.

Namun dengan munculnya jerat layanan seperti Istio, Konsul banyak fungsi dari API Gateways akan dimasukkan oleh jerat.