DEV Community: Bagas Hariyanto

Co-Learning Camp Arbitrum Week 2 Journey

Bagas Hariyanto — Fri, 06 Feb 2026 05:53:07 +0000

Entering the second week of the Co-Learning Camp by HackQuest, I dove deep into the world of Arbitrum Stylus. My journey began with the Stylus SDK, where I learned to bridge the gap between Rust and smart contracts. Setting up the environment felt like unlocking a new superpower, as I successfully built a basic Counter contract, witnessing firsthand how WASM makes on-chain execution faster.

The path grew more exciting as I moved toward hands-on examples. I transitioned from simple data storage to building a Greeting contract and a more complex Voting system. Mastering the use of StorageMap to track voters and managing Rust-specific errors taught me how to handle state efficiently. Every successful compilation felt like a victory, bringing me closer to mastering high-performance dApps.

In the final stretch, I tackled the core of DeFi: token standards. Implementing ERC-20 and ERC-721 in Rust required precision, especially when managing dependencies and storage layouts. Deploying my first custom token to the Arbitrum Sepolia testnet was a defining moment. With these new skills in my toolkit, I am now ready to face the Mini Hackathon and turn these concepts into reality.

Co-Learning Camp Arbitrum Week 1 Journey

Bagas Hariyanto — Sun, 01 Feb 2026 15:41:41 +0000

I started my journey at the Arbitrum Co-Learning Camp hosted by HackQuest.io, eager to dive into the world of Web3. Starting with the basics, I explored how Arbitrum serves as a Layer 2 scaling solution for Ethereum. Understanding the fundamentals of optimistic rollups was my first step toward mastering this ecosystem and contributing to its growing community of developers.

As the curriculum progressed, I transitioned from Arbitrum Classic to its advanced iterations: Arbitrum One and Arbitrum Nova. It was fascinating to learn how One handles DeFi with full security, while Nova offers ultra-low fees for gaming and social apps using AnyTrust technology. This distinction helped me see how different projects choose the right chain for their specific needs.

I then delved into Arbitrum Orbit, a framework for launching dedicated L3 chains. The idea of having a customizable, private blockchain that still benefits from Ethereum's security is revolutionary. Mastering Orbit opened my eyes to the future of hyper-scaling, where specialized chains can cater to massive user bases without congesting the network or increasing transaction costs.

A major highlight was exploring Arbitrum Stylus. Moving beyond Solidity, I began learning Rust fundamentals for Web3 development. The Stylus SDK allows for writing smart contracts in Rust, which is significantly more efficient. This "next-gen" programming approach promised faster execution and lower gas, making high-performance dApps a reality on the Arbitrum network.

Finally, I put theory into practice with hands-on examples and the Stylus SDK. Building my first simple projects and seeing code execute on-chain was rewarding. This practical experience at the camp solidified my skills, transforming me from a curious learner into a developer ready to build the next generation of decentralized applications in the Arbitrum ecosystem.

Reflection of Co-Learning Mantle week 2

Bagas Hariyanto — Sun, 21 Dec 2025 19:30:08 +0000

After week 1 we learning about basic of Solidity and how to make and deploy smart contract, now we learn about Real World Asset (RWA).

1. What exactly is RWA? (The Digital Mirror)

At its core, Real World Assets (RWA) are digital representations of physical or financial assets (like real estate, gold, or government bonds) on the blockchain. This process is called tokenization.

The most exciting part for me was seeing how RWA solves "old world" problems. In Traditional Finance (TradFi), investing in a commercial building requires millions of dollars. Through RWA, we can have Fractional Ownership, allowing someone to buy a "piece" of a property for as little as $10.

2. The Legal Puzzle: Token vs. Title

One of the biggest questions I had was: "Does owning a token legally mean I own the asset?" The module explains that this depends on the Legal Structuring. I learned about three main models:

SPV (Special Purpose Vehicle): A company holds the asset, and the token represents shares in that company.

Direct Ownership: The law directly recognizes the token as the title deed (common in crypto-friendly hubs like Switzerland).

Contractual Claims: The token acts as a contract between the holder and a custodian (common for gold-backed tokens).

For those of us in Indonesia, it’s fascinating to see the OJK (Financial Services Authority) developing frameworks to regulate these digital securities by 2025.

3. Why Mantle Network for RWA?

Choosing the right blockchain is critical for RWA because these projects require high security and low costs. Mantle Network stands out to me for a few reasons:

Efficiency: Its modular architecture keeps transaction fees low, which is essential when you are dealing with small fractional investments.

Institutional Grade: Mantle provides the performance needed for high-frequency trading of tokenized assets.

The Ecosystem: With initiatives like the Mantle Global Hackathon (offering $150k in prizes), there is a massive push to make Mantle the go-to home for "RealFi."

4. Technical Standards & Compliance

Unlike a standard ERC-20 token that anyone can send to anyone, RWA tokens must be "smart" enough to follow the law. I learned about:

ERC-3643: A standard that ensures tokens can only be transferred to users who have passed KYC (Know Your Customer) verification.

Oracles (Chainlink): These provide the "bridge" for data, ensuring the price of the asset on-chain matches the real-world market value.

Proof of Reserve (PoR): A way to prove on-chain that the physical gold or cash actually exists in a vault.

5. Practical Application: The IndonesiaPropertyToken

The most hands-on part of the course is the challenge to build the IndonesiaPropertyToken. This project involves creating a decentralized application (DApp) that allows users to invest in Indonesian real estate.

The Mission: Integrate a KYC Registry with a Property Token contract.

The Goal: Ensure transparency, liquidity, and 24/7 trading for assets that were previously "locked" behind high barriers to entry.

Final Thoughts: The Road Ahead
The RWA market is projected to reach $10–30 trillion by 2030. Learning this now feels like being at the start of a massive wave. The Mantle Co-Learning Camp doesn't just teach you how to code; it teaches you how to rebuild the global financial system.

(#LearnwithHQ #14DaysOfLearning)

Reflection of Co-Learning Mantle week 1

Bagas Hariyanto — Sun, 14 Dec 2025 14:59:12 +0000

In this blog I want to share a reflection of Co-Learning Mantle. This co-learning is held by Hackquest, a platform to learn about Web3. The participant expected to learn and build a web3 project using Mantle Network. Mantle is a L2 ETH Mantle is a Web3 ecosystem built on Ethereum that positions itself as the “Liquidity Chain of the Future,” combining modular blockchain design, zero-knowledge (ZK) proofs, and a large treasury governed by token holders.

In the first day there is Town Hall for boarding toward Co-Learning Mantle, we learn about Hackquest platform, what is Mantle and the difference between L1 and L2 ETH network. Layer 1 Eth (L1) is mainnet of ETH networks that base of the blockchain itself, it run the smart-contract directly, provides security through Proof of Stake consensus, and tores all transaction data permanently. But has high gas fees during congestion, Scalability bottlenecks due to every node needing to process every transaction. The Layer 2 Eth (L2) created to fix that weakness like Much lower fees, Higher throughput (hundreds to thousands of TPS), and inherits Ethereum’s security guarantees.

On the second Town Hall we Learn about basic Solidity. Solidity is programming language that used to create Smart-Contract. We learn about type data, struct & enum, Mapping & Array, Modifier & Event, Payable & Time-Based. We also learn to implement that to a simple Smart-Contract project using Remix.

On the Third Town Hall we learn about Foundry. Foundry is a fast, modular Ethereum development framework written in Rust that helps developers build, test, and deploy Solidity smart contracts efficiently. We learn to build a EduLoan project, a smart contract project that use to lending a money to student, the project can be topup by admin, can transfer the fund to student wallet address, and the student can repay the loan with interest. The project is deployed on Mantle Netwrok.

#LearnwithHQ #14DaysOfLearning

14 Days Journey Learn Web3

Bagas Hariyanto — Mon, 17 Nov 2025 09:12:58 +0000

I just completed an intensive 14-day dive into Web3, and it's incredible how much I've learned. I went from understanding the basic concepts to actually building my own tokens. Here’s a breakdown of my journey and what I mastered over the two weeks.

Week 1: Mastering Solidity & Smart Contract Fundamentals

My first week was all about building a strong foundation. I focused on Solidity, the primary programming language for the Ethereum blockchain.

Setting Up My Environment: First, I got my tools ready. I learned to use the Remix IDE, a fantastic browser-based tool for writing and testing contracts. I also set up my MetaMask wallet to interact with the network and used a Sepolia faucet to get free "test" ETH. This was crucial so I could deploy contracts without spending real money.

Solidity 101 (The Basics): I started with the essential building blocks of the language. I now understand the core data types:

string: For text.

uint256: The standard for numbers, like IDs or balances.

bool: For simple true/false values.

address: A special type for holding Ethereum wallet addresses, including the critical msg.sender (who is calling the function).

Organizing Complex Data: Once I had the basics, I learned how to structure data effectively.

struct: This was a breakthrough. It lets me create my own custom data types, like a Student struct that groups an ID, name, and wallet address.

mapping: This is the most common way to store and retrieve data. I learned to think of it as a "dictionary" that links a key (like a student ID) to a value (like their Student struct).

enum and array: I also learned to use enums for predefined states (like Active or Graduated) and arrays for dynamic lists.

Contract Logic & Security: Finally, I learned how to make my contracts do things and how to keep them safe.

require(): This is my most important security tool. I learned to use it to check conditions (like require(balance >= amount)) before allowing a function to continue.

modifier: I learned how to create reusable checks, like the classic onlyOwner modifier, to lock down administrative functions.

event: I learned how contracts "talk" to the outside world by emitting events, which are essential for any user interface.

payable: I now know how to write functions that can receive Ether.

By the end of week one, I had successfully written, deployed, and interacted with my own StudentRegistry smart contract. I was no longer just reading about blockchain; I was writing to one.

Week 2: Building My Own Tokens (ERC20 & ERC721)

In my second week, I took my new Solidity skills and applied them to one of the most exciting parts of Web3: tokens. I focused on the two main standards.

Part 1: ERC20 (Fungible Tokens):

I learned that ERC20 is the standard for "fungible" tokens, where every token is identical, like a dollar bill. This is what stablecoins (USDT) and utility tokens (LINK) use.

I built my own ERC20 token from scratch. This was a fantastic exercise where I had to implement:

A mapping (using balanceOf) to track how many tokens each wallet holds.

A transfer function to let users send tokens to each other.

The approve and transferFrom flow. This was a key concept, as it's what allows other smart contracts (like decentralized exchanges) to spend tokens on my behalf.

Part 2: ERC721 (Non-Fungible Tokens - NFTs):

Next, I tackled ERC721, the standard for NFTs. I learned that "non-fungible" means each token is unique and has a specific owner, identified by a tokenId.

This was the most fun part. I built my own CryptoKitty-style NFT contract. This was more complex and taught me to:

Use a mapping (for ownerOf) to track the owner of each unique NFT.

Write a _mint() function to create new NFTs, often with unique properties.

Implement safeTransferFrom to securely transfer NFT ownership.

I even experimented with a breed() function to create a new, unique NFT from two "parent" NFTs.

Putting It All Together: OpenZeppelin

Finally, I learned the most important lesson for real-world development: don't write these from scratch in production!

I was introduced to OpenZeppelin Contracts, a library of secure, audited, and optimized smart contracts. I learned how I can create a production-ready ERC20 or ERC721 token in just a few lines of code by simply importing from their library. This is how I'll build projects moving forward.

After this 14-day journey, I've gone from being a curious outsider to someone who has successfully built and deployed their own fungible tokens and NFTs. I have a solid, practical skill set and I'm excited to keep building in Web3.

ERC20 in Web3 Smart Contract

Bagas Hariyanto — Sun, 16 Nov 2025 14:32:31 +0000

Token standard is essential in Web3 Smart Contract development because it ensure Interoperability, compatibility, Security and Community. That mean the smart contract can be used on all Dapp, have compatibility to any Wallet for example Metamask, follow security standard that safe and tested, also has maintained tools and library to develop it. In this article I want to share about Token standard in Web3, ERC20 or known as Fungible Token.

ERC20

ERC20 also known as Fungible Token is a standard to make a Token that can be tradeable (Fungible), and each Token has the same value. The example of this Token in real-life is USDT, BNB, etc.

ERC20 Interface

Each ERC20 token must have this function:

interface IERC20 {
    // Total supply token
    function totalSupply() external view returns (uint256);

    // Balance dari address
    function balanceOf(address account) external view returns (uint256);

    // Transfer token
    function transfer(address to, uint256 amount) external returns (bool);

    // Approve spending
    function approve(address spender, uint256 amount) external returns (bool);

    // Check allowance
    function allowance(address owner, address spender) external view returns (uint256);

    // Transfer from (by approved spender)
    function transferFrom(address from, address to, uint256 amount) external returns (bool);

    // Events
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

Setup Contract

Make a file named FungibleToken.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

/**
 * @title FungibleToken
 * @dev ERC20 Token implementation from scratch
 */
contract FungibleToken {
    // Token metadata
    string public name;
    string public symbol;
    uint8 public decimals;

    constructor() {
        name = "My First Token";
        symbol = "MFT";
        decimals = 18;
    }
}

Define Key Variables

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

contract FungibleToken {
    string public name;
    string public symbol;
    uint8 public decimals;

    // Total supply token yang ada
    uint256 public totalSupply;

    // Mapping address -> balance
    mapping(address => uint256) public balanceOf;

    // Mapping owner -> spender -> amount
    // Untuk approve mechanism
    mapping(address => mapping(address => uint256)) public allowance;

    constructor() {
        name = "My First Token";
        symbol = "MFT";
        decimals = 18;
    }
}

Event and Basic Mint

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

contract FungibleToken {
    string public name;
    string public symbol;
    uint8 public decimals;
    uint256 public totalSupply;

    mapping(address => uint256) public balanceOf;
    mapping(address => mapping(address => uint256)) public allowance;

    // Events (wajib untuk ERC20!)
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);

    constructor() {
        name = "My First Token";
        symbol = "MFT";
        decimals = 18;
    }

    /**
     * @dev Mint new tokens
     * @param _to Address yang menerima token
     * @param _amount Jumlah token (dalam wei)
     */
    function mint(address _to, uint256 _amount) public {
        // Validasi input
        require(_to != address(0), "Mint to zero address");
        require(_amount > 0, "Amount must be greater than 0");

        // Update state
        totalSupply += _amount;
        balanceOf[_to] += _amount;

        // Emit event
        emit Transfer(address(0), _to, _amount);
    }
}

Access Control

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

contract FungibleToken {
    string public name;
    string public symbol;
    uint8 public decimals;
    uint256 public totalSupply;

    address public owner;

    mapping(address => uint256) public balanceOf;
    mapping(address => mapping(address => uint256)) public allowance;

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);

    // Modifier untuk restrict ke owner
    modifier onlyOwner() {
        require(msg.sender == owner, "Only owner can call this");
        _;
    }

    constructor() {
        name = "My First Token";
        symbol = "MFT";
        decimals = 18;
        owner = msg.sender;

        // Mint initial supply ke owner
        _mint(msg.sender, 1000000 * 10**decimals); // 1 juta token
    }

    /**
     * @dev Internal mint function
     */
    function _mint(address _to, uint256 _amount) internal {
        require(_to != address(0), "Mint to zero address");

        totalSupply += _amount;
        balanceOf[_to] += _amount;

        emit Transfer(address(0), _to, _amount);
    }

    /**
     * @dev Public mint (only owner)
     */
    function mint(address _to, uint256 _amount) public onlyOwner {
        require(_amount > 0, "Amount must be greater than 0");
        _mint(_to, _amount);
    }
}

Hands On Docker For Beginners Golang Dev

Bagas Hariyanto — Sun, 27 Oct 2024 22:56:41 +0000

Table of Content

Overview
Prerequisite
Dockerfile
Docker Compose
- Services
  - Nginx
  - Mysql
  - Migrate
  - API
- Volumes
- Networks
References

Overview

This Article wouldn't explain how Docker works on the hood, instead this Article will explain what the purpose on each code that written on Dockerfile and docker-compose.yml file so we can write our Docker configuration for other project.

Prerequisite

We need some project with Dockerfile and docker-compose for example, here we would use Golang Project named Ecom as example. For using Dockerfile you need to setup Local Database as mentioned on README.

Dockerfile

Dockerfile used to create a container image.(6)

# Build application from source
FROM golang:1.23.0 AS build-stage
    WORKDIR /app

    COPY go.mod go.sum ./
    RUN go mod download

    COPY . .

    RUN CGO_ENABLED=0 GOOS=linux go build -o /api ./cmd/main.go

FROM golang:1.23.0 AS build-stage this is an Image for our App, it's similar like we download Go engine to our Machine, Docker need specific Image to run our Code.(1)(2)
WORKDIR /app this is the working directory we want our Code to be executed at /app.
COPY go.mod go.sum ./ this code will copying go.mod and go.sum file from local machine to ./ directory on Docker.
RUN go mod download this will executed command go mod download on Docker
COPY . . this code will copy all file and folder project from local machine to Docker.
RUN CGO_ENABLED=0 GOOS=linux go build -o /api ./cmd/main.go this code will executed command to build Golang app on linux OS to folder /api on Docker.

# Deploy application binary into a lean image
FROM scratch AS build-realease-stage
    WORKDIR /

    COPY --from=build-stage /api /api

    EXPOSE 8080

    ENTRYPOINT [ "/api" ]

FROM scratch AS build-realease-stage scratch used to create minimal images containing only just what an application needs.
WORKDIR / we will using root / as working directory.
COPY --from=build-stage /api /api this will copying directory /api from image build-stage to /api on build-realease-stage image.
EXPOSE 8080 this will expose port 8080 so we can access API with port 8080 outside Docker.
ENTRYPOINT [ "/api" ] this will set default executable at /api

Let's try our Dockerfile.

sudo docker build .

docker build to build our project into an Image. You can add tags -t project-ecom to easier identify Images you build.(3)

You can check the Image list with command sudo docker image ls

sudo docker run --rm --network host --env-file .env 98bc0128576e

Then Run our Docker Image
--rm to remove container when stopped
--network host to connect docker app to localhost machine (4),(5)
--env-file .env to access environment value through .env file
98bc0128576e docker image ID

Congratulation

You now can testing to Consume API with Postman or other apps.

Docker Compose

Docker Compose used to make multiple container services and run it inside Docker. In this project docker-compose.yml there are 4 services that we will explain.

Services

A service is an abstract definition of a computing resource within an application which can be scaled or replaced independently from other components.(12)

Nginx Proxy

  nginx:
    image: nginxproxy/nginx-proxy:1.6
    networks:
      - default
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    environment:
      HTTPS_METHOD: nohttps

nginx: this is the service name
image: nginxproxy/nginx-proxy:1.6 this is the Image that we will use, similar to FROM at Dockerfile.
networks: this is the network inside Docker the service will use.
ports: this is to set port for service to use <local-machine-port> : <docker-nginx-port>, 80 is default port for HTTP
volumes: this is persistent Volume to store data for this service, <local-data-directory> : <docker-directory> :ro (read-only).
environment: this is to use environment variable.(8)

Mysql

  db:
    image: mysql:8.0
    networks:
      new:
        aliases:
          - database
    healthcheck:
      test: mysqladmin ping -h database -u ${DB_USER} --password=${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3308:3306"
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
      MYSQL_DATABASE: ${DB_NAME}

db: this is the service name
image: mysql:8.0 this service using Image mysql version 8.0
networks: this service using custom network named new then the new network using alias-name database
healthcheck: this is to check the service operation by running a test, test: mysqladmin ping -h database -u ${DB_USER} --password=${DB_PASSWORD} this testing ping a mysql database.
volumes: this is to store persistent data inside volume.
ports: this is port the service will use, in this service we use 3308 as local-machine port because port 3306 already used for mysql on our local-machine.
environment: this is to using environment variable, in this mysql service we need root password and database name.(7)

Migrate

  migrate-up:
    image: migrate/migrate
    networks:
      - new
    volumes:
      - ./cmd/migrate/migrations:/migrations
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    command: ["-path", "/migrations", "-database", "${CONNECT_DB}", "-verbose", "up"]
    links:
      - db
    depends_on:
      db:
        condition: service_healthy

migrate-up: this is the service name
image: migrate/migrate this service use migrate Image
networks: this service using network new same as db service
volumes: the migrations data from local ./cmd/migrate/migrations got copied to service directory /migrations
command: this is to run a command on this service, ["-path", "/migrations", "-database", "${CONNECT_DB}", "-verbose", "up"] this command similar to migrate -path /migrations -database mysql://root:some-secret-password@tcp(database:3306)/ecom -verbose up. (9)
links: this to link service to another service, this migrate service linked to db service
depends_on: this to make this service executed after certain condition, db: condition: service_healthy this mean migrate-up service will executed when db service test got result service_healthy.

API

  api:
    networks:
      - new
      - default
    build: 
      context: .
      dockerfile: Dockerfile
    restart: on-failure
    volumes:
      - .:/go/src/api
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "8080:8080"
    environment:
      VIRTUAL_HOST: ${PUBLIC_HOST}
      DB_HOST: db
      DB_USER: ${DB_USER}
      DB_PASSWORD: ${DB_PASSWORD}
      DB_NAME: ${DB_NAME}
    links:
      - db
    depends_on:
      migrate-up:
        condition: service_completed_successfully
      db:
        condition: service_healthy
      nginx:
        condition: service_started

api: this is the service name
networks: this is network for this service, this service using network new so it can connect to service db, also connect to network default used by service nginx.
build: this is to build the service, thi service using Dockerfile.
restart: this service will restart whenever the service on-failure
volumes: this is persistent data that stored on volume /go/src/api.
ports: port for this service.
environment: environment value this service needed.
links: this service linked to db service because its need to consume mysql database.
depends_on: this service will executed on several condition, when migrate-up: already service_completed_successfully, when db test result is service_healthy, and when nginx service_started

Volumes

Volumes are persistent data stores implemented by the container engine.(10)

volumes:
  db_data:

volumes: this created persistent volume named db_data:

Networks

Networks let services communicate with each other.(11)

networks:
      new:

networks: this created networks named new

Let's try our Docker Compose

sudo docker compose up -d

This command will create images for each services and run each container.

sudo docker compose ps --all

You can check the container our docker-compose.yml created.

sudo docker volume ls

You can check volume our docker-compose.yml created.

sudo docker image ls

You can check images our docker-compose.yml created.

Congratulation

You can test Consume API from our project based on documentation on README with Postman or other apps.

if you have done you can stop the container with,

sudo docker compose stop

Or if you want to delete all container service inside docker compose you can run,

sudo docker compose down

References

(1)Dockerfile Reference
(2)Docker Base Image
(3)Docker Build
(4)Docker Network Tutorials
(5)Docker Network Drivers
(6)Writing a Dockerfile
(7)Docker Hub Mysql
(8)Nginx-Proxy Docs
(9)Golang Migrate
(10)Compose-file Volumes
(11)Compose-file Networks
(12)Compose-file Services

Consume Data From API on Flutter Using DIO Package (1)

Bagas Hariyanto — Thu, 25 Aug 2022 08:24:00 +0000

Intro

For Mobile App developer consuming data from API is one of skill set that you must have. Flutter it self have many package to help developer consuming data from API.

DIO

DIO is a popular package for retrive data from API on flutter, it's powefull and easy to use.

GET Example

For example we would using reqres.in API to perform GET, POST and PUT

First we should make a data model, this is to store the data from API before we consume it with flutter.
You can make data model based on response data from API, here the response data from method GET reqres.in :
GET:https://reqres.in/api/users?page=2

class UserModel {
// this is the data from json response,
// each type data based on success json response
  int? page;
  int? perPage;
  int? total;
  int? totalPages;
  List<Data>? data;

// this is constructor
  UserModel({
    this.page,
    this.perPage,
    this.total,
    this.totalPages,
    this.data,
  });

// this is function to store data base on key-value response
  UserModel.fromJson(Map<String, dynamic> json) {
    page = json['page'];
    perPage = json['per_page'];
    total = json['total'];
    totalPages = json['total_pages'];
    data = json['data'] == null
        ? []
        : (json['data'] as List).map((e) => Data.fromJson(e)).toList();
// on this data we should mapping each response from List to 'class Data'
  }
}

// this class for store data from each response on List
class Data {
  int? id;
  String? email;
  String? firstName;
  String? lastName;
  String? avatar;

  Data({
    this.id,
    this.email,
    this.firstName,
    this.lastName,
    this.avatar,
  });

  Data.fromJson(Map<String, dynamic> json) {
    id = json['id'];
    email = json['email'];
    firstName = json['first_name'];
    lastName = json['last_name'];
    avatar = json['avatar'];
  }
}

then we would make function to Get API with DIO.
Using GET method on DIO is easy, we just need to declare DIO package on a class then make a function to use method GET and passing the URL.

class ApiServices {
  Dio dio = Dio();

  Future<Map<String, dynamic>> getUser() async {
    const String url = 'https://reqres.in/api/users?page=2';
    try {
      Response response = await dio.get(url);
      return response.data;
    } on DioError catch (error, trace) {
      print('DIO error : $error, on : $trace');
      return error.response!.data;
    }
  }
}

Explanation:

Future<Map<String, dynamic>> getUser() async {

on this code, we use Future Type data because Dart only allow asyncronous on Future type data function. Then we use Type data Map of String, and dynamic because the response from GET is still array of json, we need to mapping it later.

Then we make another function to cast Map of String, dynamic to List of DataModel:

Future<List<DataModel>> userServices() async {
    List<DataModel> userList = [];
    var response = await getUser();
    if (response.containsKey('data') && response['data'] is List) {
      userList =
          (response['data'] as List).map((e) => DataModel.fromJson(e)).toList();
    }
    return userList;
  }

Explanation:

Future<List<DataModel>> userServices() async {

The return data from getUser is Map of json data, we should convert it to List of DataModel before we consume it on Flutter.

if (response.containsKey('data') && response['data'] is List) {

Because we just want to consume array of 'data' we should ensure that the response has it and then we mapping it to DataModel.

userList = (response['data'] as List).map((e) => DataModel.fromJson(e)).toList();

And then we have List of DataModel, we can consume it with ListView.builder() on Flutter.

Common DIO GET Method

Beside of 'path' on dio.get() there another parameter on method get() you can use:
queryParameters: to give param to API,
options: this required Options() and have many function like setting header etc.