API Gateway Pattern

Penggunaan Api Gateway Pada Microservice

Pada microservice arsitektur, terdapat sebuah fakta bahwa setiap service akan mengekspose endpoint lebih detil. Dengan demikian, hal ini akan mempengaruhi cara client atau service-service luar yang menghakses service-service pada microservice.

Terdapat beberapa cara dunia luar mengkases service-service yang ada pada microservice. Salah satunya dengan pengaksesan langsung atau direct access pada service-service yang dipunya. Ada pula cara lain yaitu dengan cara malalui suatu layanan suatu service sebagai pintu utama untuk mengakses service-service pada microservice. Service ini dinamakan sebagai API Gateway.

Cara pertama yang sering banyak digunakan, walaupun bukan pendekatan yang terbaik adalah dengan cara mengakses langsung pada setiap service. Biasanya setiap service memiliki suatu IP public yang dapat diakses dari jaringan internet. Terkadang juga dengan satu IP public tetapi dibedakan port untuk melayani setiap servicenya.

Pada sistem aplikasi terdisribusi dimana tingkat availibility sangat diperlukan maka biasanya sebelum service tersebut di depanya dipasang terlebih dahulu load balancer yang bertugas membagi beban request. Hampir semua layanan cloud seperti AWS atau GCP akan memiliki fasilitas load balancer yang bisa digunakan.

Pengungaan direct acces pada service ini mungkin akan cukup baik dan effective untuk sistem microservice kecil. Akan tetapi, untuk sistem microservce yang sudah sangat besar dimana banyak sekali service-service yang digunakan maka penggunaan direct acces ini tidak disarankan untuk digunakan.

Berikut adalah pertimbangan yang musti diperhatikan ketika layanan service kita sudah sangat besar.

Bagaimana sistem kita yang berposisi sebgai frontend atau mobile app mengurangi jumlah request ke bagian back end dan menurunkan komunikasi yang kurang baik pada sistem microservice kita. Karena pada dasarnya, sistem kita bakal memiliki batasn layanan requesdt baik itu karena budget data ataupun keterbatasan dari resouce sistem. Apalagi karena sistem kita sudah tebuka maka dimungkinkan sekali ada beberapa orang yang berniat tidak baik terhadap sistem kita dengan membebani terus menerus service-service kita dengan jutaan request.
Bagaimana sistem kita akan menangani cross-cutting concerns seperti security dan authorization, transformasi data,dan dispaching untuk requst yang dinamik.
Bagaimana sistem kita dapat menangai komunikasi dari dunia luar tetapi dengan protokol yang tidak umum.
Bagaimana kita membut sebuah fascade layer khusunya untuk menangani request dari mobile apps.

Cara kedua untuk mengakses service-service pada microservice adalah dengan menggunakan Api Gateway. Seperti dijelaskan di atas apabila sistem kita sudah besar maka Api Gateway akan sangat bagus dalam menjawab permasalah yang timbul seperti di jelaskan di atas.

Selain digunakan untuk menjawab permasalahan di atas, api gateway memilik kelebihan sebagai bertikut.

Loose Coupling. Dengana adanya api gateway kita dapat menurunkan tingkat ketergantungan client terhadap serivce-servive yang ada. Apabila kita melakukan refactoring dan maintenace akan membuat impact pada client kita secara langsung. Dimungkinkan terjadi breaking pada client yang mengkonsume service-servivce kita. Api gateway dapat menbuat yang asalanya sangat coupled menjadi loose coupling.
Terlalu banyak Round Trip. Suatu halamam front end atau mobile app teakadang memerlukan banyak sekali pemanggilan kebeberapa service yang berbenda. Atau jika service yang dibuat tidak terlalu bagus, bisa saja terjadi banyak pemanggilan pada service yang sama. Dengan adanya api gateway kita dapat menurunkan tinggat latency dengan membuat agregate pada api gateway untuk menggabungkan beberapa pamamangilan api yang terjadi. Biasanya untuk keperluan ini kita musti dapat melakukan customize pada api gateway yang kita gunakan.
Security. Tanpa api gateway, apabila kita akan menerapkan security maka kita harus membuat dan menginplementasikannya di setiap service yang ada. Hal ini menjadi tidak effisien dan terlalu banyak usaha yang harus dikorbankan. Dengan api gateway kita hanya perlu melakukan implement security di level api gatwaye dan setiap service kita tempatkan di linkungan private yang tidak terekspose secara langsung dari luar.
Cross-cutting concern. Proses penerapan authorization, SSL, dan hal-hal lainya yang berhubungan tetapi bukan proses utama atau pendukung dapat kita implementasikan di bagian gateway sehigga membuat setiap service menjadi lebih sederhana.

API Gateway adalah suatu service yang dibuat khusus dan dijadikan sebagai pintu utama atau entry point dari dunia luar untuk masuk ke dalam service-serivce kita. Ini hampir sama dengan fascade layer pada OOP tetapi ada bagian sistem yang terdistribusi. API gateway pattern kadang disebut juga sebagai “Back end for Fronend” atau BFF karena kita membuatnya sambil memikirkan kebutuhan frontend.

Dikarenakan hal-hal di atas maka api gateway akan berada di antara client dan servcie-service kita. Ini berfunsi sebagai revernse proxy untuk merouting request dari client ke service-service.

Jika kita lihat dari diagram di atas maka semua request yang datang dari berbagai platform akan dihandle atau melalui api gateway.

Fakta ini menjadi penting dan perlu diperhatikan karena dengan semakin tumbuhnya aplikasi kita maka api gateway menjadi sangat gemuk dan tumbuh berdasarkan banyaknya persyaratan yang berbeda dari tiap client. Akhirnya, memungkinkan terjadi monolith baru.

Oleh karena itu, API Gateway harus dipisahkan berdasarkan batasan bisnis dan aplikasi klien, dan tidak bertindak sebagai agregator tunggal untuk semua layanan mikro internal. Ini sangat berresiko jika api gateway mati atau bermasalah masa semua platform yand di punya bermasalah juga.

Saat membagi tingkat API Gateway menjadi beberapa API Gateway, jika aplikasi Anda memiliki beberapa aplikasi klien, itu bisa menjadi poros utama saat mengidentifikasi beberapa jenis API Gateway, sehingga Anda bisa memiliki fascade yang berbeda untuk kebutuhan setiap aplikasi klien.

Kasus ini adalah pola bernama “Backend for Frontend” ( BFF ) di mana setiap API Gateway dapat menyediakan API berbeda yang disesuaikan untuk setiap jenis aplikasi klien, bahkan mungkin berdasarkan faktor bentuk klien dengan mengimplementasikan kode adaptor tertentu yang di bawahnya memanggil beberapa layanan mikro internal, seperti yang ditunjukkan pada gambar berikut.

Best praktis penggunaan API Gateway berdasarkan jenis client

Selain bedasarkan jenis client bisa juga api gateway dibuat berdasarkan bussines domain. Misalkan API Gaeway untuk customer facing dan API Gateway untuk Admin atau Back Office.

Berikut adalah fitur utama yang harus ada pada sebuah API Gateway.