DEV Community: Iskandar Rizki

Jalan menuju pemahaman yang lebih baik melalui Elixir - Pemrograman Fungsional

Iskandar Rizki — Sun, 06 Sep 2020 15:34:16 +0000

Dalam mempelajari sebuah bahasa pemrograman, salah satu hal yang penting sebagai modal untuk sukses adalah memiliki motivasi dan alasan mempelajari-nya. Pada suatu proses interview saya pernah ditanya "bagaimana cara meyakinkan seorang programmer untuk mempelajari pemrograman fungsional ?". Terus terang agak kewalahan juga menjawabnya. Karena tidak ada alasan pragmatis untuk meyakinkan seorang programmer untuk mempelajari pemrograman fungsional.

Diantara alasan pragmatis seorang programmer mempelajari bahasa pemrograman yaitu banyak lapangan pekerjaan yang membutuhkan bahasa X, kemudian gaji programmer bahasa X paling tinggi. Dan alasan-alasan pragmatis tadi sepanjang sepengetahuan saya bekerja di Indonesia tidak banyak berlaku bagi seorang programmer fungsional, beberapa yang bekerja sebagai programmer ReactJS mungkin sebagai pengecualian. Sedangkan satu-satunya alasan yang terlintas dalam pikiran saya untuk mempelajari pemrograman fungsional adalah untuk menjadi programmer yang lebih baik.

Alasan untuk menjadi programmer yang lebih baik akan efektif jika seorang programmer telah memiliki pengalaman kurang beruntung dengan konsep OOP (Object Oriented Programming), atau tidak merasa puas dengan konsep OOP. Bukannya konsep OOP tidak bagus, tapi ada sesuatu yang kurang dengan OOP, walaupun konsep design pattern menyempurnakannya, banyak yang mungkin tidak mengadopsinya dan tidak menjadikan design pattern itu wajib diterapkan, dan mungkin ada yang merasa design pattern adalah sesuatu yang over engineered bagi konsep OOP. Jika ada yang merasakan hal yang sama, maka sudah waktunya untuk mencoba paradigma pemrograman lain yaitu pemrograman fungsional.

Pengalaman mencoba beberapa bahasa fungsional seperti Scala, Clojure dan kemudian Elixir, membuat saya merasakan Elixir adalah sebuah bahasa fungsional yang sangat "Down to Earth". Mungkin karena pencipta bahasa Elixir, yaitu Jose Valim memiliki latar belakang dari komunitas Ruby, dimana Ruby selalu mengedepankan "Developer Happiness", sehingga banyak konsep dari Ruby diadopsi ke dalam Elixir. Elixir sendiri adalah bahasa pemrograman yang berjalan diatas Erlang VM.

Kemudian pekan lalu teman dengan latar belakang bahasa Java yang menyatakan, "diantara Python, Golang dan Elixir, Elixir memiliki kurva pembelajaran (learning curve) yang paling tinggi". Hal tersebut sangat wajar sekali, karena diantara ketiga bahasa pemrograman tersebut memiliki paradigma yang berbeda. Python dengan konsep pragmatic OOP dan sedikit konsep fungsionalnya, Golang dengan konsep imperativenya, dipengaruhi dari bahasa C, kedua bahasa ini secara konsep sudah sangat familiar oleh sebagian besar programmer, dan yang berbeda adalah Elixir dengan konsep murni fungsional. Dan yang perlu diingat adalah, ketika melakukan programming dalam Elixir, konsep-konsep bahasa imperative dan OOP, seperti mutable object, konsep class dengan member, inheritance dan lain sebagainya harus juga dilupakan, dan setiap sifat (behaviour) dari bahasa imperative dan OOP tadi pasti ada penggantinya di Elixir. Dan saya akui bahwa dari pernyataan teman inilah yang membuat saya ingin mencoba menceritakan pengalaman dalam mempelajari Elixir.

Dari pengalaman mempelajari Elixir, saya melihat paling tidak ada dua konsep besar yang berperan dalam Elixir, dan bila kedua konsep ini dikuasai, maka saya yakin akan lancar dalam penggunaan bahasa ini. Kedua konsep tadi adalah konsep bahasa fungsional dari Elixir dan konsep Actor dari Erlang VM. Kedua konsep ini saling berperan dalam menciptakan sebuah sistem dengan kehandalan (reliability) yang sangat tinggi. Hal yang mencakup dalam konsep bahasa fungsional ada paling tidak tiga hal yang penting yaitu

immutable objects
declarative programming
higher order function

Pemrograman Fungsional di Elixir

mungkin sudah banyak yang mengenal tentang immutable objects, definisi bebasnya adalah memberlakukan seluruh nilai yang digunakan dalam proses pemrograman sebagai nilai yang tidak dapat diubah dari saat nilai tersebut dibentuk atau dideklarasikan sampai akhir masa berlakunya nilai tersebut.
Untuk mempermudah pemahaman tentang immutable objects ini saya coba analogikan semua nilai immutable adalah data. Seperti kita tahu, data bersifat konstan dan merupakan fakta yang tidak berubah. Contoh data adalah "curah hujan di tanggal 5 September 2020", merupakan sebuah data yang nilainya tetap dan merupakan sebuah fakta.
Programmer tidak bisa mengubah fakta tentang "curah hujan" di tanggal tersebut, tetapi yang bisa dilakukan adalah membuat data baru dari fakta tersebut. Dari banyak data di tanggal-tanggal bulan September, programmer dapat membuat data baru misalnya "rata-rata curah hujan di bulan September".
Jadi demikian dianalogikan, bahwa jika seorang programmer menginginkan sebuah nilai yang dibutuhkan, programmer dapat membangun nilai baru tersebut dari kumpulan data-data atau nilai-nilai lain yang telah tersedia.
Apa keuntungan menggunakan immutable objects ini ? Dalam concurrency programming seperti multi-threading atau multi-processing, seorang programmer tidak membutuhkan mutex atau mekanisme resource locking, karena semua nilai yang digunakan adalah read only, tiap thread bebas melakukan pembacaan pada nilai tersebut. Sehingga dengan immutability memastikan kondisi thread-safe dan memory-safe pada program.
seperti namanya declarative programming adalah kebalikan dari imperative programming. Dimana dalam imperative programming, seorang programmer secara eksplisit menuliskan semua perintah kepada program untuk menjalankan langkah-langkah yang harus dilakukan, pada declarative programming, tidak semua langkah-langkah harus diberikan secara eksplisit dari programmer pada program, hanya bagian yang penting saja perlu dituliskan pada program, hal yang bukan bagian penting telah didelegasikan kepada fungsi lain. Untuk lebih jelasnya berikut adalah contoh dari imperative programming,

Dari contoh imperative programming diatas jelas terlihat setiap langkah diberikan instruksi oleh programmer, mulai dari inisialisasi nilai total, sampai proses looping diberikan secara detil langkah pengerjaannya. Bandingkan dengan declarative programming,

Terlihat dari contoh diatas proses looping telah didelegasikan kepada fungsi Enum.reduce, secara implementasi programmer tidak tahu apakah looping yang dilakukan dari index terkecil atau terbesar, semua terserah implementasi fungsi Enum.reduce. Yang programmer lakukan hanya menentukan nilai inisialisasi seperti apa yang diinginkan dan apa yang harus dilakukan untuk nilai tiap item member, dimana nilai tiap item member ditambahkan dengan nilai total item sebelumnya yang disimpan dalam accumulator (acc). Apa keuntungannya jika programmer mengadopsi declarative programming ini ? Tentu saja kode yang dihasilkan akan lebih jelas dan ringkas (clear and concise), karena sebagian besar kode yang digunakan adalah fungsi yang telah dipercayakan pasti berjalan dengan baik dan benar, yang berasal dari bahasa Elixir itu sendiri maupun ekosistemnya. Dan tentu saja dapat memperkecil kecenderungan terjadinya kesalahan (error prone) pada program.
higher order function adalah sebuah konsep dimana setiap input dan output pada sebuah proses bukan hanya nilai tapi dapat berupa fungsi. Hal ini yang menyebabkan fungsi adalah sebuah bagian yang terpenting dari bahasa pemrograman Elixir. Contoh input output dapat berupa fungsi adalah sebagai berikut,

Dapat dilihat pada contoh diatas, reduce_func merupakan sebuah pointer menuju fungsi. Dimana pointer ini dapat diberlakukan sebagai input maupun output. Pada fungsi anonim anon2 terlihat bahwa pointer fungsi reduce_func adalah output dari fungsi anon2. Pada fungsi anon2 juga terlihat bahwa anon1 merupakan input dari reduce_func. Terlihat pada bahasa Elixir pointer menuju fungsi ini dapat diberlakukan sebagai input maupun output. Sedikit tambahan variasi penulisan pointer menuju fungsi, juga dapat berbentuk seperti dibawah,

Diatas terlihat bahwa fungsi anonim anon1 dapat digantikan dengan sintaks &(&2+&1*&1), untuk meringkaskan penulisan kode, tapi sedikit mengorbankan clarity atau kejelasan dari kode. Dengan higher-order function ini keuntungannya adalah keseluruhan program yang dibangun dari banyak fungsi-fungsi yang lebih kecil dibawahnya, sehingga dengan konsep ini dapat dibangun sebuah sistem yang memenuhi prinsip composability.

Selain ketiga konsep diatas, masih ada fitur-fitur bahasa Elixir yang merupakan variasi-variasi dari pemrograman fungsional, diantaranya adalah pipe operator (|>), konsep matching operator (=) dan pattern matching, pin operator (^), protocols, railway oriented programming, dan masih banyak lainnya.

Jika dipelajari lebih lanjut, maka akan terlihat sebenarnya konsep pemrograman fungsional adalah sebuah konsep yang cukup familiar di antara programmer, tetapi hanya diperlukan pembiasaan dan menanamkan mindset dari konsep-konsep pemrograman fungsional diatas. Untuk konsep pemrograman fungsional mungkin sampai disini dulu, untuk artikel yang berikutnya akan dibahas tentang pemrograman aktor di Elixir. Terima kasih.

Web FullStack menggunakan Phoenix LiveView - Publisher Subscriber

Iskandar Rizki — Mon, 24 Aug 2020 07:08:47 +0000

Ini merupakan bagian akhir dari seri Web FullStack menggunakan Phoenix LiveView. Pada bagian akhir ini akan coba diimplementasikan mekanisme Publisher Subscriber, atau yang sering disebut dengan PubSub. PubSub adalah sebuah mekanisme yang bertujuan untuk saling berkomunikasinya antara proses atau dalam konteks erlang/elixir adalah actor, baik itu dalam satu host/mesin atau berlainan host. Perlu diketahui bahwa proses PubSub ini bersifat asynchronous, atau semua proses publish atau subscribe tidak ada actor / proses yang harus menunggu hingga proses publish atau subscribe ini selesai dijalankan.

Kemudian menjadi pertanyaan adalah untuk apa mengimplementasikan PubSub pada sebuah implementasi web aplikasi ? Untuk lebih jelas mungkin bisa melihat video ilustrasi dibawah, dimana terdapat 2 browser yang membuka halaman yang sama, perubahan di suatu halaman, dapat membuat halaman lainnya berubah pula. Bagaimana agar halaman browser lain tadi bisa ikut berubah jika terjadi perubahan pada suatu halaman dengan browser berbeda ? Salah satu caranya adalah dengan mekanisme PubSub.

Mungkin banyak yang sudah mengenal implementasi PubSub ini menggunakan tools seperti rabbitmq, redis atau kafka. Dalam Phoenix framework salah satu implementasi PubSub adalah dengan menggunakan Distributed Erlang, dimana implementasi ini sudah built-in di dalam Elixir, sehingga tidak perlu melakukan maintain software atau stack lainnya. Seperti apa cara kerja dari PubSub dalam Phoenix framework ? Berikut adalah ilustrasinya

Sebagai contoh adalah ketika ada permintaan "Add Todo" yang datang ke browser, permintaan "Add Todo" ini akan dikirimkan melalui komunikasi LiveView kepada sebuah Actor. Actor ini akan memproses permintaan "Add Todo" dan hasilnya akan di publish sebagai sebuah "event" (kejadian) dalam sebuah topik. Topik ini merupakan sebuah scope atau lingkup dimana beberapa "event-event" akan dipublish. Jika tadi sudah dijelaskan bahwa ada Actor yang akan melakukan publish event dalam topik, ada pula Actor yang akan melakukan subscribe ke dalam topik, yang nantinya akan menerima "event-event" yang di publish. Actor-actor yang melakukan subscribe ini kemudian akan meneruskan "event" yang diterima dari publisher ke LiveView agar tampilan dari browser dapat diupdate sesuai dengan data yang diterima.

Bagaimana mengimplementasikan PubSub ini pada halaman Todo ? Berikut kodenya yang ditambahkan pada file 'lib/liveview_todo_web/live/todo_live.ex'.

Bagian yang ditambahkan adalah kode Phoenix.PubSub.subscribe(LiveviewTodo.PubSub, @topic, link: true) dan Phoenix.PubSub.broadcast(LiveviewTodo.PubSub, @topic, {"new_todo_event", new_todo}). Dimana kedua fungsi ini berguna berturut-turut untuk melakukan subscribe terhadap sebuah topik (@topic yang bernilai "live_todo") dan melakukan publish yang akan mem-broadcast atau menyiarkan jika terjadi sebuah "event", pada broadcast tersebut contoh "event" adalah ketika terjadi "Add Todo" maka akan menghasilkan event "new_todo_event", dengan mengirimkan data "new_todo" ke setiap subscriber.

Pada file tersebut juga ditambahkan fungsi handle_info({"delete_todo_event", todo} = _info, socket) dan handle_info({_event, todo} = _info, socket) dimana berturut-turut kedua fungsi tersebut adalah sebagai fungsi penampung dari event "delete_todo_event" dan sisa event lainnya yaitu "new_todo_event" dan "update_todo_event". Dan di masing-masing fungsi ini hanya terdapat 1 pemanggilan fungsi saja, berturut-turut adalah fungsi push_event dan assign. Fungsi push_event seperti yang telah dijelaskan pada artikel sebelumnya, berguna untuk mentrigger JS Interop yang akan menghapus tampilan data todo pada browser. Sedangkan fungsi assign berfungsi untuk melakukan update terdapat state LiveView yang berisi data todo, yang kemudian akan berefek mengubah halaman web LiveView yang dikendalikan oleh actor yang menerima "event" dari publisher atau broadcaster.

Untuk mencoba implementasi PubSub ini, jangan lupa untuk melakukan pengecekan pada file 'lib/liveview_todo/application.ex', apakah Phoenix.PubSub sudah masuk sebagai child actor. Berikut contoh isi file 'application.ex'

Yakinkan terdapat baris berikut pada application.ex tersebut {Phoenix.PubSub, name: LiveviewTodo.PubSub}, baris tersebut akan menambahkan Phoenix.PubSub sebagai child actor dari aplikasi. Untuk langsung melihat kodenya, silahkan clone atau fork github repo berikut https://github.com/rizki96/liveview_todo.

Sudah diterangkan pada artikel-artikel sebelumnya bagaimana dengan Elixir khususnya Phoenix framework dapat membangun suatu aplikasi web yang bersifat realtime. Dimana jika terjadi perubahan data di server, secara instan dan cepat, semua client browsernya dapat juga menerima perubahan datanya. Semua ini dapat dibangun dengan sebuah ekosistem yang lengkap secara fungsi, boleh dikatakan Erlang/Elixir adalah sebuah arsitektur yang memiliki sifat "One Size Fits All Architecture" dimana semua kebutuhan untuk membangun aplikasi realtime dapat dipenuhi oleh ekosistemnya. Mulai dari database, websocket, pubsub, cache, queue dan lain sebagainya. Jika ada kebutuhan untuk mengadopsi solusi yang lebih handal, baru kemudian solusi itu akan diadopsi, misalnya fungsi database digantikan dengan postgresql, mysql dan lainnya.

Demikian telah coba dibawakan artikel-artikel mengenai Web FullStack menggunakan Phoenix LiveView. Dimana artikel-artikel ini adalah cara saya agar dapat mempelajari lebih dalam mengenai Elixir dan ekosistemnya. Karena bagi saya banyak sekali hal yang baru dari Erlang/Elixir ini mulai dari konsep pemrograman hingga konsep arsitekturnya, sehingga lebih terbuka mengenai berbagai hal seperti functional programming, concurrencies, process communication, bahkan sedikit konsep mengenai microservice. Mudah-mudahan bisa bermanfaat juga untuk yang lainnya. Terima kasih.

Web FullStack menggunakan Phoenix LiveView - Javascript Interoperability

Iskandar Rizki — Sun, 16 Aug 2020 16:35:53 +0000

Bagian ketiga dari Web FullStack menggunakan Phoenix LiveView akan membahas tentang Javascript Interoperability. Apa itu Javascript Interoperability atau lebih dikenal dengan JS Interop pada LiveView ? Seperti artinya JS Interop adalah suatu mekanisme untuk menggunakan kode Javascript dalam keseluruhan siklus LiveView. Seperti pada tujuan didesain-nya LiveView adalah bukan meniadakan fungsi Javascript pada kode yang dibangun, tetapi tujuan LiveView adalah meminimalkan penggunaan Javascript pada kode framework Phoenix. Pada akhirnya cepat atau lambat mekanisme JS Interop ini akan digunakan pada kode framework Phoenix, karena pada akhirnya kita membutuhkan solusi custom ataupun solusi yang lebih advance dari Javascript, jika kebutuhan dari aplikasi mengharuskan hal tersebut.

Untuk melihat bagaimana penggunaan JS Interop, mari kita coba implementasikan fungsi hapus data sebagai bagian dari CRUD dari aplikasi Todo yang telah diimplementasikan sebelumnya. Sebelum masuk ke JS Interop, akan dibandingkan juga implementasi hapus ini jika tanpa menggunakan JS Interop. Seperti biasa, untuk memudahkan dan mempercepat pemahaman, sebelumnya silahkan clone atau fork github repo berikut https://github.com/rizki96/liveview_todo.

Solusi penghapusan tanpa JS Interop

Solusi tanpa JS Interop merupakan solusi yang paling mudah untuk dilakukan. Pertama adalah tambahkan informasi pada file 'lib/liveview_todo_web/router.ex', sehingga terdapat link untuk melakukan penghapusan atau delete pada endpoint '/todo'. Berikut contoh penggalan kode dari router.ex

Saat ini artinya module TodoLive telah memiliki endpoint :delete. Sehingga file 'lib/liveview_todo_web/live/components/todos/todo_list_item.ex' dapat ditambahkan salah satu fungsi link html untuk liveview yaitu live_redirect untuk melakukan operasi penghapusan. Berikut isi file 'todo_list_item.ex' yang terbaru

Terlihat dari fungsi live_redirect, link tersebut akan membawa menuju ke Routes.live_path(@socket, TodoLive, [id: @todo.id, action: :delete]), replace: false), Routes.live_path ini merupakan representasi dari link '/todo' yang ada pada file 'router.ex', yang kemudian akan di render oleh browser sebagai '/todo?id={id}&action=delete'. Dan dari router live_path tersebut, client akan dibawa ke fungsi handle_params pada module TodoLive. Seterusnya module TodoLive akan berbentuk sebagai berikut

Maka setelah semua kode tersebut terpasang, maka penghapusan sudah bisa dilakukan. Tetapi ada hal yang perlu diingat dari kode diatas. Yaitu jika dilihat pada bagian '# versi tanpa JS Interop' setelah handle_params melakukan penghapusan terhadap data todo, maka semua data kembali akan di fetch dari database dengan fungsi {:ok, todos} = Tasks.list_todos() dan state dari todos akan di assign ulang. Hal ini tentu akan menimbulkan bottle neck jika jumlah data todo yang di fetch cukup signifikan. Untuk menghindari hal tersebut, yang perlu dilakukan adalah mengganti operasi fetch data tadi dengan operasi pengiriman event ke client browser dalam hal ini ke Javascript, sehingga nanti Javascript yang akan melakukan penghapusan todo item, tanpa perlu melakukan fetch data dan mengirimkan data ke client browser. Hal tersebut akan coba dijelaskan pada bagian berikutnya yaitu solusi menggunakan JS Interop. Dan berikut adalah ilustrasi pengiriman data dari server ke client dengan solusi tanpa JS Interop.

Solusi penghapusan dengan JS Interop

Sebelumnya perlu diketahui bahwa JS Interop merupakan sebuah siklus berupa fungsi callback yang terjadi pada sebuah LiveView Component. Siklus tersebut terdiri dari fungsi mounted, beforeUpdate, updated, beforeDestroy, destroyed dan lainnya, untuk lebih jelas tentang siklusnya bisa dilihat pada link ini.

Disebabkan karena yang akan melakukan penghapusan ada pada elemen list, maka akan diimplementasikan JS Interop ini pada LiveView Component 'todo_list.ex' pada direktori 'lib/liveview_todo_web/live/components/todos'. Untuk memulai mari buat sebuah file javascript yang berfungsi sebagai hook, pada direktori 'assets/js' dengan nama file 'todo_list_hook.js'. Berikut isi dari file 'todo_list_hook.js'

Kemudian lakukan modifikasi pada file 'app.js' pada direktori 'assets/js', dimana file Javascript ini yang akan dimuat (load) untuk pertama kali pada client browser. Berikut isi dari file 'app.js'

Dari kode diatas terlihat object hook TodoListHook di-import dan kemudian diteruskan ke dalam object LiveSocket. Setelah ini dibutuhkan melakukan modifikasi file berturut-turut yaitu 'todo_list.ex', 'todo_list_item.ex' dan 'todo_live.ex'. Pada file 'todo_list.ex' yang akan ditambahkan adalah tag phx-hook dengan nilai 'TodoListHook' (phx-hook='TodoListHook'). Sehingga isi file 'todo_list.ex' akan berbentuk

Pada file 'todo_list_item.ex' akan diubah fungsi 'live_redirect' menjadi 'live_patch'. Perbedaan 'live_redirect' dan 'live_patch' adalah pada 'live_redirect', phoenix yang akan menangani redirecting / pengarahan ke konten liveview yang baru dengan assign state yang baru. Pada 'live_patch' hal tersebut tidak dilakukan, semua operasi tersebut akan ditangani oleh Javascript. 'live_patch' hanya akan mengirimkan event ke handle_params. Berikut isi dari file 'todo_list_item.ex'

Bagaimana file 'todo_live.ex' ? Bagian yang dibutuhkan untuk dimodifikasi adalah bagian handle_params. Berikut isi dari file 'todo_live.ex' setelah dimodifikasi

Seperti bisa dilihat pada kode diatas, setelah penghapusan data operasi yang dilakukan adalah pengiriman event oleh fungsi 'push_event'. Event ini akan ditangkap oleh 'TodoListHook' pada file 'assets/js/todo_list_hook.js' di bagian 'this.handleEvent' yang kemudian akan menghapus element data todo yang bersangkutan pada LiveView Component 'todo_list.ex'. Sebagai bahan perbandingan, berikut informasi yang dikirim dari server ke client browser, jika menggunakan JS Interop. Data yang dikirim hanya informasi event dan todo data dari object yang telah dihapus di server. Dan terlihat dengan JS Interop ini akan mengefisienkan pengiriman data dari server ke client browser.

Dan terakhir, perlu diketahui bahwa dengan JS Interop ini dimungkinkan untuk LiveView berinteraksi dengan framework Javascript lain, seperti JQuery, React, Vue.js dan lain sebagainya. Demikian sekilas mengenai JS Interop pada Phoenix LiveView, mudah-mudahan bisa bermanfaat. Terima kasih.

Web FullStack menggunakan Phoenix LiveView - Membangun Operasi CRUD

Iskandar Rizki — Sun, 09 Aug 2020 15:10:46 +0000

Dalam artikel kali ini akan coba dibawakan bagaimana mengimplementasikan CRUD (Create Read Update Delete) dalam Phoenix Liveview. Untuk kemudahan dan bisa memulai dengan cepat, bisa langsung melakukan git clone atau fork dari github repo berikut https://github.com/rizki96/liveview_todo.git.

Perlu diketahui, database yang digunakan kali ini adalah CubDB. Sedikit tentang CubDB, database ini adalah embedded key value database, dimana mekanisme penyimpanan datanya berlaku Copy On Write (COW) atau append only database untuk menjaga konsistensi data. Mekanisme ini berbeda dengan sqlite yang menggunakan mekanisme file locking. Dari mekanisme ini memungkinkan CubDB untuk disimpan dalam remote file system, seperti AWS S3 fuse mount atau google cloud storage fuse mount, atau file system seperti NFS maupun SMB. Karena dengan solusi remote file system biasanya fitur file locking tidak dijamin, sehingga tidak dimungkinkan sqlite berjalan dengan benar.

Untuk memulai mari kita bangun dulu interface untuk pengaksesan database CubDB. Interface ini akan disimpan dalam sebuah module elixir dalam file 'lib/liveview_todo/kv_store.ex'. Berikut isi dari file kv_store.ex

Module elixir ini pada hakikatnya adalah sebuah supervisor actor yang akan menjalankan worker engine dari CubDB. Worker engine tentunya akan dijalankan pada saat aplikasi dimulai, oleh sebab itu tambahkan module LiveviewTodo.KvStore ke dalam children supervisor, sebagai contoh nya adalah penggalan berikut pada file 'lib/liveview_todo/application.ex'

Kemudian terdapat 2 bagian besar dari module LiveviewTodo.KvStore, yaitu bagian dari MetaRecord dan bagian dari record data aplikasi. MetaRecord berisi informasi id yang terakhir di tulis dalam sebuah record data. Informasi mengenai record data ini disimpan dalam bentuk key, yang berisi nama tabel dan id. Dan record yang berisi value adalah informasi lengkap dari record data tersebut. Contoh adalah table todos, dengan record id 1, maka key-nya akan berisi {:todos, 1}.

Data file dari CubDB sendiri akan disimpan dalam config.exs, dimana path dari file ini akan dibaca oleh module file 'kv_store.ex' tersebut. Berikut sebagian isi dari 'config.exs' tempat penyimpanan data file dari CubDB

Phoenix framework sendiri mengenal konsep Context, dimana 'kv_store.ex' sebagai interface database tidak diperbolehkan untuk diakses langsung oleh aplikasi, tetapi harus melalui konsep Context ini. Untuk tiap aplikasi berbeda akan memiliki Context yang berbeda sesuai dengan domain aplikasi yang bersangkutan. Context aplikasi ini disimpan dalam module file 'lib/liveview_todo/tasks.ex' dimana dalam module ini terdapat query dan command yang akan diakses oleh aplikasi. Berikut isi dari module Context Tasks

Dalam Context Tasks ini terdapat CRUD module yang akan digunakan oleh aplikasi LiveView. Bagaimana penggunaan CRUD ini dalam LiveView ? Berikut module liveview yang telah dibuat pada artikel sebelumnya yaitu 'todo_live.ex', dengan ditambahkan fungsi list_todos untuk menampilkan semua data Todo.

Jika diperhatikan ada beberapa operasi pattern matching dalam kode ini. Seperti misalnya {:ok, todos} = Tasks.list_todos(), Dalam Elixir operator '=' bukan hanya berlaku sebagai assignment tapi juga sebagai match operator. Dimana match operator akan melakukan pencocokan antara sisi kiri dan kanan dari operasi '='. Kemudian dalam Phoenix (tidak hanya LiveView) dikenal perintah assign, contohnya adalah socket = assign(socket, todos: todos), perintah ini berfungsi untuk merubah state socket yang berisi variable yang dapat diakses dalam halaman HTML yang di render oleh LiveView. Dalam halaman HTML tersebut variable yang di assign dalam socket, seperti todos akan dikenal sebagai '@todos'. Dalam kode ini juga digunakan temporary_assigns seperti pada {:ok, assign(socket, temporary_assigns: [todos: []])}. temporary_assigns akan memberlakukan variable todos sebagai nilai sementara agar pada event berikutnya tidak dikirim semua data lagi ke halaman HTML LiveView. Fitur temporary_assigns ini yang akan membuat pengiriman data antara backend dan frontend menjadi efisien, karena semua data hanya akan dikirim sekali ketika event mount. Event berikutnya hanya data yang berubah saja yang akan dikirimkan. Perlu diketahui juga, data todos yang dikirim ke halaman HTML, ini secara otomatis akan di serialisasi kan sebagai data JSON, karena dalam module Tasks sebelumnya, module struct Todo telah ditambahkan line berikut : @derive {Jason.Encoder, only: [:id, :text, :completed]} , baris ini yang akan membuat framework Phoenix menginterpretasikan struct Todo menjadi JSON jika dibutuhkan, dan hanya field-field yang terpilih saja akan disertakan sebagai JSON object.

Kemudian bagaimana untuk menampilkan query list_todos ini dalam HTML ? Untuk itu mari kita buat LiveView Component yang berisi HTML dengan item-item 'todos'. Seperti sebelumnya buat Component dalam direktori 'lib/liveview_todo_web/live/components/todos' dengan nama file 'todo_list.ex' dan 'todo_list_item.ex'. Berturut-turut file tersebut berfungsi sebagai renderer untuk list of todos dan item todo. Berikut berturut-turut isi dari 'todo_list.ex' dan 'todo_list_item.ex'

Untuk mengetahui Component tersebut berfungsi, diharuskan untuk menambahkan Component tersebut ke halaman utama dari LiveView todo_live.html.leex. Sehingga halaman todo_live.html.leex akan berisi seperti berikut

Tentu saja setelah ini harus ditambahkan juga fungsi untuk melakukan penambahan dan pengubahan data ke dalam database. Sehingga file 'todo_live.ex' akan ditambahkan event untuk melakukan add dan update. Berikut ini isi dari 'todo_live.ex'

Dalam event yang akan di trigger dari halaman HTML pun mengenal pattern matching. Contohnya adalah baris 'def handle_event("add_todo", %{"todo" => todo} = _params, socket) do' dan 'def handle_event("update_todo:" <> todo_id, params, socket) do'. Parameter pada baris sebelumnya yaitu '%{"todo" => todo} = _params', params yang dikirim ke dalam event kita pattern match sebagai tipe map dan dilakukan ekstraksi terhadap nilai dalam map tersebut. Sedangkan params secara keseluruhan akan diabaikan dengan menambahkan '_' di depan nama variablenya. Begitu juga pada baris event berikutnya, "update_todo:" <> todo_id merupakan sebuah pattern match. Yang dilakukan disini adalah ekstraksi string untuk mendapatkan bagian yang dinginkan. Misalnya secara keseluruhan string nya adalah "update_todo:2" maka variable todo_id akan bernilai string '2'. Oleh sebab itu pattern matching adalah salah satu kekuatan dari bahasa Elixir untuk membuat kode lebih jelas dan ringkas.

Setelah fungsi add dan update, jalankan 'mix phx.server' untuk menjalankan phoenix web server dan akses ke halaman 'http://localhost:4000/todo'. Coba untuk menambahkan todo, misalnya adalah 'testing 1'. Maka akan terlihat seperti berikut ini

Bagaimana cara untuk melihat data yang dipertukarkan antara frontend dan backend dalam LiveView ? Buka bagian developer inspect element pada browser, kemudian pada bagian console javascript jalankan perintah liveSocket.enableDebug(). Berikut ini contoh gambarnya

Setelah itu coba untuk melakukan update dan akan terlihat hanya data yang berubah saja akan dikirim ke backend server. Contoh adalah sebagai berikut

Kemudian jika ditambahkan data todo berikutnya akan terlihat data baru ditambahkan pada element terakhir dari list_todo dan semua item todo terurut dari item todo yang lama ke item todo yang baru. Hal ini dimungkinkan dengan fitur DOM patching dari phoenix LiveView, dimana pada element list ditambahkan attribute phx-update="append". Bagaimana bila dibutuhkan sebaliknya ? data yang ditambahkan selalu berada diatas dan akan berurutan terbalik dari item todo yang baru ke item todo yang lama ? Caranya cukup mudah, yaitu ubah query list_todos menjadi reverse=true, query ini terdapat pada Context Tasks dan ubah nilai phx-update pada Component 'list_item.ex' menjadi phx-update="prepend". Maka ketika data ditambahkan todo akan terlihat seperti gambar dibawah

Bagaimana jika kita ingin menampilkan lebih Custom dari pada hanya sekedar append dan prepend. Jawabannya adalah gunakan JS Interop Hooks dalam LiveView.

Demikian bagian ke 2 dari artikel membangun web fullstack dengan menggunakan Phoenix LiveView, untuk JS Interop Hooks silahkan dicoba sebagai sebuah latihan, dan bisa dicoba juga untuk menambahkan fitur hapus. Terima kasih telah membaca artikel ini dan kemudian mencoba Phoenix LiveView, semoga lancar dan jika ada kritik, saran atau pertanyaan dapat langsung kontak melalui linkedin atau twitter di @rizki.

Web FullStack menggunakan Phoenix LiveView - Memulai Pembangunan

Iskandar Rizki — Fri, 31 Jul 2020 09:38:35 +0000

Banyak dari web developer saat ini menggunakan teknologi frontend seperti diantaranya ReactJS, AngularJS dan VueJS yang dipadukan dengan RESTful framework, GraphQL atau menggunakan teknologi seperti websocket untuk berinteraksi dengan backend service. Terkadang solusi ReactJS, AngularJS atau frontend framework lainnya terlalu kompleks jika hanya ditujukan untuk komunikasi dengan backend, tanpa misalnya penggunaan fitur Offline First atau fitur lain yang memungkinkan berjalan mandiri tanpa backend service. Terlebih bila backend service berbeda bahasa pemrograman dengan frontend, dikhawatirkan terjadi gap atau pemisah diatara keduanya.

Untuk pengguna Elixir ada pilihan yang menarik untuk melakukan pembangunan Web Fullstack sehingga tidak terjadi gap atau pemisah antara frontend hingga backend, yaitu dengan menggunakan framework Phoenix LiveView. Apa yang menjadi kelebihan Phoenix framework dengan LiveView ini untuk Web Fullstack ? Phoenix framework seperti pada web framework lainnya membawakan konsep MVC, memiliki gaya development mengikuti framework Ruby on Rails, yang membawa konsep convention over configuration dimana banyak aturan telah disepakati pada permulaan konsep framework dibangun, code generator atau scaffolding untuk meminimalisir kesalahan dan memudahkan developer untuk memulai pembangunan. Sedangkan kelebihan LiveView untuk Web Fullstack dibandingkan menggunakan teknologi lain adalah,

Kode yang dibangun di dominasi dengan kode Elixir dan HTML, meminimalisir penggunaan Javascript, Javascript tetap digunakan hanya pada kondisi siklus callback tertentu, yang telah ditetapkan oleh LiveView. Pada LiveView mekanisme ini dikenal dengan istilah Javascript Hooks.
Komunikasi antara Frontend dan Backend sangat alami dan seamless (tanpa ada penghalang/barrier dan gap), tidak memerlukan kode http client atau websocket client di sisi Frontend, atau membangun RESTFul endpoint di sisi Backend. Karena tiap perubahan object dan event yang terjadi baik di frontend dan backend bisa langsung saling diakses oleh kedua pihak frontend dan backend tersebut.
Pertukaran data antara Frontend dan Backend dapat diminimalkan, dengan mekanisme DOM patching dan temporary assigns data yang dikirim dari server ke frontend minimal hanya terbatas DOM element yang berubah nilainya pada browser, begitu juga dari frontend ke server hanya data yang berasal dari DOM element yang terjadi event saja datanya akan dikirimkan.

Seperti apa proses pembangunan framework Phoenix LiveView ? Mari simak berikut ini.

Untuk memulai dibutuhkan Erlang OTP minimal versi 21, Elixir minimal versi 1.9 dan NodeJS versi 12 (membutuhkan NPM), cara instalasi erlang & elixir diberbagai platform bisa lihat disini https://elixir-lang.org/install.html.
Setelah erlang dan elixir terinstall, pastikan perintah 'mix' telah terinstall, coba dengan menjalankan 'mix help'
install phoenix framework 'mix archive.install hex phx_new 1.5.4'
buat project baru 'mix phx.new liveview_todo --no-dashboard --no-ecto --live'
cd liveview_todo
edit file mix.exs, ubah bagian '{:phoenix_live_view, "~> 0.13.0"}' menjadi '{:phoenix_live_view, "~> 0.14.0"}'
Menggunakan database CUBDB, edit file mix.exs, tambahkan '{:cubdb, "~> 1.0.0-rc.4"},' dibaris terakhir sesudah '{:plug_cowboy, "~> 2.0"}', hasil akhir seperti ini

mix deps.get
cd assets && npm install && node node_modules/webpack/bin/webpack.js --mode development && cd ..
mix compile
mencoba untuk menjalankan web server 'mix phx.server' dan akses alamat 'http://localhost:4000' pada browser

Setelah semuanya berjalan baik dan webserver bisa dijalankan, mari kita mulai membuat kode liveview. Paling tidak ada 2 pendekatan untuk memulai kode liveview, yaitu dengan menggunakan scaffolding dan dengan cara manual membuat file dengan akhiran '_live.ex'. Sayangnya dengan cara scaffolding sangat erat berintegrasi dengan library Ecto (membutuhkan postgresql, mysql atau SQL Server), kita menggunakan cara ke 2 yaitu secara manual membuat file dengan akhiran '_live.ex'. Langsung saja kita buat file baru dengan nama 'todo_live.ex' pada direktori 'lib/liveview_todo_web/live', dan proses ini berlaku suatu konvensi atau perjanjian bahwa untuk membuat file html yang akan digunakan oleh 'todo_live.ex', developer hanya butuh membuat sebuah file lagi yaitu 'todo_live.html.leex'. Hal ini mengikuti konsep convention over configuration, dimana banyak hal sudah ditentukan / disepakati dari permulaan tentang aturan-aturan yang berlaku di framework. Hasil akhir seperti gambar dibawah.

Untuk mencoba apakah halaman liveview bisa diakses, dibutuhkan minimal kode seperti berikut pada file 'todo_live.ex'.

Dan untuk mencoba apakah halaman 'todo_live.html.leex' dapat bekerja dengan benar, coba untuk memasukkan kode html sebagai berikut.

Dan tambahkan juga pada file 'router.ex' URL yang akan dipetakan ke file 'todo_live.ex'. File 'router.ex' terdapat pada direktori 'lib/liveview_todo_web'. Tambahkan line: 'live "/todo", TodoLive, :index', seperti berikut ini.

Jika masih menjalankan 'mix phx.server', coba akses dengan browser ke halaman 'http://localhost:4000/todo', maka akan muncul halaman seperti berikut.

Seperti juga ReactJS dan framework frontend lainnya, LiveView juga memiliki konsep Component. Component adalah sebuah cara / metode melakukan pemecahan element User Interface agar nantinya dapat dipergunakan ulang di halaman lain (Reuse) dan diharapkan dengan Component ini juga akan lebih efisien dalam pertukaran data antara browser dan server, dimana static Component dapat diberlakukan mekanisme cache pada browser. Berikut cara membangun Component pada LiveView. Pertama tentukan dimana Component akan ditempatkan pada project. Kali ini akan diberikan tempat pada direktori 'lib/liveview_todo_web/live' dengan membuat direktori baru yaitu 'components'. Dan tambahkan juga direktori 'todos' ke dalam direktori 'components'. Sehingga akan terlihat seperti dibawah.

Dan tambahkan juga Component pertama kita dengan membuat file 'add_todo_form.ex' di dalam direktori 'todos'. Akan terlihat seperti dibawah.

Dalam file 'add_todo_form.ex' tambahkan kode seperti dibawah ini.

Untuk menggunakan Component 'add_todo_form.ex', bisa mulai menambahkan Component tersebut ke dalam file 'todo_live.html.leex' dan menambahkan baris 'alias LiveviewTodoWeb.Todos.AddTodoFormComponent' ke dalam file 'todo_live.ex'. Sehingga file 'todo_live.ex' dan 'todo_live.html.leex' yang terbaru akan berbentuk seperti dibawah ini.

Dan jika halaman 'http://localhost:4000/todo' diakses dari browser, akan muncul Component 'add_todo_form.ex' yang telah dibuat tadi.

Setelah ini bagaimana mengirimkan informasi event yang akan dikirim ke server, misalnya ketika tombol 'Add Todo' diklik ? Caranya cukup mudah, ada 2 langkah yang harus dilakukan, yaitu

menambahkan kode: '[phx_submit: :add_todo]' di dalam Component 'add_todo_form.ex', sehingga akan berbentuk seperti dibawah ini.
menambahkan kode event handler "add_todo" pada file 'todo_live.ex', seperti dibawah ini.

Apabila dicoba untuk memasukkan kata 'testing' dari halaman 'http://localhost:4000/todo' ke dalam input text dan kemudian klik tombol 'Add Todo', maka pada log server akan muncul '[debug] %{"text" => "testing"}'. Artinya event yang dikirimkan dari browser telah berhasil dikirim dan ditampilkan pada log yang terdapat di server.

Demikian bagian pertama dari pengenalan mengenai Phoenix LiveView. Untuk lebih lengkapnya, repositori tutorial ini dapat diakses melalui https://github.com/rizki96/liveview_todo. Dan nanti pada bagian berikutnya akan coba dijelaskan mengenai proses penambahan data, update data dan hal-hal yang berhubungan dengan database, dan bagaimana melakukan pengiriman data yang efisien dengan mekanisme Phoenix LiveView ini.

Berbagai alasan melakukan Programming dalam Rust

Iskandar Rizki — Sat, 06 Jun 2020 15:45:39 +0000

Baru saja membaca artikel tentang Rust sebagai bahasa pemrograman yang dicintai, membuat saya terpancing untuk menulis artikel tentang Rust. Pengalaman menggunakan bahasa pemrograman Rust ini adalah ketika membuat wrapper Phoenix Channels client dalam Python untuk kebutuhan salah satu Python project. Seperti juga C/C++, Rust memiliki native binding dengan Python melalui pyo3 atau melalui FFI. Dengan pyo3 melakukan native binding antara Python dan Rust atau sebaliknya menjadi mudah.

Bukan hanya native binding saja, berbagai alasan mengapa Rust akan menjadi sebuah pilihan bahasa pemrograman yang populer, setelah Google mengeluarkan laporan bahwa 70 % masalah keamanan dalam program adalah memory safety, kemudian Microsoft mengeluarkan laporan yang sama. Membuat masa depan Rust menjadi sangat jelas mengapa bahasa pemrograman ini menjadi kebutuhan penting.

Bagi C/C++ programmer, Rust merupakan sebuah doa yang terkabul, banyak fitur dan konsep baru yang dapat membantu C/C++ programmer untuk membuat program sangat stabil dengan pengamanan (safety) di berbagai sisi (type, thread and memory safety). Dengan Rust, programmer diajak untuk membuat spesifikasi dengan aturan-aturan yang telah ditentukan dari tiap variable yang dibuat dan fungsi atau method yang dipanggil. Spesifikasi dan aturan-aturan ini bukan hanya dari tipe, tapi juga hal lain yang dibutuhkan untuk pengamanan program.

Berikut hal-hal dari yang biasa sampai luar biasa mengenai Rust, menurut pengamatan dan mungkin salah satu atau salah duanya bisa menjadi alasan untuk melakukan programming dalam Rust.

Kompilasi kode

Ini merupakan hal yang biasa ditemukan di bahasa pemrograman seperti C/C++, Golang, dimana dengan kompilasi kita bisa mendapatkan kecepatan yang memuaskan dari program.

Memiliki Tipe Statik

Tipe statik (Static Type Binding) juga ditemukan di bahasa pemrograman C/C++, Golang, Java. Dapat membantu programmer secara cepat menemukan kesalahan pada penugasan tipe (assignment type mismatch) atau kesalahan tipe dalam alokasi memory pada saat kompilasi sehingga program dapat terhindar dari crash ketika sedang berjalan (runtime).

Perpaduan antara high level dan low level programming

Di satu sisi Rust mengajak programmer untuk melakukan programming secara high level, misalnya dengan konsep Container (vector, hashmap, etc.) untuk data struktur dan konsep Generic Template (<T>) untuk mendefinisikan tipe. Tapi juga tidak meninggalkan low level programming, seperti pengaksesan memory reference (&), memory pointer (*), dengan catatan low level programming ini memiliki aturan ketat dalam penggunaannya, agar pengamanan tetap terjaga. Perpaduan high level dan low level ini juga bisa ditemukan pada C++.

Pengamanan thread dan memory / thread and memory safety

Dari thread dan memory, Rust banyak menawarkan konsep baru yang luar biasa. Diantaranya adalah konsep Ownership, dimana alamat memory bisa "dipinjam" (borrow) kepada assignment variable atau passing variable (melalui fungsi). Aturan ini akan berlaku berbeda untuk mutable type (tipe yang dapat di tulis ulang) dan immutable type (tipe yang tidak dapat ditulis ulang). Dan aturan ini dijaga ketat oleh kompilator (compiler) dengan istilah "borrow checker". Perlu diketahui juga, konsep dasar Ownership memory di Rust ini yaitu move (borrow), copy, dan clone. Dan ada juga konsep Lifetime ('static, 'a, etc.) dari sebuah tipe yang dideklarasikan sebagai variable, yaitu setiap tipe yang dideklarasikan memiliki waktu hidup, waktu hidup ini bisa ditentukan oleh programmer sendiri atau berlaku secara umum (default) dari aturan Rust sendiri, aturan default untuk Lifetime ini disebut Lifetime Elision. Untuk konsep Mutex sebagai pengamanan memory pada thread berlaku sebagai Generic Template, dimana penguncian sumber daya (resource locking) memfokuskan pada variable yang dialokasikan dan bukan pada baris kode, ini berbeda dengan konsep mutex lock pada bahasa C/C++ atau Java yang lama. Karena tidak menggunakan locking atau kesalahan menempatkan locking pada baris kode dapat menimbulkan race condition atau deadlock pada program.

Tidak memiliki pengumpul sampah / garbage collection

Tentu saja hal ini menimbulkan trade off, "there is no such a thing as a free lunch", fitur GC dibebankan pada programmer ketika mendefinisikan variable dan menjadi spesifikasi yang harus dideklarasikan oleh programmer. Dan akan dicek pada saat kompilasi. Fitur ini antara lain adalah Reference Counting dimana alamat memory memiliki variable penghitung (counter), yang akan ditambah ketika ada referensi ke variable baru atau akan dikurangi ketika lifetime berakhir atau dilakukan dereferensi. Fitur Lifetime yang disebutkan sebelumnya juga adalah salah satu fitur dari GC, dimana pada Rust menjadi tanggung jawab programmer. Keuntungan dengan tidak adanya GC ini adalah pada saat program berjalan (runtime) tidak ada overhead memory yang digunakan, karena pada kebanyakan bahasa, misalnya Java atau Python, GC menjadi salah satu bottleneck performance, karena bisa menghabiskan resource atau memory program.

Memiliki fitur pemrograman fungsional

Walaupun pemrograman Rust bersifat imperative, tapi ada beberapa fitur pemrograman fungsional yang diadopsi, diantaranya adalah Immutable Type atau tipe yang tidak bisa ditulis ulang. Container Iterator yang bersifat deklaratif, seperti ".map", ".for_each", ".filter_map", etc. Dan Pattern Matching dengan keyword "match" dan generic template "Option". Perlu diketahui juga, karena Rust memaksa programmer untuk selalu melakukan pengamanan, pada tiap pemanggilan method atau fungsi SEBENARNYA dibutuhkan pattern matching untuk menangani Error. Tapi penanganan Error dengan pattern matching ini bisa saja tidak dilakukan dengan cara pemanggilan method "unwrap", konsekuensinya adalah bila terjadi error akan terjadi "panic".

Demikian sedikit pengamatan mengenai bahasa pemrograman Rust. Pendapat saya adalah jika menginginkan stabilitias, performa yang memuaskan dan keamanan pada program, Rust adalah pilihan yang cocok. Tapi jika menginginkan produktivitas, Rust belum tentu bisa menjadi pilihan. Bagi saya Rust sangat dibutuhkan untuk system programming (kebutuhan os, network atau device programming), dan akan menjadi second atau third layer programming laguange, ketika dibutuhkan untuk speed dan stability pengganti C/C++, sebagai wrapper program-program yang ditulis dengan bahasa Python, Ruby atau Elixir. Hal ini seperti yang telah dilakukan oleh Discord, dimana penggunaan Rust dengan rustler (Erlang interface to Rust) dapat meningkatkan speed untuk struktur datanya, tapi untuk konsep distributed system, tetap menggunakan Elixir.

Filosofi “Let It CRASH!” sebagai pola pikir untuk menangani kesalahan pada sistem

Iskandar Rizki — Fri, 08 May 2020 15:55:53 +0000

Hampir setiap bahasa pemrograman memiliki filosofi agar membantu para penggunanya (dalam hal ini programmer) untuk mengerti behaviour, sifat alami dan citra yang ingin dibangun oleh pengembang bahasa pemrograman tersebut.

Misalnya bahasa pemrograman Golang memiliki filosofi “Radical Simple”, bagaimana bahasa Golang ini ingin mencitrakan dirinya sebagai bahasa pemrograman yang sederhana dan mudah untuk dikuasai. Kemudian ada Python dengan “Explicit is better than Implicit”, Python berusaha mengkomunikasikan kepada programmernya untuk selalu gamblang dalam melakukan aktifitas koding, tanpa “magic code” dengan suatu koding yang tersembunyi di belakang layar.

Filosofi di Erlang/Elixir

Erlang dan dalam hal ini Elixir pun menganut filosofi “Let It CRASH!”. Dengan “Let It CRASH!” ini, pengembang dari Erlang ingin mengkomunikasikan bagaimana penanganan kesalahan pada program (Error Handling), sebagian besar telah ditangani oleh BEAM (Erlang VM). Perlu diingat bahwa bukan berarti sebagai programmer tidak perlu memikirkan Error Handling, hanya saja sebagian besar tanggung jawab dari Error Handling ini telah diambil alih oleh BEAM.

Jika kita perhatikan tentang Error Handling pada bahasa pemrograman yang lain, programmer dipaksa untuk melakukan “Defensive Programming”, dimana programmer harus memikirkan setiap Error yang mungkin akan muncul jika suatu baris kode di eksekusi dan harus mengantisipasi semua kemungkinan Error tersebut dengan menangkap Exception atau menulis kode “if else”. Padahal tidak semua Error adalah kesalahan pada kode, ada Error yang bukan merupakan kendali dari programmer, misalnya kesalahan pada Database, kesalahan Network, kegagalan pada operasi Disk (Disk Failure) dan kesalahan lain yang berasal dari Sistem. Disini BEAM ingin memposisikan dirinya sebagai “penghancur Defensive Programming” (https://www.amberbit.com/blog/2019/7/26/the-misunderstanding-of-let-it-crash/).

Ilustrasi Sebagian kecil class Exception dan Error pada Java yang harus ditangani oleh programmer (https://beginnersbook.com/2013/04/java-exception-handling/)

Filosofi “Let It Crash!” juga ingin menyatakan bahwa dengan terjadinya Error dari program, baik yang berasal dari Error kode atau Error sistem, bukan berarti keseluruhan program yang berjalan akan berhenti atau Crash. Telah disinggung pada artikel blog ini sebelumnya bagaimana Erlang menganut “Actor-based Concurrency”, dimana setiap proses yang dikerjakan ada banyak (ratusan, ribuan, jutaan) Aktor yang melakukan pekerjaan. Bagaimana jika pekerjaan yang dikerjakan oleh beberapa jumlah Aktor tadi terjadi Error ? Jawabannya adalah hanya Aktor dengan pekerjaan yang Error saja yang akan Crash, sedangkan sisa Aktor lain akan terus bekerja. Kemudian apakah Aktor yang Crash akan tetap Crash ? Jawabannya adalah tidak, ada “Supervisor” yang akan menghidupkan kembali Aktor yang Crash.

Apa itu “Supervisor” pada Erlang/Elixir

Supervisor pada Erlang/Elixir adalah jenis lain dari Aktor yang bertugas untuk melakukan “link and monitor” kepada Aktor lain yang bertugas untuk menjalankan proses (Worker). Dengan link, Supervisor dapat mengikat secara kuat dengan Aktor turunannya, sehingga jika terjadi Crash pada Aktor yang dimonitor, notifikasi atau pesan pemberitahuan akan dikirimkan ke Supervisor.

Ilustrasi contoh hubungan antara Supervisor dan Worker pada BEAM (supevision tree). Supervisor dapat melakukan “link and monitor” pada Worker turunannya (http://isaacjarquin.github.io/software/2017/09/01/supervision-tree.html)

Dengan mekanisme ini, cara kerja Aktor di dalam BEAM sangat teratur dan terorganisir, dimana seperti sebuah organisasi, yang didalamnya terdapat konsep Supervisor dan Worker yang akan memastikan seluruh jalannya aplikasi/sistem berjalan dengan lancar. Ini merupakan sebuah konsep toleransi terhadap kesalahan (Fault Tolerance) yang mungkin belum ada pada bahasa pemrograman lainnya. Karena pada bahasa pemrograman / jenis Stack aplikasi lainnya, tanggung jawab ini diserahkan kepada entity Stack yang lain di dalam ekosistem, sehingga Stack yang dibangun menjadi kompleks. Contohnya adalah pada stack django python yang membutuhkan gunicorn untuk melakukan pengaturan terhadap proses worker, atau zookeeper pada java untuk menghadirkan fungsi Fault Tolerance, Service Discovery dan Cluster.

Hanya menulis kode “The Happy Path”

Dengan semua filosofi yang ingin dibangun oleh pengembang Erlang/Elixir ini apakah tujuan besarnya ? Tujuannya adalah “Programmer Happiness”, semuanya adalah demi kebahagian programmer Erlang/Elixir. Kebahagian dalam arti programmer hanya diperlukan menulis bagian kode “The Happy Path”, bagian kode “The Sad Path” seperti Error, sebagian besarnya dapat dihapus dari baris kode. Impact atau pengaruhnya adalah kode yang bersih, jelas dan hanya berisikan logika aplikasi, jikapun ada Error Handling, itu hanya merupakan bagian dari logika aplikasi, seperti Error pada input pengguna yang perlu ditangani.

“The Happy Path” pun tidak hanya berlaku bagi programmer, tetapi bagi tim yang menangani infrastruktur, akan terdampak juga. Karena stack aplikasi yang dibutuhkan menjadi lebih sederhana dan berkurang kompleksitasnya. Sebagai contoh seperti Whatsapp yang memiliki aplikasi yang diakses dengan jutaan pengguna, hanya dibutuhkan sekitar 50 orang engineer untuk menanganinya.

Demikian sedikit penjelasan tentang filosofi “Let It CRASH!” pada Erlang/Elixir. Lebih lanjut tentang Supervisor bisa dilihat di https://code.tutsplus.com/id/articles/supervisors-in-elixir--cms-29330 . Terima kasih dan semoga bermanfaat.

Mengenal Pemrograman Konkurensi pada Bahasa Pemrograman Elixir

Iskandar Rizki — Fri, 08 May 2020 15:40:09 +0000

Dalam membangun sebuah aplikasi yang di dalamnya ada aktivitas pemrograman, terkadang kita dihadapkan pada situasi dimana dibutuhkan performansi dalam menjalankan proses-proses di dalam kode yang ditulis.

Untuk mencapai performansi yang memuaskan, dibutuhkan penggunaan resource seperti CPU dan memory yang maksimal dengan dijembatani oleh fasilitas yang terdapat dalam bahasa pemrograman.

Tak berbeda juga dengan bahasa pemrograman lain, Elixir yang berjalan diatas Erlang Virtual Machine (BEAM) ini memiliki berbagai fitur untuk melakukan pemrograman konkurensi atau concurrent programming, sehingga proses-proses yang berjalan diatas BEAM ini dapat memaksimalkan kerja CPU dan memory melalui pemrograman pada bahasa Elixir.

Hal yang membedakan pemrograman lain dan Elixir dalam pemrograman konkurensinya, Elixir memiliki konsep konkurensi berbasiskan Aktor (Actor Based Concurrency). Hal ini diturunkan dari bahasa pendahulunya yaitu Erlang. Erlang sendiri dikembangkan oleh Erricsson dan banyak digunakan untuk aplikasi telekomuniksi di seluruh dunia.

Dalam konkurensi berbasiskan Aktor, ada 3 hal yang penting untuk dilibatkan dalam jalannya program. Pertama adalah Aktor yang melakukan sebuah pekerjaan (actor), kedua adalah pekerjaan itu sendiri (process), dan terakhir adalah pesan yang dipertukarkan antar Aktor (message passing).

Kenapa ilustrasi Aktor diatas sangat penting dijabarkan dalam sebuah konsep pemrograman konkurensi ? Karena pada kenyataanya di bahasa pemrograman lain umumnya banyak yang terjerumus pada kompleksitas implementasi pemrograman konkurensi ini, yang disebabkan saling tumpang tindih, dan terjadi konflik dalam pemanfaatan resource memory dan IO (Disk, Network). Yang kemudian akan mengakibatkan jalannya program diluar harapan bahkan terjadi crash pada program.

Dengan konsep Aktor ini, masing-masing Aktor tersebut memiliki resource komputasi CPU dan memory secara terpisah, tidak ada lagi saling tumpang tindih, dan terjadi konflik penggunaan resource memory dan IO. Sehingga semua Aktor akan berjalan secara bersamaan menjalankan proses yang hanya Aktor tersebut eksklusif mengetahuinya, dan hanya akan berkomunikasi melalui penukaran pesan, tanpa saling berbagi alamat memory sebagai sebab konflik resource yang telah dijelaskan sebelumnya.

Ketika sebuah aktor sudah dinyatakan “hidup” dan siap menerima pesan, maka Aktor tersebut akan memiliki PID (Process ID). PID tersebut adalah sebuah alamat kirim mengirim pesan (message passing) antar Aktor.

Ilustrasi sebuah agent yang berupa Aktor, dimana memiliki alamat PID, kemudian dikirimkan pesan “update” dan “get”, yang pada akhirnya diperintahkan untuk “stop”

Dan apabila sebuah Aktor, katakan Aktor A menginginkan Aktor lain untuk melakukan perhitungan, misalnya Aktor B, maka yang diperlukan hanya pengiriman pesan (message passing) dari Aktor A ke PID Aktor B yang menjalankan proses perhitungan tersebut.

Setiap pesan yang dikirim akan diterima oleh Aktor tadi di dalam sebuah Mailbox. Mailbox ini berupa antrian pesan, jika satu pesan berisi perintah untuk menjalankan proses perhitungan dan proses telah berhasil dijalankan maka akan diambil pesan berikutnya pada Mailbox, untuk kemudian dijalankan isi perintah dalam pesan tersebut, begitu seterusnya.

Ilustrasi Aktor yang saling mengirimkan pesan, dalam masing-masing Aktor tersebut memiliki resource CPU dan memory secara terpisah, dan menjalankan proses secara eksklusif

Ilustrasi Aktor, PID, Pesan dan Mailbox (diambil dari https://learnyousomeerlang.com/the-hitchhikers-guide-to-concurrency)

Aktor A yang sebelumnya mengirimkan pesan, memiliki 2 pilihan, yaitu menunggu hasil proses perhitungan, sehingga nilai dari perhitungan tadi dapat digunakan oleh Aktor A, atau mengabaikan semua hasil perhitungan, dan membiarkan Aktor B yang mengurus semua hasil perhitungan (misalnya dengan disimpan ke database atau lainnya).

Pada suatu aplikasi yang menjalankan BEAM ini, memiliki ribuan, ratusan ribu bahkan jutaan Aktor adalah hal yang biasa. Sehingga aplikasi seperti Whatsapp yang dibangun diatas BEAM dengan bahasa Erlang dapat melayani miliaran pesan dalam suatu waktu.

Keuntungan lain dari Aktor ini adalah skalabilitas di level jaringan, dimana antar Aktor ini bisa saling berkomunikasi tidak hanya di level satu aplikasi, tapi juga bisa saling berkomunikasi atau berkirim pesan antar mesin di dalam suatu jaringan. Dari sisi kode yang dibangun, keuntungan yang didapatkan adalah pengembang akan fokus terhadap logika aplikasi yang dibangun, tanpa ada gangguan dari kode-kode yang berhubungan dengan saling tumpang tindih resource dan kode-kode untuk menghindari konflik resource memory dan IO.

Sisi negatif dari Aktor ini adalah penggunaan memory yang relatif lebih besar dibandingkan solusi konkurensi pada bahasa pemrograman lainnya. Dan untuk mendapatkan performansi kecepatan secara kasar (yang tidak menggunakan proteksi di memory) aplikasi Elixir sulit untuk dicapai, dimana BEAM telah memproteksi semua jalannya Aktor agar stabil dalam penggunaan memory, sehingga memiliki trade off atau harga yang dibayar dengan kecepatan dan besarnya memory untuk kestabilan sistem aplikasi.

Demikian sekilas konsep konkurensi berbasis Aktor pada bahasa pemrograman Elixir, untuk sumber pengetahuan lebih lanjut mengenai bahasa pemrograman Elixir, silahkan kunjungi https://elixirschool.com/id/