tl;dr
- Sedang berupaya mengimpelementasikan indikator notifikasi baru, SSE adalah percobaan pertama penulis dari sekian banyak teknik yang ada
- Terkait cara kerja SSE, perlu dipertimbangkan kecocokan penerapannya dan kasus yang kemungkinan terjadi
- Kebanyakan artikel termasuk jurnal ilmiah yang menjelaskan SSE menggambarkan bahwa SSE sebagai cara yang efisien dan malah disebut sebagai cara Async (padahal ga banget)
- Response yang dikirim server tidak benar-benar realtime jika menggunakan SSE.
Latar belakang
Beberapa waktu lalu, penulis mengembangkan modul notifikasi untuk website yang akan digunakan banyak entitas nanti, semua berjalan baik (karena memanfaatkan table database untuk menampung data notifikasi, lalu menarik daftar notifikasi berdasarkan user id nya) yaaa pokoknya easy peasy lah, tapi ada yang kurang, yaitu indikator notifikasi yang mati dan hanya bertengger mati di logo bell
Opini Umum terkait Cara Kerjanya
Penulis berfikir, hal seperti apa yang bisa mengatur munculnya indikator pada bell tersebut? paling tidak diperlukan alur yaitu client melakukan hit request (permintaan) melalui endpoint, selanjutnya mengharapkan respons dari backend berupa angka berupa jumlah notifikasi yang belum dibaca, jika angka lebih dari 0, munculkan indikator, selain itu? sembunyikan, tentu bisa pakai long polling, atau short polling tetapi kelihatannya akan boros di waktu (menunggu response) dan resource yang diperlukan (oleh client untuk hit dan server untuk memproses permintaan)
tapi yang menjadi pertanyaan adalah bagaimana agar jumlah event yang terjadi antara server dengan client tidak melebihi batas wajar?
Upaya Awal
Karena momennya masih persiapan dan perlu uji coba, Penulis akan mencoba SSE (Server-Sent Events) terlebih dahulu sekaligus membahasnya, kenapa SSE dulu? SSE inilah yang pertama kali ditunjukan ke penulis saat sedang scroll Youtube shorts dikala itu😛
Apa itu Server-Sent Events?
Cara kerja Server-Sent Event
Merupakan teknologi pada browser untuk mendapatkan update otomatis dari server melalui protokol HTTP. Menerapkan komunikasi satu arah yaitu diawali dengan client ke server, lalu dari server ke client seterusnya. Adapun cara kerja dari SSE yaitu memicu event dengan melaksanakan aliran data berbasis text dari server ke klien secara terus menerus, standarnya adalah tidak sampai sedetik (jika local) tergantung infrastruktur, tetapi bisa diatur dengan melampirkan “retry” dalam satuan ms pada body response, retry ini bertugas untuk memberitahu browser kapan endpointnya di hit kembali. Tipe request ini adalah GET.
jangan berfikir untuk melampirkan data dari client melalui parameter ya, utamakan fungsi yang dituju saja, sebagai informasi bahwa SSE tidak support metode request selain GET.
SSE bisa dikatakan sebagai upaya upaya dari sekian banyak cara untuk mengimplementasi studi kasus seperti angka notifikasi yang up-to-date, atau indikator pesan yang belum dibaca.
Kekhawatiran menggunakan SSE berdasarkan pengalaman
Kekhawatiran harus timbul dari pengetahuan kita terhadap kelebihan dan kekurangannya, berikut dijelaskan kelebihan dan kekurangannya yang penulis kutip dari berbagai sumber
Alur Response menggunakan SSE (setting 10 detik terjadi request)
Keuntungan SSE
- Dapat melakukan koneksi otomatis jika terjadi putus koneksi yang bukan atas instruksi dari kodenya atau kejadian tiba2 diluar nalar, bahkan termasuk menangkap data yang sempat tertunda lama dari kejadian tersebut
Kelemahan SSE
- Tidak dapat membuka koneksi jika sudah lebih dari 6 tab pada 1 browser, apa yang akan terjadi jika lebih dari 1 tab? maka requestnya akan dipending (setidaknya tutup salah satu tab, baru tidak pending lagi)
- Koneksi tetap terbuka dan penerimaan data dari server berbasis waktu konstan, tidak bisa kirim “seperlunya”, menyebabkan client terus menerima data dari server secara interval dengan jarak waktu yang konstan (lihat gambar diatas)
- AJAX Lain tidak ter-eksekusi hingga Endpoint SSE Selesai requestnya (tidak bisa async)
Pertimbangan di Sisi Server
Karena banyaknya request yang diterima server untuk menjalankan SSE atau Content-Type: text/event-stream, kita tidak tau seberapa lama server bisa memberi response balik (walaupun sudah ditentukan konstan waktu untuk mengirim data ke client), kemungkinan semua request dan proses ditelan dahulu sampai server selesai melaksanakannya lalu memberi response lagi, dan akan memberi response lagi sesuai dengan waktu yang ditentukan, bagaimana agar tidak harus menunggu response tiba dan segera memutus sambungan? solusi sesaatnya adalah refresh halaman, di awal-awal SSE tidak melambat, tetapi jika client terus berada di halaman yang sama tanpa refresh halaman? akan semakin melambat, apalagi banyak client yang mengakses endpoint event stream tersebut, kasus ini dialami oleh kawan developer berikut
Gambar Contoh kekhawatiran yang dimaksud
Asumsi penulis adalah developer tersebut tidak menentukan berapa lama proses di server terjadi dan tidak melampirkan “retry” pada body response, bisa jadi penerapan SSE sangat standar sebagaimana yang ditunjukan di w3school ini sehingga terjadilah kasus yang ditunjukan gambar diatas yang mana sama dengan kekhawatiran yang dijelaskan pada paragraf sebelumnya.
Sisi Client
Jika terjadi (misal) request AJAX setelah hit ke endpoint SSE yang proses nya belum selesai (misalkan terjadi sleep() disitu), maka SSE harus selesai terlebih dahulu dan request AJAX jadi pending, dapat dilihat pada gambar dibawah ini
Menguji bahwa SSE tidak Async-Async banget (jk)
Jika ada yang ngotot kalo SSE Async padahal sudah ada buktinya? silahkan pelajari perbedaa async dengan yang bukan disini. Jika masih percaya SSE Async? itu hanya karena response time dari server cepat aja.
Ingin Coba SSE?
Penulis mah gampang-gampang aja, pakai PHP dong ujicobanya 😁, artikel berikut dari web.dev membantu kalian mencoba SSE dengan project php, tetapi perlu kalian ketahui bahwa pada kode php nya meng-eksekusi perulangan while, yang artinya saat terjadi hit ke endpoint tersebut, proses terus terjadi dalam satu request, tapi masih pada mode aman karena disetting sleep. Jangan coba-coba inject kode while tersebut ke sesuatu yang memerlukan selesai cepat eksekusi. Lebih amannya jika kalian coba dari w3school saja tanpa ada perulangan.
Sekian dari penulis, semoga dapat menjadi bagian dari pertimbangan kalian sebelum menerapkan SSE, punya pengalaman dengan SSE atau ingin mematahkan statement yang dinyatakan pada artikel ini? sampaikan di kolom komentar 😁
Referensi
- https://dev.to/miketalbot/server-sent-events-are-still-not-production-ready-after-a-decade-a-lesson-for-me-a-warning-for-you-2gie
- https://elib.unikom.ac.id/files/disk1/708/jbptunikompp-gdl-rezafahlev-35389-7-unikom_r-i.pdf
- https://web.dev/articles/eventsource-basics
- https://stackoverflow.com/questions/14111537/correct-method-of-implementing-sse-eventsource
- https://www.w3schools.com/html/html5_serversentevents.asp
- https://medium.com/@sijariemas/tentang-server-sent-events-sse-2042fcde9cd7
- https://www.geeksforgeeks.org/difference-between-synchronous-and-asynchronous-requests-in-jquery-ajax/