Tulisan ini adalah bagian dari SOLID Principles Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Berdasarkan Wikipedia, dua point utama dari prinsip ini:

• High level modules should not import anything from low-level modules. Both should depend on abstractions (module-module High-level)

• Abstraction should not depend on details. Details (concrete implementations) should depend on abstractions.

Beberapa mungkin bingung, seperti apa itu high-level module, apa itu low-level module dan juga yang dimaksud abstraction. Yang pertama perlu diingat bahwa module itu bisa berupa class, bisa kumpulan class untuk menyelesaikan kasus penggunaan tertentu (usecase). Berikut sedikit penjelasan mengenai istilah-istilah tersebut.

• High-Level module merupakan module teratas/terdepan yang memerlukan module/class yang lebih detail untuk menyelesaikan suatu masalah atau logic. Cirinya, module ini akan menginisialisasi module lain di dalamnya.

• Low-Level module merupakan module yang lebih detail untuk menyelesaikan suatu masalah atau logic. Cirinya, module ini tidak menginisialisasi module tertentu di dalamnya.

• Abstraction, proses men-generalkan sebuah logic yang kompleks atau menyembunyikan detail-detail yang tidak diperlukan untuk diketahui antar module. Biasanya menggunakan interface atau abstract class.

Untuk lebih memperjelas, mari kita lihat dari contoh code berikut.

Account Class File

class EmailAccount {
    public emailBucket: string[] = []
    public notifyType: string

    constructor() {
        this.sendType = 'email'
    }

    addEmail(email: string) {
        this.emailBucket.push(email)
    }

    validate(email: string) {
        return email
    }
}

Notification Class File

class Notifier {
  private account: EmailAccount

  constructor(email: string) {
     this.account = new EmailAccount
     this.account.addEmail(email)
  }

  send() {
      const data = this.send.emailBucket
      const type = this.send.notifyType

      this.sendTo(type, data)
  }

     sendTo(type: string, data: string) {
         console.log({type, data})
     }
}

Code di atas memperlihatkan bahwa class Notifier adalah high-level module karena class atau module ini membutuhkan class yang lebih detail (EmailAccount) untuk menyelesaikan tugasnya, terlihat pada constructor class ini. Sedangkan class EmailAccount disebut juga sebagai low-level module karena class atau module ini lebih explicit yaitu management account email dan utamanya module ini tidak menginisialisasi atau tidak memerlukan module lain di dalamnya.

Seperti terlihat pada class Notifier pada section constructor, class ini meng-initialisasi EmailAccount yang diset ke property account. Lalu pada bagian method send terjadi pengambilan property emailBucket dan notifyType yang merupaka property milik EmailAccount. Bagian ini lah yang menjadi masalah. Class atau module ini menyalahi aturan dari Dependency Inversion Principle (DIP). Karena seandainya terjadi perubahan pada property pada module EmailAccount, misalnya property emailBucket berubah menjadi emails maka programmer harus merevisi juga high-level module yaitu class Notifier . Seharusnya agar tidak melanggar aturan DIP, sebaiknya jika terjadi perubahan pada EmailAccount module , maka pada Notifier tidak perlu ada perubahan. Untuk programmer perlu melakukan abstraction yang biasanya menggunakan interface atau abstract class . Sebagai contoh code di sebelumnya diubah menjadi seperti berikut.

Abstraction

type Prop = {
    type: string
    data: string[]

}

// MG is short of Management
interface IAccountMG {
    getData(): Prop
}

Pertama kita perlu melakukan abstraction. Seperti pada contoh snippet code di atas melakukan abstraction dengan memanfaatkan type dan interface . Di typescript sendiri, kita bisa menggunakan banyak cara untuk abstraction, bisa menggunakan type, interface atau juga menggunakan abstract class. Tapi untuk contoh kasus di code ini cukup menggunakan type dan interface saja.

Seperti yang terlihat pada interface IAccountMG terdapat member method getData dengan return value berupa type Prop . Tujuan dari type Prop adalah kontrak agar module apapun yang meng-implement interface IAccountMG maka return dari getData harus selalu ber-type Prop dengan begitu return type akan selalu konsisten.

Account class

class EmailAccount implements IAccountMG {
    public emailBucket: string[] = []
    public notifyType: string

    constructor() {
        this.sendType = 'email'
    }

    addEmail(email: string) {
        email = this.validate(email)
        this.emailBucket.push(email)
    }

    validate(email: string) {
        return email
    }

    getData() {
        return {
            data: this.emailBucket,
            type: this.notifyType
        }
    }

}

Selanjutnya class EmailAccount meng-implement interface IAccountMG. Dengan meng-implement interface IAccountMG maka class EmailAccount akan dipaksa untuk meng-implementasi method getData juga. Karena method ini yang akan di call pada high-level module maka dari itu method getData wajib ada dan callable (bisa dieksekusi).

Notifier Class

class Notifier {
  private account: IAccountMG

  constructor(email: string) {
    this.account = new EmailAccount
    this.account.addEmail(email)
  }

  send() {
    const payload: Prop = this.account.getData()
    this.sendTo(payload)
  }

  sendTo(payload: Prop) {
    console.log(payload)
  }
}

Lalu pada contructor class Notifier sama seperti sebelumnya yaitu menginisialisasi class EmailAccount. Tapi yang berbeda kali ini adalah type property account pada Notifier bukan lagi EmailAccount melainkan interface IAccountMG. Dengan begini module Notifier tidak perlu tahu yang dilakukan getData pada module account. Yang perlu diketahui oleh module Notifier hanya bahwa getData bersifat dapat dieksekusi dan memberikan return type Prop. Itulah tujuan dari abstraction yaitu menyederhanakan module dengan menyembunyikan detail pada Low-Level Module yang tidak perlu diketahui oleh High-Level module.

Lalu kenapa menggunakan penamaan method getData dari pada getEmail misalnya. Kembali ke point ke dua pada gagasan dari DIP, yaitu abstraction tidak boleh berdasarkan detail dari implementator. Implementator-lah yang harus mengikuti abstraction. Maksudnya penamaan dan fungsi member method harus lebih general, seperti misal pada kasus code di sini, jika misalkan akan menambah module lain yang bukan berupa kumpulan email maka getData sudah cukup untuk merepresentasikan module implementatornya.

references:

• https://www.tutorialsteacher.com/csharp/dependency-inversion-principle

• https://salesforcecodex.com/architecture/understanding-dependency-inversion-principle-with-c/

• https://code-maze.com/dependency-inversion-principle/

Tulisan ini adalah bagian dari SOLID Principles Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Berdasarkan history-nya, ISP dikenalkan ketika Robert C. Martin berkonsultasi dengan Xerox yang merupakan brand dari Mesin Printer. Pada saat itu Xerox membuat printer baru yang mana bisa menambah beberapa fitur yang di versi printer lainnya tidak ada. Pada saat itu, Xerox menambah fitur baru seperti kemampuan Stapling (Menstaples kertas) dan Faxing (Menerima dan mengirim Fax) pada printer barunya. Dengan adanya penanambahan fitur tersebut maka pasti akan diperlukan perubahan program yang tentunnya akan berpengaruh pada program yang digunakan oleh device printer versi lainnya. Jika desain dari program bermasalah, maka potensi akan mengakibatkan error pada device printer lainnya akan tinggi ketika program printer di-update. Maka dari itu munculah gagasan baru yang sekarang kita kenal ISP (Interface Segregation Principle).

Ide dari Interface Segregation Principle cukup sederhana, yaitu

“Client should not be forced to depend on methods it does not use”

Yang berarti Client (class/object yg berkorelasi) seharusnya tidak dipaksa untuk meimplementasikan method yang diluar dari tugas spesifik clientnya atau objectnya. Dengan begitu class atau object akan lebih ringkas karena tidak mengimplementasikan banyak method-method yang tidak digunakan ke dalam class tersebut selain itu class atau object akan hanya memiliki tugas yang spesifik (SRP).

Sebagai contoh kasus, kita gunakan contoh kasus sebelumnya tentang Vending Machine.

Asumsi kita memiliki sebuah class NotifyEvent seperti ini

class NotifyEvent {
	
	private data: Record<string, any> = {}

	setup(data: Record<string, any>) {
		this.data = data
	}
	
	console() {
	   // Code for testing logging
	}
	
	async send() {
		if (process.env.NODE_ENV === 'testing') {
			return this.console(this.data)
		} else {
			return await this.sendSMS()
		}
	}
	
	async sendSMS() {}
	
}

Kegunaan utama dari class tersebut adalah untuk mengirim notifikasi SMS yang ditandai dengan adanya method sendSMS pada class tersebut. Sedangkan pada contoh ini, method console digunakan untuk kebutuhan automated test untuk usecase tersebut. Jika mengikuti class tersebut, bentuk interface kurang lebih akan seperti ini:

interface INotifyEvent {
  setup(data: Record<string, any>): void
  console(): void
  send(): Promise<void>
  sendSMS(): Promise<void>
}

Pada contoh di atas mungkin interface masih terlihat lean karena method digunakan sedikit, tapi ketika method yang dimiliki class tersebut cukup banyak, maka interface akan menjadi besar (bloat). Sehingga perlu dilakukan penyederhanaan interface dengan cara memisahakan interface berdasarkan fungsi utamanya dengan tujuan agar class yang mengimplementasi interface tersebut tidak dipaksa untuk mengimplementasikan method yang tidak diperlukan.

Maka interface akan menjadi kurang lebih seperti ini:

interface INotifyEvent {
	setup(data: Record<string, any>): void
	send(): Promise<void>
}

interface INotifySMSEvent extends INotifyEvent {
	sendSMS(): Promise<void>
}

interface INotifyTestEvent extends INotifyEvent {
  console(): void
}

Dengan memisahkan interface seperti ini, maka class yang mengimplementasikannya tidak akan dipaksa mengimplementasikan method yang tidak diperlukan. Misal jika class akan digunakan untuk keperluan testing, maka class akan mengimplementasi interface INotifyTestEvent yang hanya memerlukan method console. Class yang bersangkutan tidak akan dipaksa mengimplemntasikan method sendSMS karena tidak diperlukan. Sehingga class akan lebih simple dan sesuai kegunaannya.

references:

• https://hackernoon.com/grasp-principles-part-2-controller-low-coupling-and-high-cohesio

• https://www.infoq.com/minibooks/reexamining-microservices/

• Robert C Martin, The Interface Segregation Principle, C++ Report, June 1996

Tulisan ini adalah bagian dari SOLID Principles Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Jika dalam buku “Design Principles and Design Pattern” menyebutkan seperti ini

“Subclass should be substitutable for their base classes”

Bahwa class turunan harus bisa disubtitusikan untuk Class Basenya. Sebagai contoh, jika Sebuah function semisal function office(ketua: PemimpinClass), jika WakilKetuaClass merupakan subclass dari PemimpinClass maka argument pada fungsi office bisa digantikan oleh WakilKetuaClass.

Principle ini terlihat sederhana dan banyak yang tidak terlalu mendetailkan prinsip ini. Menurut saya pribadi prinsip ini merupakan prinsip paling rumit dibanding 4 prinsip lainnya dalam SOLID, karena pada prinsip ini ada beberapa aturan yang harus dipatuhi. Terutama konsep-konsep dasar pada OOP seperti Covariance, Contravariance dan Invariant. Jika belum memahami tentang hal tersebut silahkan membaca posting sebelumnya di link berikut.

Covariance dan Contravariane

Selain itu silahkan membaca posting lainnya tentang class invariant pada link berikut.

Class Invariant

Perlunya memahami konsep-konsep dasar tersebut dapat mempermudah reader dalam memahami aturan-aturan yang perlu dipatuhi pada LSP. Sederhananya pada prinsip ini adalah tentang mensubtitusikan/menggantikan Obejct sejenis. Sebagai contoh.

// super type
class Machine {}

// sub type mini machine
class MiniMachine extends Machine {}

// sub type large machine
class LargeMachine extends Machine {}

Jika melihat cuplikan code tersebut akan mengerti apa yang dimaksud mensubtitusi. Dimana pada cuplikan code tersebut terdapat tiga buah class, dimana dua diantaranya adalah subtype. Jika kedua subtype tersebut diimplementasikan akan seperti ini

const mini = new MiniMachine
const large = new LargeMachine

function dispatch(machine: Machine) {}

Pada function dispatch terdapat param machine yang bertype Machine. Karena param machine bertipe Machine maka dua instance yang dibuat bisa saling menggantikan sebagai argument pada param machine di fungsi dispatch karena kedua instance tersebut merupakan turunan dari class Machine.

Namun LSP tidak sesederhana itu. Ada aturan-aturan yang perlu dipatuhi. Hal tersebut diperlukan guna mejaga ketahanan dari program yang dibuat.

Aturan-aturan LSP

Berikut ini adalah pejelasan tentang aturan-aturan yang perlu dipatuhi.

Signature Rules

• Convariance dimana keluar dari method atau function harus memiliki degree yang lebih kecil dari suppertype-nya.

• Contravariance dimana nilai argument harus memiliki degree lebih besar dari pada supertype-nya.

• Jumlah throw exception pada logika method bisa dikurangi, tapi tidak boleh ditambah.

Untuk pembahasan tentang Covariance dan Contravariance bisa membaca artikle tentang ini terlebih dahulu pada link berikut. Aturan lainnya bahwa jumlah Throw Exception pada method boleh dikurangi tapi tidak boleh ditambah. Karena akan mengakibatkan unpredictable throw exception yang mengakibatkan system break.

Property Rules

• Class invariant

Dimana class/object selalu terjaga dan tergaransi selama object class tersebut hidup. Untuk penjelasan detail tentang class invariant bisa membaca pada post sebelumnya di link berikut

Class Invariant

• History constraint

Dimana property yang seharusnya immutable tetap terjaga atau tidak boleh berubah. Sebagai contoh.

class VendingMachine {
    protected maxItem: number = 0;

    constructor(maxItem: number) {
       this.maxItem = maxItem;
    }
}

Pada class VendingMachine terdapat property maxItem pada code di atas. Property ini hanya boleh di-set nilai sekali ketika pembuatan object. Karena pada dasarnya maxItem adalah asumsi bahwa ketika pembuatan machine, maksimal barang yang bisa ditampung sesuai dengan desain dari mechine itu sendiri dan bernilai constant selama mesin berjalan. Sehingga kecil kemungkinan jika ada perubahan nilai maxItem tersebut.

• Preconditions boleh dipertahankan tapi tidak boleh dikuatkan dari method di class parent-nya.

Dimana terdapat conditional flow yang mungkin ada pada head dari sebuah method public pada supertype, atau bisa kita syarat yang harus dipenuhi sebelum masuk ke section logic dari method tersebut. Misal seperti code di bawah ini.

class VendingMachine {    
    protected maxItem: number = 10;

    doSomething(min: number) {

      // pre condition
      if (min < 2 || min >= this.maxItem) {
         throw new Error("Invalid min item")
      }

      // main logic method

      // post condition
    }
}

class MiniMachine extends VendingMachine {

    doSomething(min: number) {
        // dikuatkan, dilarang menguatkan
        // ---
        // if (min < 3 || min >= this.maxItem) {
        //   throw new Error("Invalid min item")
        // }

        // dilemahkan, diperbolehkan
        if (min < 1 || min >= this.maxItem) {
         throw new Error("Invalid min item")
      }
    }

}

Pada cuplikan code tersebut, pada method doSomething terdapat control flow dimana nilai min tidak boleh kurang dari 2. Maka pada method di subtype-nya, nilai 2 tersebut tidak boleh dikuatkan misalkan menjadi 3. Hal tersebut bisa mengakibatkan program break/berhenti jika terdapat program lain menggunakan/mengeksekusi method tersebut. Kecuali jika batas tersebut dilemahkan, misal jadi batasnya 1 item. Hal tersebut tidak akan bermasalah, karena secara asumsinya ketika pertama kali class tersebut didesain, batasan minimal 2 item. Jadi semua client yang menggunkan class tersebut masih mempertahankan bahwa syarat vending machine minimal 2 item. Ketika nilai diganti jadi 1, maka program tidak akan break karena masih memenuhi syarat.

Jadi yang dimaksud pada pre-condition adalah, jangan membuat syarat baru pada head method yang akan membuat program break.

• Postconditions boleh dipertahankan tapi tidak boleh dilemahkan dari method di class parent-nya

Post condition kebalikan dari pre condition. Post condition ini berada pada foot method atau setelah logic utama dari method dijalankan. Dimana syarat dari LSP adalah tidak boleh dilemahkan.

class VendingMachine {    
    protected maxItem: number = 10;

    doSomething(min: number) {

      // pre condition

      // main logic method
      const sum = min - 3;

      // post condition
      if (sum < 5) {
         throw new Error("Value is too small")
      }
    }
}

class MiniMachine extends VendingMachine {
   doSomething(min: number) {

       // Dilemahkan, tidak diperbolehkan
       // ---
       // if (sum < 6) {
       //  throw new Error("Invalid result")
       // }

       // Dikuatkan, diperbolehkan
       // --

       if (sum < 3) {
           throw new Error("Value is too small")
       }
   }
}

Pada cuplikan code tersebut terlihat bahwa jika hasil sum kurang dari 5 maka tampilkan Error. Ketika sudah banyak client yang menjadi turunan dari class VendingMachine tersebut, berarti sudah mendefinisikan bahwa paling besar adalah nilai 5 sebagai batas. Jika postcondition pada subtype dilemahkan, misal menjadi sum < 6, maka ketika hasil perhitungan pada main logic bernilai 5, program yang seharusnya bisa berlanjut tapi berakhir break karena tidak memenuhi syarat.

Setup Workspace

Di ekosistem Rust, untuk menginisialisasi directory workspace bisa menggunakan popular package manager yaitu menggunakan Cargo. Pada tulisan ini saya menggunakan Cargo dan rustc version 1.84.1

$ cargo --version
cargo 1.84.1 (66221abde 2024-11-19)

$ rustc --version
rustc 1.84.1 (e71f9a9a9 2025-01-27)

Selanjutnya dengan membuat workspace baru dengan nama dbconn sebagai contoh

$ cargo new dbconn
$ cd dbconn

Agar code bisa terkoneksi ke sqlite, maka diperlukan sqlx. Jalankan command berikut untuk menambahkan sqlx. Pada saat tulisan ini dibuat, sqlx terbaru menggunakan version v0.8.3

$ cargo add sqlx@0.8.3 --features runtime-tokio,sqlite

Pada command tersebut saya menambahkan option --features. Option ini digunakan agar cargo hanya meng-compile fitur-fitur yang diperlukan saja, sehingga binary yang dihasilkan akan lebih kecil dari pada meng-compile keseluruhan fitur yang mana tidak digunakan. Jika kita buka file Cargo.toml maka kurang lebih flag akan terlihat seperti ini

[dependencies]
sqlx = { version = "0.8.3", features = ["runtime-tokio", "sqlite"] }

Selanjutnya karena async pada Rust bisa menggunakan beberapa package library, seperti tokio atau async-std. Pada tulisan ini, akan menggunakan tokio karena pada setup sqlx kita sudah menambahkan fitur yang di-enable adalah runtime-tokio.

$ cargo add tokio@1 --features full

Setelah semua package yang diperlukan ter-download, selanjutnya jalan cargo check guna memastikan semua dependencies terdownload.

$ cargo check

Setup SQLite Database

Sebelum melakukan perubahan code pada main.rs, kita perlu setup database sqlite terlebih dahulu. Karena kita belum menggunakan migration tool apapun untuk meng-inisialisasi database, maka perlu melakukannya secara manual dengan langkah seperti berikut.

$ sqlite3 db.sql
sqlite> create table users (id int primary key, name varchar)
sqlite> insert into users (id, name) values (1, 'Sample User')
sqlite> select * from users;
1|Sample User

Setup Connection and Query

Setelah selesai membuat sqlite database. Kita coba kembali ke directory /tmp/dbconn. Dimana pada directory ini terdapat file src/main.rs yang berisi code start started Rust seperti ini.

fn main() {
   println!("Hello, world!")
}

Pada step ini kita perlu merevisi code tersebut agar dapat membuka koneksi ke database yang sudah dibuat sebelumnya. Seperti code di bawah ini.

use sqlx::sqlite::SqlitePoolOptions;

#[tokio::main]
async fn main() -> Result<(), sqlx::Error> {
    let mut pool = SqlitePoolOptions::new()
        .max_connections(5)
        .connect("sqlite:db.sql")
        .await?;

    Ok(())
}

Pada code tersebut terdapat sebuah variable dengan nama pool, dimana variable ini menyimpan instance dari SqlitePoolOptions. Pool ini merupakan kumpulan koneksi yang masih terhubung ke database yang mana memiliki maximal 5 koneksi. Selain itu untuk dapat melakukan query ke database, diperlukan async/await. Maka perlu menambahkan macro tokio::main pada function main.

Selanjutnya perlu membuat struct yang nantinya digunakan sebagai result dari query_as dari sqlx.

use sqlx::{ prelude::FromRow, sqlite::SqlitePoolOptions};

#[derive(Debug, FromRow)]
struct User {
   id: i64,
   name: String
}

Gunakan struct tersebut sebagai type annotation Vec<User> pada result query, sehingga hasil dari query akan di-casting ke dalam bentuk Struct tersebut seperti ini

async fn main() -> Result<(), sqlx::Error> {
	...
	let result = query_as::<_, User>(r#"select * from users"#)
		.fetch_all(&pool)
		.await?;
	...
}

Maka secara keseluruhan function main akan seperti berikut

use sqlx::{ prelude::FromRow, sqlite::SqlitePoolOptions, query_as };

#[derive(Debug, FromRow)]
struct User {
    id: i64,
    name: String
}

#[tokio::main]
async fn main() -> Result<(), sqlx::Error> {
    let mut pool = SqlitePoolOptions::new()
        .max_connections(5)
        .connect("sqlite:db.sql")
        .await?;

    let result = query_as::<_, User>(r#"select * from users"#).fetch_all(&pool).await?;
    
    for item in result.iter() {
        println!("id: {}, name: {}", item.id, item.name);
    }

    Ok(())
}

Setelah semua tersetup, selanjutnya menjalankan cargo run untuk mendapatkan result.

$ cargo run
...
Compiling dbconn v0.1.0 (/tmp/dbconn)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.28s
     Running `target/debug/dbconn`
id: 1, name: Sample User

Kesimpulan

Untuk membuka koneksi dari Rust ke SQLite database bisa dengan mudah menggunakan package sqlx.

Git sederhananya merupakan simple Key-Value datastore, dimana hash dari content akan menjadi key untuk content itu sendiri. Baik itu hash dari content yang berisi meta commit, tree hash dan blob file. Setiap hash dalam git disebut dengan ObjectID, dimana dalam satu kali melakukan commit, git akan mengkalkulasi tiga hash sekaligus, yaitu hash untuk Meta Commit yang berisi message commit, tanggal commit dsb, lalu Tree Hash, dan Blob hash.

Tulisan ini adalah bagian dari Git SCM Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Sebagai contoh, kita coba membuat file bernama README.md yang berisi Sample Content README.md. Lalu kita add dan commit file tersebut dengan message commit Sample Commit Message. Setelah commit berhasil maka git akan memberikan hash SHA-1 yang merupakan hash dari content Meta Commit. Sebagai contoh seperti ini output hash seperti ini df5496d7e785b44e2beef9349cef4bc3b4b9ddc7 atau bisa juga dengan 7 character awal dari hash tersebut (df5496d). Hash adalah key dari commit message yang kita buat. Cara mengetahui isi key tersebut adalah dengan menggunakan git cat-file . Sebagai contoh seperti ini

$ git cat-file -p df5496d
tree 5ffea0e1130ea4ecf542691c3e066e51d8628233
author Verri <verri@local.host> 1736952966 +0700
committer Verri <verri@local.host> 1736952966 +0700

Sample Commit Message

Seperti pada output dari hasil cat-file, key tersebut berisi Meta Commit.

Terlihat pada line pertama terdapat tree <hash> dimana hash tersebut berisi line permission file, type object lalu nama object. Jika menggunakan git-cat-file untuk membaca hash tersebut. Maka outputnya kurang lebih akan seperti ini.

$ git cat-file -p 5ffea0e1130ea4ecf542691c3e066e51d8628233
100644 blob 50e0aa820aae2d872340d0a13b94b129a9f589a8    README.md

Karena object berupa file, maka type object akan menjadi blob tapi jika object merupaka folder, maka type object akan menjadi tree.

Pada output dari hasil cat-file hash dari tree, terdapat hash yang merupakan key dari content README.md. Bisa menggunakan cat-file untuk mendapatkan content dari key hash tersebut.

$ git cat-file -p 50e0aa820aae2d872340d0a13b94b129a9f589a8
Sample Content README.md

Terlihat dari output bahwa hash tersebut berisi snapshoot dari isi file README.md yang di-commit.

Karena Git menggunakan metode hashing untuk melakukan snapshoot setiap perubahan yang di-commit yang secara default menggunakan algorithm SHA-1, maka akan membuat git lebih flexible ketika didistribusikan karena dengan menggunakan metode ini, Git tidak akan tergantung pada machine yang digunakan.

Shared Repository

Repository dalam Git merupakan kumpulan snapshoot dan history dari setiap perubahan yang di-commit. Ketika developer melakukan snapshooting dan commit dari perubahan code, Git akan me-hashing file-file yang terubah tersebut dan menyimpannya dalam bentuk blob file type pada folder .git/objects. Directory .git tersebutlah yang kita sebut Local Repository. Selanjutnya ketika developer perlu mendistribusikan perubahan-perubahan tersebut, maka diperlukan sebuah destinasi dimana nantinya git akan mendistribusikan file-file pada repository local tersebut ke destinasi yang dituju, dimana destinasi tersebut disebut sebagai Shared Repostiory. Seperti gambar di bawah ini.

Dari gambar mungkin terlihat bahwa Git terkesan terpusat atau centralized. Tapi pada dasarnya karena Git menggunakan hashing sebagai metode untuk meng-signature setiap perubahan, sehingga memberikan kelebihan kepada Git untuk dapat decentralize / tidak terpusat. Developer bisa menambah berapapun remote repository yang diperlukan. Tergantung dari pada kesepakatan antar developer itu sendiri.

Sebagai contoh di sini, misal setiap developer bisa memiliki remote repository sendiri, ditambah satu buah remote repository master yang hanya boleh di-pull oleh developer. Dimana remote repository master ini sebagai tempat dimana semua feature yang stable dan sudah live di production.

Seperti terlihat pada gambar di atas. Terdapat satu master repository sebagai master repository, dimana maintainer / developer tidak memiliki hak untuk melakukan push ke master repository. Tapi setiap maintainer / developer hanya diperbolehkan melakukan push remote repository khusus developer. Dengan workflow seperti ini, maka setiap code yang masuk ke master repository akan terjaga secara history dan perubahan. Sedangkan pada remote repository masing-masing maintainer / developer dibebaskan untuk melakukan push biasa ataupun force push.

Histories dan snapshoot pada setiap Shared Repository bisa saja berbeda-beda, tergantung pada masing-masing developer. Misal Developer A hanya akan meng-update branch feature/sidebar pada shared repository B, begitu juga sebaliknya. Developer B mungkin hanya meng-update branch feature/header. Tapi bisa juga Shared Repository A atau pun Shared Repository B identik yaitu memiliki history dan jumlah Branch yang bener-benar sama. Kembali lagi semua tergantung pada kesepatakan antar developer yang terlibat.

Dengan kemampuan Git yang tidak terpusat, maka akan mempermudah developer untuk saling sharing code tanpa perlu khawatir dengan downtime dari Server.

reference:

• https://www.geeksforgeeks.org/introduction-to-hashing-2/

• https://git-scm.com/docs/hash-function-transition

• https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

Tulisan ini adalah bagian dari SOLID Principles Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Asumsi kita sudah membuat class untuk Notification dengan nama file NotifyEvent.ts dengan content seperti berikut:

class NotifyEvent {

    private email: string
    private phone: string
    private id: string
    private content: string

    static new(data: Record<string, any>) : NotifyEvent {
        const instance = new NotifyEvent
        instance.setEntity(data)
        return instance
    }

    setEntity(data: Record<string,any>) {
        this.id = data.id
        this.email = data.email
        this.phone = data.phone
        this.content = data.content
    }

    sendEmail() {
        // code untuk mengirim email
    }

    sendSMS() {
        // code untuk mengirim sms
    }

}

Class tersebut hanya memiliki tugas yang yaitu Notification. Tapi class ini bermasalah atau orang biasanya menyebutnya tidak fleksible. Kenapa? karena, seandainya kita ingin menambah fitur notifikasi baru untuk mengirim infomasi ke Telegram Messanger misalnya, maka kita harus merubah class tersebut untuk menambah method baru semisal bernama sendTelegram . Jika kita mengimplementasikan Prinsip OpenClose, Code class di atas akan menjadi seperti ini:

Pertama kita perlu melakukan abstraction agar semua method yang required, diharuskan diimplementasi. Kita bisa menggunakan abtract class atau kita bisa menggunakan Interface. Tapi pada tulisan ini saya akan menggunakan Class Abstraction. Tapi apa bedanya? Saya akan buat tulisan khusus untuk membahas itu. Berikut contoh abstract cclass yang kita gunakan.

abstract class NotifyEvent {
    abstract setProp(data: Record<string,any>): void
    abstract log(): Promise<void>
    abstract send(): Promise<boolean>
}

Buat class event yang extends dari class NotifyEvent tersebut. Sebagai contoh di sini akan membuat event notifier untuk SMS.

class NotifySMSEvent extends NotifyEvent {
    private phone: string

    static new(data: Record<string,any>): NotifyEvent {
        const instance = new NotifySMSEvent
        instance.setProp(data)
        return instance
    }

    setProp(data: Record<string, any>) {
        // set property
    }

    async log() {
      // Log to database
    }

    async send() {
        // Send Code di sini
    }
}

Lalu kita buat dispatcher class atau executor untuk notifier SMS diatas.

class NotifyDispatcher {
    private events: NotifyEvent[] = []; 

    async execute() {
      const events: any[] = []
      for(let e of this.events) {
         events.push(e,send(), e.log())
      }
      return Promise.all(events)
    }    

    pushEvent(event: NotifyEvent) {
        this.events.push(event)
    }
}

Class dipatcher inilah yang seharusnya ada pada bagian core dengan tujuan agar tidak ada perubahan pada core atau module utama ketika business menginginkan penambahan feature untuk notification.

Selanjutnya pada function utama, kita perlu untuk meng-initialisasi class-class diatas. Seperti berikut.

function main() {
        const data = {} 
        const event: NotifyEvent = NotifySMSEvent.new(data)

        const dispatcher= new NotifyDispatcher
        dispatcher.pushEvent(event)

        await dispatcher.execute()
}

Kesimpulan

Dengan mengimplementasikan OCP, maka program akan lebih flexible dalam melakukan pergantian usecase module yang akan digunakan.

references:

• https://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object Oriented Software Construction.pdf

• https://stackify.com/solid-design-open-closed-principle

Tulisan ini adalah bagian dari Git SCM Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Metode untuk membuat remote repository pada VPS sama seperti saat membuat remote repository pada lokal folder. Perbedaannya, ketika kita men-setup Remote repository pada server, maka untuk kita dapat melakukan cloning repository tersebut ke lokal device, kita perlu cloning menggunakan SSH. Namun sudah bisa dipastikan setiap kita menyewa VPS, pasti sudah terdapat SSH Server. Sehingga yang perlu kita setup hanya Git Command di VPS yang kita sewa.

Untuk mengginstall git command cukup dengan mejalankan command di terminal server seperti berikut.

Menggunakan Apt Command

$ sudo apt update
$ sudo apt install -y git

Menggunakan Yum / dnf

$ sudo yum update
$ sudo yum install git

Jika GIt Command sudah berhasil diinstall, selanjutnya kita perlu membuat bare repository di VPS. Langkahnya sama seperti pada bare repository pada lokal.

$ mkdir -p /opt/repos/code.git
$ cd /opt/repos/code.git
$ git init --bare

Ketika mencoba clone repository tersebut, maka bisa melakukan clone ke local device dengan menggunakan SSH Authentication. Sebagai contoh di sini, user ssh menggunakan user root dengan contoh public IP server 10.0.2.1. Maka command untuk clone adalah seperti ini

$ git clone root@10.0.2.1:/opt/repos/code.git code

Kita juga bisa menambahkan remote repository tersebut pada workspace git yang sudah ada di lokal device. Sebagai contoh kita menggunakan workspace code yang sudah dibuat sebelumnya yaitu /tmp/sample. Maka untuk menambahkan remote repository yang ada di VPS bisa dengan menjalakan command berikut.

$ cd /tmp/sample
$ git remote add vps root@10.0.2.1:/opt/repos/code.git

Untuk push semua commit yang sudah dibuat pada workspace tersebut maka tinggal menjalankan command dengan format git push [nama remote repo] [nama branch]. Pada contoh di sini nama branch yang ada adalah main. Maka untuk push ke remote repository bisa dengan cara seperti di bawah ini.

$ git push vps main

Sampai pada tahap ini, kita berhasil membuat remote repository di VPS. Tapi terasa kurang nyaman ketika melakukan push ke Remote Repository, karena setiap melakukan push, kita perlu memasukan password SSH.

Tulisan ini adalah bagian dari SOLID Principles Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Seperti yang terlihat pada flow pada di atas, ketika pengguna selesai memilih produk, maka Vending Machine akan mengupdate info stock dan mengirim notifikasi ke admin dashboard. Jika diubah ke dalam bentuk code, maka programmer kurang lebih akan membuat code seperti ini.

class OrderService {

    async execute(dto: RequestDTO) {}

    validatePayload(dto: RequestDTO) {
        // Memvalidasi setiap key dan value yang dikirim dari sisi client
    }

    async getProduct() {
        // Meng-query database langsung disini untuk mendapatkan info product
    }

    calculateNewAvailableStock() {
        // Mengurangi jumlah stock
    }

    async saveUpdateStock() {
        // Meng-query database untuk menyimpan perubahan di database
    }

    async sendNotifyAdmin() {
        // Mengirim notifikasi ke email atau sms
    }
}

Seperti yang terlihat pada code di atas, class tersebut memiliki banyak tugas di dalamnya, sehingga class tersebut tidak memiliki kejelasan tugas pokoknya. Query ke sql, notifikasi dan logic usecase order ada dalam satu class mengakibatkan class tersebut terlihat kompleks. Akan menjadi lebih kompleks jika feature semakin banyak akibat dari keharusan aplikasi untuk mengikuti perkembangan bisnis dari perusahaan tersebut. Semakin kompleks sistem, jika tidak di-manage dengan baik, maka akan menjadi lebih sulit untuk tracing issue ketik terjadi error.

Akibat yang sering terjadi adalah, programmer akan kurang percaya diri atau khawatir ketika code tersebut akan dideploy ke production. Lebih jauh lagi, karena terlalu kompleks, akhirnya programmer memutuskan untuk merubah keseluruhan class tersebut, yang akan membuat probabilitas error pada program semakin besar. Akan memperparah probabilitas error dengan tidak adanya unit test atau integration test.

Lalu bagaimana agar code tersebut agar mudah dimaintain/diurus? Yaitu dengan cara memisahkan logic menjadi class-class yang sesuai dengan tugasnya. Seperti code ini.

class OrderUsecase {
    async execute(dto: OrderRequestDTO): Promise<OrderResponseDTO> {}
    validate(dto: OrderReqeustDTO): boolean {}
    async getStock(id: number): Promise<ProductEntity> {}
    calculateStock(product: ProductEntity) {}
}

class OrderRepository {
    async getProductById(id: number): Promise<ProductEntity> {}
    async updateProduct(id: number, product: ProductEntity): Promise<ProductEntity> {}
}

class OrderNotification() {
    async sendAsWebsocket() {}
    async sendAsSMS() {}
}

Bisa kita lihat dari code di atas, setiap class sekarang memiliki tugasnya yang lebih spesifik. Misal class OrderUsecase hanya memiliki satu tugas untuk alur utama usecase order, untuk class OrderRepository digunakan khusus untuk yang berhubungan dengan database, dan untuk class OrderNotification tugasnya hanya yang berhubungan dengan notifikasi. Sebagaimana syarat SRP, class hanya boleh miliki satu tugas saja.

Lalu dimisalkan perlu perubahan pada logic khusus Order Usecase, berarti programmer hanya perlu merubah class OrderUsecase saja, tidak perlu merubah class lain. Jika ingin merubah yg berhubungan dengan database, berarti yang dirubah bukan class OrderUsecase melainkan OrderRepository. Sesuai dengan syarat SRP, class hanya boleh dirubah karena satu alasan saja.

Kesimpulan

Single Responsibiliy Princple akan memperjelas tugas dari setiap class. Semakin jelas tugas sebuah class, maka akan semamkin mempermudah programmer ketika akan melakukan tracing masalah.

Selanjutnya akan membahas tentang point ketiga dari SOLID, yaitu Open Closed Principle

reference:

• http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Jadi seperti apa itu SOLID ? saya akan coba detailkan satu persatu di tulisan yang saya buat ini untuk setiap prinsip-prinsip pada setiap huruf pada SOLID.

Tulisan ini adalah bagian dari SOLID Principles Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

SOLID merupakan sebuah singkatan dari beberapa prinsip, yaitu:

• S - Single Responsibility Principle

• O - Open Closed Principle

• L - Liskov Subtition Principle

• I - Interface Segregation Principle

• D - Dependency Inversion Principle

Selanjutnya akan membahas tentang point pertama dari SOLID, yaitu Single Responsibility Principle.

Tulisan ini adalah bagian dari Git SCM Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Dari yang saya amati, sampai saat ini masih banyak programmer yang berfikir bahwa untuk bisa mendistribusikan code menggunakan Git, harus menggunakan layanan seperti Github, Gitlab, Bitbucket atau yang menggunakan self-manage git server seperti Gogs atau sejenisnya. Tapi ternyata, membuat git remote repository bisa menggunakan local folder pada device atau VPS dengan SSH. Berikut ini adalah langkah-langkahnya.

Shared Repository di Local Drive

Sedikit mengklarifikasi istilah dalam Git seperti repository pada Git adalah kumpulan snapshoot dari perubahan-perubahan pada directory workspace yang di-commit oleh developer. Commit itu sendiri merupakan cara developer melakukan snapshoot pada setiap perubahan yang terjadi pada workspace. Pada section ini kita coba membuat Shared Repository dengan hanya membedakan directory.

Sebelum masuk ke bagaimana cara men-setup shared repository, kita perlu mempersiapkan dulu folder yang berisi git yang akan kita push ke Shared Repository dengan langkah seperti berikut.

Buat folder baru dan tambahkan file README.md pada folder tersebut.

$ mkdir /tmp/sample
$ cd /tmp/sample
$ echo "# Initial Git Workspace" > README.md

Init folder tersebut sebagai git dan commit file README.md tersebut.

$ git init .
$ git add .
$ git commit -am "Initialize project"
$ git status

Setelah git status dijalankan, maka pada terminal akan tampil informasi current branch dimana defaultnya adalah branch main.

Sederhananya, membuat local Shared Repository itu sama seperti saat mempersiapkan code yang akan dipush ke repository pada langkah sebelumnya. Tapi bedannya, pada saat initial git pada folder tersebut, perlu menambahkan option --bare. Seperti berikut.

$ mkdir -p /opt/repos/code.git
$ cd /opt/repos/code.git
$ git init --bare

Berdasarkan official documentation mengenai option --bare.

Create a bare repository. If GIT_DIR environment is not set, it is set to the current working directory.

Bahwa option --bare digunakan untuk membuat Shared Repository baru yang masih kosong. Jika GIT_DIR tidak diset, maka git akan men-set repository baru tersebut pada direktori dimana cursor berada saat perintah git init dijalankan.

Selanjutnya hanya perlu meset Shared Repository config pada folder code yang sudah dipersiapkan sebelumnya. Dengan langkah seperti berikut.

$ cd /tmp/sample
$ git remote add origin /opt/repos/code.git
$ git push origin main

Jika kita coba melakukan clone dari folder git repository tersebut, maka kita akan langsung mendapatkan file README.md yang sudah kita commit pada folder /tmp/sample.

$ cd /tmp/
$ git clone /opt/repos/code.git code
$ ls code
README.md

Tulisan ini adalah bagian dari Remote SSH Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Pada tulisan dengan title Alias untuk Remote SSH, kita sudah mencoba membuat alias domain untuk SSH agar lebih simple ketika akan meremote server. Hanya dengan command ssh repository.aws, SSH sudah bisa mengetahui config apa yang harus digunakan. Tapi kita masih ada masalah di config SSH pada local device.

Kita sudah mengetahui bahwa untuk mengconfig alias domain pada SSH dengan menambah Host baru pada file ~/.ssh/config.

Host repository.aws
    User root
    IdentityFile ~/.ssh/id_ed25519

Tapi ketika kita perlu menambah destination host baru yang memerlukan key yang sama kita harus menambah list Host tersebut ke list yang sama misal seperti ini.

Host repository.aws web.aws api.aws
    User root
    IdentityFile ~/.ssh/id_ed25519

Semakin banyak destination server, semakin panjang list-nya. Cukup merepotkan bukan?!

Nah pada tulisan sebelumnya dengan title “Alias untuk Remote SSH” saya menyarankan sebaiknya menggunakan extesion domain. Karena untuk keperluan multi destination seperti ini. Dengan menggunakan extension domain, akan mempermudah kita melisting host alias. Sebagai contoh seperti ini.

Host *.aws
    User root
    IdentityFile ~/.ssh/id_ed25519

Dengan menggunakan asterick (*), maka semua alias host dengan menggunakan extension .aws akan menggunakan config tersebut. Tapi bisa saja menggunakan IP Address, misalkan seperti ini.

Host 192.168.*
    User root
    IdentityFile ~/.ssh/id_ed25519

Tapi jika menggunakan IP Address, jelas kita akan sulit mengingatnya. Maka dari itu perlu alias host agar lebih mudah mengingat destination nya.

Kesimpulan

Dengan menggunakan asterisk (*), kita bisa mengernalkan config ssh. Dengan begitu akan lebih mudah memaintain IdentityFile untuk tiap-tiap host.

Tulisan ini adalah bagian dari Remote SSH Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Pada tutorial sebelumnya dengan title SSH tanpa Password sudah dijabarkan step by step bagaimana cara mensetupnya. Pada tulisan kali ini saya akan menunjukan bagaimana membuat agar kita bisa melakukan autentikasi ke server dengan command lebih sederhana. Misal seperti ini.

$ ssh repository.aws

Seperti terlihat dari contoh command ssh tersebut, tidak ada user, ip address dan juga identity file (-i) yang diikutkan sebagai argument command.

Dengan cara ini, maka user, IP Address dan juga identity File tidak kan tercatat pada history terminal history -c kemana user melakukan remote ssh.

Untuk bisa membuat seperti itu, pertama yang perlu dilakukan adalah dengan mambuat alias domain di file /etc/hosts.

$ echo "repository.aws\\t10.2.0.2" | sudo tee -a /etc/hosts

Pada command tersebut saya menggunakan repository.aws sebagai domain, nama alias domain ini bebas, bisa apa saja. misal kita bisa menggunakan nama repository, tanpa domain extention. Hal tersebut sah-sah saja. Namun lebih baik menggunakan extension karena ada keunggulan yg nantinya akan saya jelaskan pada tulisan ini juga.

Untuk IP address, saya menggunakan destination ip address 10.2.0.2. Dimana IP ini seharusnya IP Address dari remote server yang akan diremote.

Setelah selesai menambah alias dari IP Address tersebut. Kita bisa memvalidasi apakah alias sudah ter-setup dengan bensar, dengan cara ping ke domain baru tersebut.

$ ping repository.aws
64 bytes from 10.2.0.2: icmp_seq=0 ttl=64 time=0.108 ms
64 bytes from 10.2.0.2: icmp_seq=1 ttl=64 time=0.160 ms
64 bytes from 10.2.0.2: icmp_seq=2 ttl=64 time=0.162 ms
64 bytes from 10.2.0.2: icmp_seq=3 ttl=64 time=0.175 ms

Terlihat bahwa response memberikan info from 10.2.0.2 menandakan bahwa domain sudah tersetup dengan benar. Langkah selanjutnya menambah config untuk SSH pada file ~/.ssh/config untuk domain baru. Seperti berikut.

Host repository.aws
    User root
    IdentityFile ~/.ssh/id_ed25519

Sampai langkah ini, short SSH command sudah bisa dilakukan. Jika kita mengeksekusi command ssh seperti berikut:

$ ssh repository.aws

Maka kita akan mendapatkan shell dari remote server yang dituju.

Kesimpulan

Kita bisa menyebunyikan argument-argument pada command ssh dengan men-config file ~/.ssh/config dengan begitu, akan lebih memudahkan kita sebagai commander yang mengeksekusi command ssh tersebut karena kita hanya perlu mengingat nama alias dari pada harus mengingat IP Address dan argument-argument lainnya.

Tulisan ini adalah bagian dari Remote SSH Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Me-remote device atau khususnya server biasa dilakuan oleh programmer untuk melakukan deploy aplikasi atau sekedar untuk mencopy file dari local device ke remote device. Protocol yang digunakan biasanya adalah SSH (Secure Shell) baik untuk mendapat akses shell dari target device atau untuk sekedar mengcopy file. biasa bisa menggunakan FTP (File Transfer Protocol) hanya saja untuk FTP tidak disarankan karena masalah keamanannya. Lebih disarankan menggunakan SFTP yang memanfaatkan protocol SSH untuk mentransfer data karena dinilai lebih aman.

Pada umumnya kita akan me-remote shell ke PC atau server menggunakan cara menjalankan command seperti ini ssh verri@10.2.0.2. Setelah itu terminal akan meminta kita untuk input password. Setelah kita menginput password, maka kita akan mendapatkan shell dari Remote Device. Tapi bagaimana jika kita ingin mengremote server tanpa password dan juga tanpa mengikutkan user account pada command ssh. Saya akan jelaskan caranya pada tulisan ini.

Generate SSH Key Pairs Baru

Langkah pertama sebelum meng-config ssh yaitu kita perlu men-generate ssh key pairs dengan menggunakan ssh-keygen. Tapi sebelum itu lebih baik kita membuat direktori baru di folder /home/user/.ssh. Sebagai contoh disini saya menggunakan nama direktory remote.

$ mkdir ~/.ssh/remote
$ cd ~/.ssh/remote
$ ssh-keygen -t rsa -b 1024 -C verri@ndriawan

Generating public/private ed25519 key pair.
Enter file in which to save the key (/tmp/keys/id_ed25519):

Pada baris Enter file blablbla, kita diminta untuk menginputkan file path dimana key baru akan distore. Jika pada contoh output di atas, default path akan distore di /tmp/keys dengan nama file id_ed25519. Tapi karena kita sudah membuat folder baru ~/.ssh/remote maka kita bisa inputkan lokasi file keys pada folder tersebut seperti ini ~/.ssh/remote/id_ed25519. Lalu tekan Enter.

Berikut Informasi options dari command:

• -t : Type key yang dipilih, secara default, type key akan memilih RSA. tapi pada contoh menggunakan ed25519.

• -b: Panjang bits key, yang dimana pada contoh 1024. Tapi options ini akan di-ignore atau tidak digunakan untuk type key ras, beda dengan RSA yang key lengthnya dinamic dan minimal secure bits-nya adalah 1024.

• -C: adalah comment, saya menambahkan commit verri@ndriawan sebagi penanda bahwa key itu milik si pembuat key.

Selanjutnya akan muncul pada prompt meminta kita untuk meinputkan password. Kita bisa menginputkan password yang kita inginkan. Tapi password ini optional, jadi tidak menginputkan password pun tidak masalah untuk kepentingan yang tidak terlalu memerlukan keamanan. Kurang lebih output pada terminal akan seperti ini.

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ~/.ssh/remote
Your public key has been saved in ~/.ssh/remote/id_ed25519.pub
The key fingerprint is:
SHA:blabla verri@ndriawan
The key's randomart image is:
+---[RSA 1024]----+
|  ..==o.         |
|=...             |
|o                |
+----[SHA256]-----+

Pada contoh key yang digenerate di atas, key akan menggunakan id_ed25519. Penamaan ini bebas. Pengguna bisa mengenerate key pairs dengan nama apa saja. Baiknya penamaan sesuaikan dengan kebutuhan saja.

Setelah generate selesai, maka seharusnya akan ada dua file yang terbuat, yaitu file id_ed25519 dan file id_ed25519.pub. Content dari file id_ed25519.pub inilah yang akan didistribusikan ke server nantinya.

Alur koneksi SSH

Ketika membuka koneksi, SSH akan memastikan pada file ~/.ssh/config apakah destination host ada di dalam config tersebut atau tidak. Jika tidak, maka ssh akan meminta kita sebagai commander untuk mengikutkan argument-argument pada command yang akan dieksekusi. tetapi jika config tersebut ada, maka ssh akan menggunakan config tersebut. Jika kita buka file ~/.ssh/config, isi dari file tersebut kurang lebih ssh config pada sisi client akan terlihat seperti ini.

Host 10.2.0.2
  User root
  IdentityFile ~/.ssh/id_ed25519

Jika kita translate config tersebut ke dalam bentuk command, maka kurang lebih akan menjadi seperti ini.

$ ssh -i ~/.ssh/id_ed25519 root@10.2.0.2

Dimana option (-i) adalah identity file yang merupakan file private key yang digunakan untuk autentikasi. Seperti itulah alur pada sisi client.

Selanjutnya alur pada sisi server, ketika ada permintaan koneksi dari client dengan menggunakan protocol SSH seperti pada contoh sebelumnya, server akan melakukan verifikasi pair key yang ada pada file ~/.ssh/authorized_keys berdasarkan identity file yang diikutkan pada command ssh. Jika pair key dari id tersebut terdaftar pada file authorized_keys, selanjutkan secara sederhananya server dan client akan saling mengautentikasi sehingga akhirnya client mendapatkan shell dari server.

Distribusi Key

Setelah memahami cara autentikasi protocol SSH, maka selanjutnya yang perlu kita lakukan adalah mendistribusikan public key yang sudah dibuat sebelumnya ke server dengan menggunakan contoh command dibawah ini.

$ cat ~/.ssh/id_ed25519.pub | ssh root@10.2.0.2 "cat - >> /root/.ssh/authorized_keys"

lalu coba melakukan koneksi ke server menggunakan command ssh seperti ini

$ ssh -i ~/.ssh/id_ed25519 root@10.2.0.2

Jika berhasil, maka terminal dimana kita menjalankan command SSH tersebut akan mendapatkan shell dari server. Tapi jika gagal melakukan autentikasi, maka yang perlu dilakukan adalah coba merubah mode folder ~/.ssh pada server ke permission 700 dan juga untuk file ~/.ssh/authorized_keys pada server ubah ke mode 600. sebagai contoh command seperti berikut

$ chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

Selanjutnya coba login ke remote server lagi menggunakan command ssh seperti sebelumnya.

Kesimpulan

SSH adalah protocol aman yang digunakan untuk komunikasi antara dua node. SSH menggunakan berbagai algoritma enkripsi untuk mengauentikasi antar node. Selain menggunakan credential dari host untuk mengautentikasi antar node, SSH juga bisa menggunakan pair keys. Sehingga pengguna tidak perlu menginputkan password ketika mengauntentikasi dengan server. Dengan begitu, password akan tetap terjaga karena tidak akan sering ditransfer dari client ke server. Mengurangi resiko MITM atau keylogger.