Software Architecture

Rizal Diantoro
Sulang
Published in
6 min readMay 16, 2018

Software application architecture adalah sebuah proses untuk mendefinisikan struktur dari suatu aplikasi yang dapat memenuhi seluruh kriteria dari sisi teknis dan juga operasional, dengan pertimbangan kualitas seperti performance, security, and manageability.

— — Definisi menurut Martin Fowler —
““The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system’s lifetime; and, in the end, architecture boils down to whatever the important stuff is.”

Kenapa sih suatu Software Architecture itu penting?

https://msdn.microsoft.com/en-us/library/ee658098.aspx

Pada dasarnya ketika membuat sebuah aplikasi, ada 3 komponen utama yang akan saling berkaitan satu sama lain seperti gambar diatas yaitu user, business, dan system. Dan menurut definisi yang sudah dibahas sebelumnya, suatu software architecture yang baik adalah yang mampu memenuhi seluruh kriteria dari komponen-komponen tersebut. Sayangnya, seiring berjalannya waktu biasanya akan terjadi perubahan, baik dari sisi user, business, maupun system. Tapi merubah suatu komponen akan berpengaruh pada komponen yang lainnya.

Seperti contoh ketika kita ingin merubah bisnis model, mau tidak mau kita juga harus merubah dari sisi sistem untuk mampu memenuhi kriteria bisnis model yang baru. Tidak hanya itu, dari sisi user experience pun juga akan mengalami hal yang sama. Oleh karena itu software architecture harus dipersiapkan dengan baik, dan dapat mengantisipasi kemungkinan-kemungkinan perubahan yang akan terjadi pada masa yang akan datang.

Tujuan dari Software Architecture

Untuk menciptakan suatu jembatan antara kebutuhan bisnis dengan kebutuhan teknis melalui use cases yang sudah dibuat, dan menemukan cara bagaimana untuk mengimplementasikan use cases tersebut. Software architecture yang baik akan meminimalisir kemungkinan resiko/kegagalan yang diciptakan oleh para developer. Selain itu, software architecture yang baik juga dapat beradaptasi dengan perubahan yang akan terjadi seiring waktu dalam teknologi perangkat keras dan perangkat lunak, serta dalam skenario dan persyaratan pengguna. Seorang arsitektur aplikasi juga harus mempertimbangkan hasil desain arsitektur yang sudah dibuat agar memiliki performance dan security yang baik.

Software Architecture pada Suling

Dibuat oleh Fachrur Rozi

Kita akan bahas satu-satu mulai dari yang paling kanan, baik dari segi kelebihan dan juga kekurangannya.

Databases (PostgresQL)

Kami menggunakan databases untuk menyimpan data-data yang ada pada aplikasi kami. Database yang kami gunakan pada Suling sendiri merupakan PostgresQL, beberapa alasan utama kami memilih PostgresQL adalah karena tim sudah familiar dengan PostgresQL, dan juga gratis. Karena sejauh ini kami belum punya pendaan, biaya sangat berpengaruh dalam bagaimana kami menentukan stack yang akan digunakan. Selain itu, apa yang dibutuhkan oleh suling sendiri masih mampu disediakan dengan baik oleh PostgresQL.

Meskipun gratis, namun PostgresQL memiliki performance yang cukup baik.

Bisa kita lihat diatas, kecepatan Query dari PostgresQL mampu mengimbangi atau bahkan lebih baik dari database lain.

Alternatif yang mungkin kami gunakan

  1. MySql
    Kami mungkin akan beralih ke MySql jika PostgresQL sudah tidak mampu memenuhi apa yang kami butuhkan. Alasannya adalah, karena MySql mempunyai kemiripan dengan PostgresQL dengan fitur yang jauh lebih lengkap. Selain itu, komunitas MySql juga sudah besar sehingga tidak akan menyulitkan jika menemukan masalah-masalah semasa pengembangan software.
  2. NoSQL
    Kami juga mungkin menggunakan NoSQL dikarenakan kami butuh untuk melakukan query text yang saat ini sulit dilakukan ketika menggunakan PostgresQL.
  3. Redis
    Untuk mempercepat read terhadap database, mungkin juga ditambahkan redis untuk melakukan caching. Sehingga REST akan membaca data jauh lebih cepat ketimbang melakukan pemanggilan pada database asal.

Django (Backend Service)

Kami menggunakan Django sebagai backend kami, dan dengan bantuan Djano Rest Framework kami mengubahnya menjadi aplikasi REST. Kami memiliki beberapa alasan tersendiri mengapa memilih Django, diantaranya adalah:

  1. Menggunakan bahasa python yang cukup familiar dengan tim
  2. Mudah untuk dipelajari, dan diimplementasikan
  3. Modular
  4. Memiki keamanan yang baik

Beberapa kekurangan django menurut kami:

  1. Masih sulit untuk menemukan hosting yang dapat digunakan untuk melakukan deployment python, tidak sebanyak PHP.
  2. Menggunakan ORM yang terkadang membingungkan.

Alternative lain

  1. Go
    Merupakan bahasa yang cukup populer digunakan saat ini, dia memiliki syntax yang mirip dengan bahasa high level seperti java, namun memiliki performa yang baik seperti bahasa low level seperti c. Go sendiri memudahkan programmer dalam menciptakan aplikasi yang concurent.
  2. Rails
    Memiliki waktu developing yang juga cepat seperti Django, memiliki komunitas dan pengguna yang lebih banyak dari Django.

FrontEnd(React.Js)

Salah satu cara yang mudah untuk mengurangi beban server adalah dengan menggunakan resource yang dimiliki oleh client. Hal itu kami lakukan dengan client side rendering React.js, dimana yang pertama kali dikirimkan oleh server adalah template html, dan user akan melakukan request data yang selanjutkan akan dirender di client. Hal ini akan meningkatkan performance, karena request yang dikirimkan oleh user hanya akan dibalas oleh data-data saja, bukan seluruh view dan datanya.

Kami memilih React.js karena memiliki komunitas yang sudah besar, dan didukung oleh facebook dan instagram. Sehingga kami yakin bahwa stack ini akan bertahan cukup lama hingga beberapa tahun kedepan. React.js juga mendukung PWA, sehingga aplikasi dapat disimpan didalam Android layaknya sebuah aplikasi, selain itu React.js menggunakan Service Worker dapat membuat aplikasi menjadi Offline Mode.

Kekurangan dari React.js adalah learning curve yang sangat tajam, sehingga membutuhkan waktu yang lama untuk mempelajari stack yang satu ini. Selain itu melakukan setup pada stack ini juga memerlukan waktu yang lama dan sulit. Jika kita asal import library yang tidak dibutuhkan, justru bisa membuat aplikasi ini menjadi tidak efisien lagi.

Alternatif yang bisa digunakan lainnya

  1. Vue.js
    Memiliki performa yang baik seperti React.js dengan learning curve yang jauh lebih bersahabat untuk yang baru belajar. Vue ini tepat digunakan untuk membuat aplikasi dengan skala kecil.

API (api.cs, linkedin)

Kami menggunakan beberapa API untuk kebutuhan sistem yang kami buat. Beberapa API yang kami gunakan diantaranya adalah:

  1. API CS
    Digunakan untuk login dan mengambil data mahasiswa.
  2. Linkedin
    Digunakan untuk login, dan mengambil data-data yang ada di linkedin.

Deployment

Kami menggunakan Image Based untuk melakukan deployment, sehingga akan memudahkan untuk skalabilitas. Kami bisa melakukan deployment kedalam beberapa server, setelah itu kami pasang load balancer untuk mengatur request yang masuk. Saat ini kami menggunakan Azure VM sebagai tempat kami meletakkan server tersebut, dengan satu load balancer dan juga satu server.

Constraint yang kami temukan.

  1. Kami tidak bisa menggunakan service luar untuk menyimpan data.
    Awalnya sempat ada wacana untuk menggunakan elasticSearch, untuk memudahkan pencarian mahasiswa. Namun hal tersebut mengharuskan agar data yang ada diindex ke elasticSeacrh, yang mana hal tersebut tidak diizinkan oleh pihak fakultas.
    Saran dari kami adalah agar pihak fakultas maupun universitas mampu mengimplementasikan fungsi search yang baik yang dapat digunakan untuk melakukan pencarian terhadap mahasiswa.
  2. Single Truth Data
    Kami tidak menyimpan data-data penting yang ada pada database UI, dikarenakan hanya boleh ada satu data yang benar untuk seluruh aplikasi yang menggunakan database UI. Jika kami ketahuan memiliki data yang berbeda, maka kami harus rela jika pihak UI inigin mematikan aplikasi kami. Akhirnya, kami selalu melakukan request kedatabase UI setiap saat, setiap kali kami membutuhkan data.
  3. Aplikasi yang kami buat harus bisa dideploy di server Fasilkom
    Kami harus bisa membuat agar aplikasi ini mudah dideploy pada server Fasilkom, hal itu yang akhirnya membantu kami memilih Docker/Image Based sebagai cara deployment. Karena hanya perlu di build docker image yang sudah ada.

Okee sekian dulu yaa, babay

--

--