Bayangkan Anda berada di dalam stasiun kereta yang akan memberangkatkan Anda menuju suatu kota. Anda tidak tahu mengetahui jalur kereta yang akan Anda gunakan, sudah pasti Anda akan menanyakan itu ke tempat informasi, kemudian Anda juga melihat banyak orang menanyakan jalur kereta nya di tempat informasi itu juga. Dari sini kita bisa menyimpulkan bahwa tempat informasi itu selalu menunjukan jalur yang tepat sesuai dengan keberangkatan pelanggan. Seperti itulah API Gateway bekerja. Pengguna kereta api itu bisa kita artikan sebagai request, kemudian tempat informasi itu sebagai API Gateway yang bertugas untuk meneruskan request ke resource yaitu jalur kereta yang tepat. Dalam lingkungan sistem terdistribusi atau yang lebih kita kenal sebagai microservices, terdapat dua cara dunia luar (Client) supaya bisa berkomunikasi dengan service-service yang ada pada microservice.
- Pengaksessan langsung ke service yang dituju
Diagram diatas bisa kita lihat bahwa mobile app dan web app mengakses langsung setiap service. Secara kasat mata, tidak ada masalah dan secara teknis itu bisa bekerja. Namun dikemudian hari, karena pengaksesan langsung menjadikan pola komunikasi client-service menjadi sangat erat (tight-couple) sehingga setiap ada perubahan service seperti penggantian nama endpoint, refactoring, akan menimbulkan impact juga ke sisi clien app (mobile app, dan web app), tentu hal ini sangat tidak diinginkan apalagi jika aplikasi yang dibuat sudah sangat besar dan melibatkan banyak developer. Dari contoh kasus diatas, kita perlu sebuah solusi dimana setiap perubahan-perubahan kecil yang terjadi di setiap service tidak langsung menimbulkan impact ke client app. Disini kita perlu sebuah abstraction layer yang membantu client app sehingga client app tidak perlu lagi mengetahui detail dari setiap service nya itu. Cukup dengan kontrak yang sudah dibuat maka client app sudah bisa berkomunikasi dengan service-service.
- Pengaksesan menggunakan sebuah layanan
Dari permasalahan diatas bahwa kita perlu sebuah abstraction layer yang bisa bertindak sebagai sebuah pengatur traffic, atau sebuah router dan menyediakan sebuah single entry point untuk setiap service. Konsep ini mirip dengan Facade pattern pada konsep pemrograman berorientasi object Dari hal itulah kemudian muncul istilah API Gateway.
Diagram diatas memberikan informasi bahwa client app sudah tidak memiliki hubungan yang erat ( tight couple ) lagi ke setiap service nya. API Gateway akan meneruskan setiap request yang dilakukan client app dan meneruskan ke setiap service yang dituju. Menggunakan API Gateway akan sangat bermanfaat ketika sebuah sistem sudah banyak mempunyai service salah satunya untuk para pengembang sisi client misalnya. Mereka tidak perlu banyak menaruh url setiap service disetiap kode nya cukup menggunakan satu url API Gateway dan semuanya akan bekerja. Disamping itu kita bisa melihat traffic sebuah sistem dari sisi API Gatewaynya dan melihat service mana saja yang load nya sangat berat. Seiring berkembangnya teknologi khususnya dalam dunia cloud computing banyak provider API Gateway yang sudah digunakan saat ini seperti Amazon API Gateway, GCP API Gateway dan Azure API Management. Semua teknologi ini menawarkan kemudahan developer untuk menghandle traffic dari luar. Namun perlu diingat setiap menggunakan layanan cloud pasti ada cost yang perlu diperhitungkan. Untuk contoh perhitungannya kita bisa lihat di situs aws misalnya aws.amazon.com/api-gateway/pricing disana bisa lihat :
An API is used in a Serverless Web Application that invokes Lambda to return dynamic webpage content. The site gets 10,000 page loads per minute. Each API request is 12KB and the response is 46 KB.
10,000 page loads/minute 60 minutes/hour 24 hours/day * 30 days/month / 1,000,000 = 432 million requests per month.
300 million * $1.00/million = $300
132 million * $0.90/million = $118.8
Total =
$418.8 ($0.97 per million)
Disamping provider API Gateway yang berbayar, terdapat juga beberapa API Gateway provider yang bersifat opensource yang bisa kamu gunakan dalam pengembangan aplikasi kamu diantaranya :
- Kong Gateway OSS
- Tyk
- KrakenD
- Gravitee.io
- Gloo Edge
- Goku API Gateway
- WSO2 API Gateway
- Fusio
- Apiman
- API Umrella
Karena fungsi awalnya sebagai perantara komunikasi antara dunia luar (client) dengan sistem internal maka peran API Gateway sangatlah penting dalam sebuah arsitektur sistem. Pengembangan fitur API Gateway masih terus berlanjut sehingga yang asalnya peran sebatas penghubung, sekarang banyak fitur baru yang juga sangat penting terkait traffic sebuah request yaitu :
- Authentication dan Authorization
- Cache
- Rate Limiter
- Load Balancing
- IP Whitelisting
- Reverse Proxy
- etc
Disamping manfaat menggunakan API Gateway diatas, juga terdapat beberapa kelemahan menggunakan API Gateway sepeti akan ada kurva pembelajaran ketika sebuah aplikasi akan dirancang menjadi high availability, API Gateway akan menjadi titik kegagalan tunggal dan membutuhkan lebih banyak orchestrasi yang akan menambah kesulitan untuk para pengembang.
API Gateway dibuat untuk mempermudah komunikasi antara client dan aplikasi server sehingga diharap dengan adanya API Gateway client tidak perlu mengetahui betul detail dari setiap service yang diakses. Selain itu dari sisi service juga akan lebih mudah untuk dipelihara dan dikembangakan karena tidak ada keterikatan erat antara client dan server.
sumber :
https://www.asditaprasetya.com/api-gateway-untuk-pengembangan-microservice/
https://medium.com/the-legend/api-gateway-pattern-ef5cd3b2ae50
https://www.nginx.com/learn/api-gateway/
https://dashbird.io/knowledge-base/api-gateway/pros-and-cons-of-using-an-api-gateway/