Penerapan Paradigma Fungsional di Industri — Paradigma Fungsional Praktis, Part 5
Artikel ini adalah bagian dari sebuah seri artikel tentang Paradigma Fungsional Praktis. Silakan lompat ke akhir artikel untuk melihat navigasi keseluruhan seri ini.

Teknologi-teknologi di bawah ini mungkin tidak dibuat menggunakan bahasa pemrograman “fungsional”, tapi mereka menerapkan beberapa paradigma fungsional untuk melakukan tugas mereka. Bagian ini ingin memperlihatkan pada Anda contoh masalah apa saja yang berhasil dipecahkan dengan pendekatan paradigma fungsional.
UI Deklaratif dan Manajemen State (React dan Redux)
Di dunia pemrograman front-end beberapa tahun lalu, sebelum React terkenal, beberapa framework Javascript pesohor di bidang ini adalah Angular.js, Ember, Knockout.js, dan Backbone.js. Mereka memiliki banyak pengguna dan dianggap sebagai penemuan besar untuk membuat halaman web yang interaktif pada waktu itu.
Tapi kemudian React datang. Sekarang, mengetahui teknologi React hampir menjadi kewajiban bagi front-end Javascript developer. Semakin banyak yang meninggalkan framework-framework sebelumnya dan beralih ke React. Bagaimana itu bisa terjadi?
Saya ingin berargumen bahwa salah satu faktor besarnya adopsi React adalah karena ia menggunakan pendekatan deklaratif untuk membangun UI.
Angular, Ember, Knockout, dan Backbone dulunya menggunakan arsitektur model-view-controller (MVC), lengkap dengan data-binding. Arsitektur ini telah terbukti berhasil digunakan untuk back-end, seperti misalnya pada Ruby on Rails, Symfony, dan Spring. Tapi ternyata, mengadopsi MVC untuk front-end menyebabkan aplikasi kita sulit dimengerti ketika ukurannya sudah cukup besar.
React memecahkan masalah itu dengan pendekatan deklaratif. Dalam sebuah component, kita menjelaskan bagaimana UI komponen tersebut terbentuk pada suatu waktu. Kalau Anda melihat lebih dekat, komponen pada React secara esensial adalah sebuah fungsi! Fungsi tersebut menerima masukan melalui props dan state, dan mengembalikan representasi UI sebagai keluarannya. Detail tentang bagaimana mengubah DOM menjadi detail implementasi yang developer tidak perlu tahu (terdengar familiar?). Pada React versi 0.14 bahkan diperkenalkan stateless functional components, yaitu pendefinisian komponen menggunakan function tanpa referensi ke state (hanya props).
Tentu kita tetap memerlukan state pada aplikasi Javascript kita; itulah yang membuatnya interaktif. Salah satu library yang juga umum digunakan bersama React adalah Redux. Redux merupakan sebuah library untuk manajemen state, di mana state aplikasi kita disimpan dalam sebuah tree yang tersentralisasi, yang menjadikannya lebih mudah dimengerti dibanding state yang tersebar di banyak komponen.
Redux, menurut saya, adalah pengaplikasian bagus soal konsep pemisahan antara state dan behavior yang saya bahas tadi. Reducer, fungsi untuk meng-update state, merupakan sebuah fungsi transformasi data state sebelumnya berdasarkan suatu deskripsi action. Dokumentasi soal reducer secara eksplisit mengatakan bahwa memastikan reducer sebagai pure function sangat penting.
Sudah banyak kasus yang menyuarakan bahwa penggunaan React dan Redux dalam aplikasi membuat alur data dan representasi UI pada aplikasinya jauh lebih mudah dimengerti. Redux sendiri terinspirasi pada bahasa Elm, bahasa fungsional yang ramah-pemula untuk membangun UI yang menargetkan Javascript dalam kompilasinya. Anda mungkin tertarik untuk mencoba Elm!
Pemrograman Konkuren dan Paralel (Erlang dan Elixir)
Di saat bahasa pemrograman lain sedang bersusah payah menambahkan fitur konkurensi dan multicore (kemampuan berjalan pada lebih dari satu core) pada platform mereka, Erlang sudah melakukannya sejak lama untuk switch telepon perusahaan Ericsson.
Software untuk meng-handle saluran telepon secara natural merupakan program dengan konkurensi tinggi; sebuah switch harus mampu melayani puluhan hingga ratusan ribu transaksi. Pada tahun 1986, belum ada bahasa pemrograman yang secara spesifik mengatasi hal tersebut. Oleh karena itu, Ericsson, sebagai salah satu perusahaan telekomunikasi terbesar, pada tahun tersebut membuat sebuah bahasa pemrograman baru: Erlang.
Model konkurensi pada Erlang adalah kode berjalan pada banyak lightweight processes — proses ringan. Proses tersebut jauh lebih ringan dari proses pada OS, sehingga sangat wajar dalam sebuah aplikasi terdapat hingga jutaan proses yang berjalan. Proses ini diatur oleh sebuah scheduler yang menentukan setiap proses mendapat kesempatan adil untuk berjalan. Proses-proses ini memiliki sifat share-nothing, tiap proses memiliki memorinya sendiri dan tidak ada shared state antara proses. Sebuah proses berkomunikasi dengan proses lain melalui message passing — pengiriman pesan, hanya jika dibutuhkan. Secara teknis, pendekatan ini dikenal dengan istilah actor model.
Bisa ditebak bahwa karakteristik share-nothing tersebut yang membuat paradigma fungsional cocok untuk Erlang. Kita dapat menggunakan fungsi murni yang tidak tergantung pada state. Yang menarik adalah Joe Armstrong, salah satu pencipta bahasa Erlang, mengaku bahwa Erlang tidak didesain sebagai bahasa fungsional. Erlang dibuat dengan tujuan untuk memecahkan masalah konkurensi, dan ternyata pendekatan dengan paradigma fungsional cocok untuk masalah tersebut.
Awalnya, scheduler Erlang berjalan hanya pada satu core. Seiring dengan keluarnya prosesor dengan core lebih dari satu pada komputer untuk konsumer, tidak sulit untuk membuatnya berjalan dengan memanfaatkan semua core yang ada; bahkan tanpa ada penggantian di kode yang kita tulis.
Setelah zaman semakin modern, masalah konkurensi tersebut ternyata tidak unik untuk transaksi telepon. Sebuah web server, contohnya, juga memiliki requirement untuk dapat melayani banyak request dalam suatu waktu. Model konkurensi Erlang sudah terbukti dapat memecahkan masalah tersebut, karena itu pada tahun 2011 José Valim, salah seorang core contributor untuk framework Ruby on Rails, membuat Elixir, sebagai jawaban dari masalah konkurensi yang ia alami saat itu dengan Ruby dan Rails.
Elixir adalah sebuah bahasa pemrograman “fungsional” dengan sintaks yang mirip secara superfisial seperti Ruby, namun dengan kapabilitas penuh platform Erlang untuk pemrograman konkuren dan terdistribusi. Elixir saat ini sedang naik daun dan komunitasnya berkembang sangat pesat; kalau Anda butuh materi untuk dieksplorasi dalam waktu senggang, saya sangat menyarankan untuk mempelajarinya!
Sistem Terdistribusi dan Horizontal Scaling
Saya sering mendengar pertanyaan, “bagaimana cara Facebook meng-handle traffic yang sangat besar?” Kita mungkin pernah mengalami saat-saat di mana suatu situs lokal yang kita kunjungi tidak dapat diakses atau down karena terlalu banyak pengunjung.
Dalam dunia software engineering, skalabilitas merupakan isu yang harus dihadapi oleh aplikasi yang sudah berkembang cukup besar; bagaimana server-server kita tetap hidup meski diterpa begitu banyak request pada waktu bersamaan.
Salah satu solusinya adalah vertical scaling, yaitu melakukan upgrade mesin. Butuh tambahan RAM? Upgrade server ke tipe yang RAM-nya lebih besar. Storage kurang besar? Cari provider lain yang menyediakan server dengan kapasitas lebih besar.
Pendekatan ini bekerja, namun tidak untuk waktu lama. Lambat laun terdapat sebuah “batas” yang menghalangi kita untuk meng-upgrade mesin lebih jauh, baik dari segi fisik maupun harga. Meminta mesin dengan RAM 1TB mungkin akan terdengar main-main. Kalau pun ada, harganya pasti selangit.
Solusi yang lebih murah adalah dengan menambahkan jumlah mesin. Ini disebut horizontal scaling: kita menambah mesin dan mendistribusikan request secara adil ke mesin-mesin tersebut. Alhasil, load untuk masing-masing mesin berkurang, dan dapat di-handle oleh mesin dengan spesifikasi normal.
Namun, horizontal scaling tidak dapat dilakukan sembarangan. Kita harus memastikan bahwa aplikasi kita stateless. Kita tidak ingin pengunjung yang dilayani oleh server A mendapatkan hasil yang berbeda apabila kemudian dilayani oleh server B.
Di sinilah konsep paradigma fungsional untuk manajemen state dan pure function diaplikasikan. Shared state diekstraksi keluar dari kode aplikasi kita, mungkin ke external storage seperti database. Kita dapat melihat proses pelayanan request sebagai fungsi yang hanya melakukan sesuatu berdasarkan masukan dari parameter pada request (URL, header, body dan sebagainya).
Kalau Anda bisa memastikan kode Anda stateless, horizontal scaling akan menjadi sangat mudah dilakukan. Cukup menambahkan mesin, deploy aplikasi Anda ke mesin baru, dan registrasi mesin baru ke load balancer. Anda juga bisa menggunakan teknologi seperti AWS serverless computing yang memiliki fitur autoscaling.
Rekap dan Kesimpulan: Sekarang Apa?
Selamat! Anda telah sampai ke artikel terakhir dari seri Paradigma Pemrograman Fungsional Praktis. Saya sangat menghargainya. Sebuah perjalanan yang panjang!
Kita telah melihat apa yang dimaksud dengan paradigma pemrograman fungsional dan bagaimana pendekatan tersebut bermanfaat untuk kita sebagai developer. Kita juga melihat bagaimana konsep-konsep paradigma fungsional membantu memecahkan masalah-masalah riil di industri.
Saya harap ulasan ini bisa membuat Anda tertarik untuk mencoba-coba melakukan pemrograman dengan bahasa yang berorientasi fungsional. Ada yang mengatakan bahwa mempelajari Haskell, meskipun Anda tidak menggunakannya, akan mengajari Anda banyak hal. Saya sepenuh hati menyetujuinya; ia akan membawa Anda melihat dunia yang belum pernah Anda temui sebelumnya.
Terima kasih saya ucapkan pada Faisal Rahman dan Joshua Bezaleel yang telah bersedia me-review draft awal tulisan seri ini.
Pada post-post berikutnya, saya akan membahas berbagai hal lebih jauh mengenai paradigma fungsional dan teknologi-teknologi yang berputar di dunia pemrograman fungsional. Hal-hal yang menurut saya sangat menarik, dan saya harap Anda juga demikian.
Sampai bertemu pada kesempatan berikutnya!
Berikut navigasi yang Anda bisa gunakan untuk melihat artikel lainnya di seri ini:
- Perkenalan Paradigma Pemrograman Fungsional Praktis
- Pemrograman Deklaratif — Paradigma Fungsional Praktis, Part 1
- Pure Functions dan Efek Samping — Paradigma Fungsional Praktis, Part 2
- Transformasi Data dan Immutability — Paradigma Fungsional Praktis, Part 3
- Higher-order Function — Paradigma Fungsional Praktis, Part 4
- Penerapan Paradigma Fungsional di Industri — Paradigma Fungsional Praktis, Part 5
Apakah Anda menyukai yang Anda baca? Apa saya melewatkan sesuatu? Beritahu saya melalui kolom komentar!
Paradigma Fungsional adalah sebuah blog tentang berbagai hal yang berkaitan dengan paradigma pemrograman fungsional (functional programming) di dunia pengembangan software. Tulisan-tulisan di blog ini akan dimuat dalam Bahasa Indonesia, karena menurut saya resource untuk belajar paradigma fungsional dalam bahasa kita masih sangat kurang.
Apabila Anda tertarik untuk mengetahui lebih lanjut tentang dunia paradigma fungsional, silakan ikuti blog ini!

