Coder Legion - Recent posts tagged rest

Why Rest Matters for Software Engineers

Sat, 15 Aug 2026 19:18:40 +0000

Why Rest Matters for Software Engineers

We are all software engineers, and most of us know what it feels like to carry work in our heads even after the laptop is closed.

During the week, there is always something to solve: a production issue, a difficult bug, a deadline, a code review, a new feature, or a technical problem that just refuses to make sense. Even when the workday ends, our brain sometimes keeps running in the background.

That is why I believe weekends should not always be about catching up on more work.

We need enough rest.

Rest is not being lazy. It is part of doing good engineering.

When we are constantly tired, we don't just lose energy. We lose patience, focus, creativity, and the ability to think clearly. A problem that normally takes 20 minutes can suddenly take two hours because our brain is simply exhausted.

Good software development requires deep thinking. We need to understand problems, make decisions, notice small details, and sometimes find solutions that are not obvious at first. That becomes much harder when we haven't given ourselves enough time to recover.

For me, a proper weekend is a chance to step away from the screen, sleep enough, spend time with people, go outside, enjoy simple things, and let my mind slow down.

Sometimes the best solution to a difficult technical problem doesn't come from staring at the code for another five hours. It comes after taking a break and coming back with a fresh mind.

So, if you are a developer and you feel guilty for resting on the weekend, remember this:

You are not wasting time. You are recovering the energy you need to do better work.

We spend so much time building software. We should also make time to maintain ourselves.

A rested developer can think better, communicate better, make better decisions, and enjoy the work more.

Rest is not a break from being a good engineer. It is part of being one.

I want you to have enough rest this weekend

gRPC vs REST

Tue, 14 Apr 2026 07:25:32 +0000

TL;DR:
We benchmarked REST vs gRPC under identical local setups using .NET. While gRPC is widely believed to outperform REST, our results show REST can be equally, or even slightly faster in specific data-heavy operations.

As microservices multiply across modern systems, the choice of API protocol can make or break performance. REST has ruled for years, but gRPC promises to be faster, leaner and more efficient. So why hasn't it taken over? Microservices can be heavily dependent on each other, which means speed and stability is key. When gRPC claims to be faster than REST, why isn't it the de facto standard? In this blog we will put gRPC and REST head to head, to see which is actually faster.

gRPC is a superior technology to REST! At least that is what this1, this2, this3 and this blog4 claims. According to all the mentioned blogs, gRPC performs better and faster than a REST on several metrics. In this blog we will test specifically, how fast a REST client can handle different request and responses, and compare it to how fast a similar gRPC client handles the same requests and responses. This begs the question...

Is gRPC faster than REST?

We hypothesize that gRPC is able to send and receive requests faster than a traditional REST. To test this, the following experiments have been developed.

The experiment

To test the Hypothesis two experiments, one utilizing gRPC and one utilizing REST. These experiments have to adhere to the following:

Rules

To ensure accurate measurements, the results must be obtained from the same computer.
Multiple data structures will be tested.
The setup for both APIs has to be as similar as possible.
The time used for measuring should be obtained from the client.

Set up

To adhere to the multiple data structures rule, a local database has been created, this database will provide a single instance of an object, as well as multiple instances of objects that will be stored in a list.
Each API will have 12 methods to call.
- Three for a single instance which takes a parameter of Id.
  - Each one with a larger payload
- Three for a single instance which takes a parameter of Id.
  - Each one with a deeper payload
- Three for a collection of 100 instances, which takes no parameters.
  - Each one with a larger payload
- Three for a collection of 100 instances, which takes no parameters.
  - Each one with a deeper payload
Each API will be tested with a client written in C#, as a console app.
- Time will be measured with .NET Stopwatch18.
- The stopwatch will begin when the method is called and end when the API returns the full data.
To minimize anomalies and outliers, each operation will be executed 100 times, and the average call speed will be evaluated.

Specs

I7-9700k, 8 core, 4.6GHz

Samsung SSD 840 EVO 250GB

NVIDIA GeForce GTX 1070

2x8 GB HyperX Fury 2666MHz DDR4 Memory

REST

What is REST?

We have decided to work with the common implementation of REST and not the full implementation of a RESTful API5.

The key features to take note of when using rest:

Separation of client and server

Server and client can be implemented independently without knowing each other-
Server code can be changed without affecting the client.
Client code can be changed without affecting the server.
Both server and client are aware of methods available.

Statelessness

Stateless6 means that the server is not required to know the current state of the client and vice versa.
Either end can understand any method calls, without knowing the previously called methods.

Invocation

We invoke a method on the server via HTTP operations7
- GET
- POST
- PUT
- DELETE

Setting up the experiment for the REST API

The architecture for this experiment is a simple one:

Sample project and metrics

If you want to replicate this experiment yourself, the database setup can be found here and the source code for the rest-api can be found here

Running our setup yielded the following results:

Single payload

The difference between a single small payload and a single large payload is small in the context of a daily task. A single small payload has a mean response time of 0.0181 whilst a single large payload has a mean response time of 0.0204 seconds. But in relation to each other, it's a 12.7% increase in response time.

To put this into perspective a small payload contains 10 values of data. A large payload contains (4+(6*9))*6+4 or 352 values. This means that we have requested 3420% more data and it only took 12.7% longer.

To test different scenarios we also created a "deep" payload that contains a different amount of nested objects. The deepest payload contains a total of eight nested objects, however, the total amount of values is far less in comparison to the previous payload. The previously mentioned payload peaked at 352 values whereas the deepest payload peaks at (4+(6*4))+(4+(7*4))+(4+(8*4)) values, or 96 values in total. In other words, the deep payloads are much smaller in size but different in structure.

To give a concrete example, a large payload is structured like so:

large_payload {
    id,
    string_Value,
    int_value,
    double_value,
    medium_payload {
        id,
        string_value,
        int_value,
        double value,
        small_payload {
                id,
                string_value,
                int_value,
                double_value
            },
        small_payload {
                ...
            },
        ...
        },
    medium_payload {
            ...
        },
    ...
}

and the deepest_payload is structured like so:

deepest_payload {
    id,
    depth_seven {
        ...
    },
    depth_eight {
        ...
    },
    depth_nine {
        id,
        string_value,
        int_value,
        double_value,
        depth_eight {
            id,
            string_value,
            int_value,
            double_value,
            depth_seven {
                ...
                depth_six {
                    ...
                    dpeth_five {
                        ...
                        depth_four {
                            ...
                            depth_three {
                                ...
                                depth_two {
                                    ...
                                    depth_one {
                                        ...
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }

    }
}

Interestingly, larger payloads returned faster results, an unexpected outcome that could hint at CPU scheduling effects or cached object reuse.

To put things into perspective, a deep payload, which contains a total of 4+(4+4)+(4+4*2) values, or 24 values in total. Averaged at 0.0173 seconds, whereas the deepest payload, which carries a total of 96 values, which means it's 300% larger in size, averaged at 0.015 seconds. In other words, 300% more data was transferred 15.3% faster on average.

Collection of payloads

When we compare collections, the difference becomes very apparent. A small collection payload averaged 0.0256 seconds and a large average of 0.1006 seconds, which is an increase of 293%. It is apparent that when it comes to moving large collections of data over the REST API, it takes a considerate amount of time compared to smaller collections.

The results are very much alike when we tested on collections of deep payloads.

gRPC

What is gRPC?

gRPC8 is an open-source RPC framework, that can run in any environment. gRPC was recently included in the .Net core platform thereby easily accessible by thousands of developers.

Some key features we would like to highlight:

HTTP/2 support

HTTP/29 is HTTP/1's successor, which is what most websites and frameworks utilize today. In many ways, HTTP/2 is an improved version of HTTP/1, and HTTP/3 is already in the works.

Language independent

gRPC is language independent, which means it doesn't matter which language you develop in. The framework supports a handful of popular languages10. This is quite an advantage when you're developing microservices, which might have services developed in different languages and frameworks.

Contract First

gRPC is strictly contract first11 which is a design approach that works especially well in larger development teams. It also excels when developing microservices, as a contract would be created before any actual implementations can be done. The contract is designed in the .proto file12, which is also where gRPC gains some of its speed from, seeing as .proto files are...

Strongly typed As a by-product of a strongly typed proto file, which is used as a contract between client and server, but also used as an extensible mechanism for serializing13 structured data.

Setting up the gRPC project

For the gRPC architecture we use the same as the rest, we have a client and a server running locally. The client calls the methods exposed by the proto file. The method then gets executed on the server and queries the database, once the data has been obtained it replies to the client. When the client has received all the data, we stop and log the time elapsed since the call started.

Sample project and metrics

If you want to replicate this experiment yourself database setup can be found here and the source code for the grpc-project can be found here

Running our setup yielded the following results:

Single payloads

The test on single payloads yielded quite odd results, where the medium payload proved to be the fastest on average, and the largest payload only being slightly slower than the smallest. Just to recap the numbers; a larger payload contains 3400% more data than a small payload, and yet it only took 2.36% longer to get that data.

Even more odd were the results of the deep payloads. Once again the payload containing a "medium" amount of data, was the fastest, just like previously. But unlike previously, the deepest payload was significantly faster than the deep payload, to be precise; the deepest payload, which contains 300% more data than a deep payload was 28.63% faster. As the results are rather unexpected we have to take a close look at possible errors that could have occurred.

Collection of payloads

Collections paint a different picture, a small payload collection averaged 0.01911 seconds, while a collection of large payloads took 0.7025. This means a large payload on average took 267.6% longer to get. These results are much closer to what we would expect. We did the same test with a collection of deep payloads.

The results of this test, were as you would expect, as the payloads incrementally increase in size, they also increase incrementally in response time.

Conclusion

When we put the two charts next to each other, it's easy to see which one has an edge. The REST API is represented by the blue blocks, whilst gRPC is represented by the red blocks, just like previously.

This is the case for both single instances of objects as well as collections of objects.

We hypothesized that gRPC would be faster than the rest, based on the numerous blogs claiming this to be true, with their own tests. Contrary to popular belief, our experiments suggest that under certain conditions, REST can outperform gRPC in raw speed, reminding us that performance isn't universal but contextual.

These results might not seem as much, but it has been proven14 that people on average don't wait around for data to load and will abandon a web page or program if loading times are too long. When moving large amounts of data, a small amount of time can be the difference between keeping or losing a customer.

this prompts the question: When to use gRPC and when to use REST

We would argue that gRPC fit into a setting, where you need to have multiple programs or services talking to each other across different languages, especially when the task that needs to connect to an endpoint is an action that needs to be executed; one such action could be TurnOnTheWater(). This argument is based on the research made into gRPC, rather than the results of these particular tests.

REST on the other hand operates on the four aforementioned HTTP operations, these operations indicated data transfers of one sort or the other. While rest can execute the same actions as gRPC, the action TurnOnTheWater() doesn't fit into what a REST API was designed for. We would instead use REST where we required data transfers and other typical CRUD mechanics.

Ultimately, the right choice depends on your use case: REST for simplicity and interoperability, gRPC for high-efficiency internal microservice communication.

Possible errors

Network outage during some of the tests
The gRPC serverside logging was set to critical, tweaking this option might yield different results.

What's next?

This blog has only been about the differences in speed between REST and gRPC, but in reality, many other factors are present, if we were to truly compare the two frameworks. gRPC has claimed to not only be faster, but also more reliable, stable, and secure, and all of these metrics, as well as other metrics, would be interesting to cover, they are however out of scope in this particular blog-post.

Technologies used

References

Battle of the APIs gRPC v REST
gRPC/REST performance simplified gRPC v REST
Why milliseconds matter gRPC v REST
gRPC/REST evaluating performance gRPC v REST
REST vs RESTful REST
Statelessness REST
Http Methods REST
gRPC gRPC
HTTP/2 wiki
Suported gRPC languages gRPC
Design by Contract wiki
Google proto buffers gRPC
Serialization wiki
Website should load in 4 seconds blog
.NET Web API .NET
.NET Console App .NET
MySQL MySQL
.NET Stopwatch API .NET

Getting Started with Google Colab: Run Python in the Cloud for Free

Sat, 21 Mar 2026 09:05:41 +0000

If you want to write and run Python code without installing anything on your machine, Google Colab is one of the easiest ways to start.

Whether you're learning Python, building AI models, or analyzing data, Colab gives you a powerful environment—right in your browser.

What is Google Colab?

Google Colab (short for Colaboratory) is a cloud-based notebook environment that lets you:

Write and execute Python code
Use GPUs/TPUs for free
Share notebooks like Google Docs
Install libraries on the fly

Think of it as:

Jupyter Notebook + Free Cloud Compute + Collaboration

⚡ Why Developers Love Colab

No setup required – runs in your browser
Free GPU access – great for AI/ML
Auto-saves to Google Drive
Easy sharing & collaboration
Pre-installed libraries (NumPy, Pandas, TensorFlow, PyTorch)

️ Getting Started Step-by-Step

Step 1: Open Google Colab

Go to Colab
Sign in with your Google account

Step 2: Create a New Notebook

Click “New Notebook”
A .ipynb file opens instantly

Step 3: Understand the Interface

Code cells → write Python code
Text cells → write notes (Markdown)
Run button ▶️ → execute code

✍️ Your First Code

Example: Hello World

print("Hello, Google Colab!")

Click ▶️ and see output instantly.

Example: Data Analysis

import pandas as pd

data = {
    "Name": ["Alice", "Bob", "Charlie"],
    "Score": [85, 90, 95]
}

df = pd.DataFrame(data)
df

Output is displayed as a clean table.

Using Colab for AI/ML

Colab is widely used for:

Training machine learning models
Running deep learning experiments
Building NLP applications
Prototyping AI ideas

Enable GPU

Click Runtime → Change runtime type
Select GPU

Now your notebook runs faster for heavy tasks.

Installing Libraries

Need extra packages? Just run:

!pip install transformers

Working with Files

Upload file

from google.colab import files
files.upload()

Mount Google Drive

from google.colab import drive
drive.mount('/content/drive')

Click Share
Add collaborators
Set permissions (view/edit)

Just like Google Docs!

Real-World Use Cases

Data analysis & visualization
Machine learning experiments
AI model prototyping
Teaching & tutorials
Research projects

⚠️ Limitations to Know

Sessions disconnect after inactivity
Limited compute time
Not ideal for production apps

When Should You Use Colab?

Use it when you want to:

Learn Python or ML
Prototype quickly
Avoid local setup
Use GPU without cost

Avoid it when:

Building production systems
Running long-duration jobs

Final Thoughts

Google Colab removes the friction of setup and gives you instant access to powerful computing.

Instead of worrying about environments, you can focus on:

Learning, experimenting, and building

What to Try Next

Train a simple ML model
Use Hugging Face transformers
Build a chatbot
Analyze a dataset
Visualize data with Matplotlib

kind of free GPU
https://colab.research.google.com/

Dashboard Operasional Armada Rental Mobil dengan Python + FastAPI

Thu, 12 Mar 2026 17:00:00 +0000

Di banyak bisnis rental, masalahnya bukan kekurangan data—melainkan data tercecer: ketersediaan unit ada di chat, jadwal servis ada di catatan, dan laporan pemakaian tercebur di spreadsheet. Tren “dashboard-first” yang sering dibahas komunitas (misalnya artikel CoderLegion tentang dashboard monitoring Python + FastAPI) membuat kita bisa merapikan alur operasional jadi satu layar. Di artikel ini, kita bongkar cara membangun dashboard operasional armada rental yang ringan, real-time, dan enak dipakai tim lapangan.

Secara akademik, pendekatan dashboard monitoring terbukti membantu efisiensi pemantauan dan akurasi pelaporan pada studi pengembangan dashboard monitoring proyek (lihat landasan pada jurnal dashboard monitoring berbasis KPI). Walau konteksnya bukan rental mobil, prinsipnya identik: KPI yang terukur + visualisasi yang tepat = keputusan lebih cepat. Itu alasan kenapa tema ini relevan untuk pembaca developer: kalian bisa membawa “engineering mindset” ke problem operasional yang nyata.

“Dashboard yang bagus itu bukan sekadar cantik—dia memotong waktu debat, mempercepat keputusan, dan mengurangi miskomunikasi.”

1. Kenapa Dashboard Operasional Itu Penting untuk Armada Rental

Sebelum nulis satu baris kode, kita perlu sepakat: dashboard bukan “aksesori”, tapi control plane untuk operasional. Kalau operasional kamu masih bergantung pada ingatan admin dan scroll chat panjang, risiko bentrok jadwal, servis telat, dan salah alokasi unit itu tinggal menunggu waktu.

Masalah yang sering kejadian di lapangan

Double booking: unit dianggap available karena belum di-update.
Servis kelewat: jadwal maintenance tidak punya pengingat yang konsisten.
Laporan pemakaian bias: data odometer/BBM masuknya sporadis.
SLA respon lambat: customer nunggu kepastian unit karena admin cek manual.

KPI yang “wajib ada” untuk rental

Agar dashboard operasional armada rental tidak jadi pajangan, tetapkan KPI sederhana:

Utilization rate per tipe kendaraan
Availability harian (available / on-rent / maintenance)
On-time return rate
Jumlah unit “overdue service”
Lead time dari inquiry → konfirmasi

2. Data Model Minimal yang Bikin Dashboard Nendang

Dashboard yang efektif biasanya justru lahir dari skema data yang tidak ribet. Mulai dari model minimal, lalu berkembang.

Entity yang disarankan

Fleet

vehicle_id, plate_number, type (sedan/SUV/minivan/city car/pickup), status

Booking

booking_id, vehicle_id, start_at, end_at, customer_name, channel (WA/web), status

Maintenance

maintenance_id, vehicle_id, service_type, due_at / due_odometer, status

Usage Log

usage_id, vehicle_id, date, odometer, fuel, notes

Tabel ringkas status unit (agar semua orang 1 bahasa)

Status	Definisi	Dampak di Dashboard
available	Unit siap disewa	Bisa dibooking
on_rent	Sedang dipakai customer	Tampil sebagai terpakai
maintenance	Servis/repair	Disembunyikan dari listing booking
hold	Diblock sementara (mis. inspeksi)	Perlu approval sebelum release

Tip: status hold sering menyelamatkan ketika ada unit “abu-abu” (baru balik, belum dicek).

3. Arsitektur Cepat: FastAPI sebagai Backend, Dashboard sebagai Produk

Untuk komunitas CoderLegion, stack paling “masuk akal” adalah FastAPI + Postgres + frontend dashboard (bisa Next.js, atau minimal Jinja/HTMX kalau mau hemat).

Komponen yang saya pakai (pragmatis)

FastAPI: REST + WebSocket untuk update real-time
PostgreSQL: data transaksi booking/servis
Redis (opsional): cache availability dan event stream
Background jobs: scheduler reminder servis & overdue return

Kenapa FastAPI cocok

Typed (Pydantic) → validasi data operasional rapi
Async-ready → cocok untuk notifikasi dan stream
Ekosistem luas → gampang integrasi scheduler, websocket, auth

Sebagai referensi internal yang relevan, kamu juga bisa lihat fastapi-bgtasks-dashboard untuk ide “observability” background task di ekosistem FastAPI.

4. Cara Menghitung Ketersediaan Unit Tanpa Drama

Bagian paling krusial dari dashboard operasional armada rental adalah availability engine. Kita tidak mau “available” versi admin A berbeda dengan admin B.

Prinsip kalkulasi

Ambil semua unit yang bukan maintenance dan bukan hold.
Untuk rentang waktu yang dipilih, cek apakah ada booking berstatus confirmed/active yang overlap.
Jika overlap → on_rent, jika tidak → available.

Edge case yang sering dilupakan

Booking yang extend (end time berubah)
Unit yang swap karena kerusakan
Booking pending (belum dibayar DP) — putuskan apakah memblok unit atau tidak

Tabel contoh aturan overlap

Kondisi	Overlap?	Status
booking end < start filter	tidak	available
booking start > end filter	tidak	available
booking start <= end filter dan booking end >= start filter	ya	on_rent

5. Jadwal Servis: Dari “Ingat-ingat” Jadi Sistematis

Di rental mobil, maintenance itu bukan biaya—dia investasi. Dashboard harus membuat servis terlihat dan actionable.

Pola yang efektif

Due by date: servis berkala tiap X bulan
Due by odometer: servis tiap X km
Alert window: misalnya H-7 / 500 km sebelum due

Checklist servis yang bisa ditampilkan

Oli + filter
Rem & kampas
Ban & rotasi
AC & filter kabin
Pemeriksaan kelistrikan

Pro tip: tampilkan widget “unit yang overdue” di atas. Manusia cenderung mengerjakan yang paling terlihat.

6. Laporan Pemakaian: Biar Keputusan Tarif Nggak Pakai Perasaan

Kalau kamu punya log odometer dan pemakaian, kamu bisa:

Deteksi unit yang “boros” (indikasi masalah mesin/ban)
Rekomendasi rotasi armada
Hitung biaya per km untuk evaluasi tarif

Format laporan yang enak dibaca

Per unit per minggu: km tempuh, hari terpakai, downtime
Per tipe kendaraan: utilisasi, revenue proxy, complaint rate
Top 5 penyebab downtime: maintenance, hold, overdue return

Contoh ringkas tabel laporan mingguan

Plat	Hari terpakai	KM	Downtime (hari)	Catatan
B 1234 XX	5	410	1	Servis oli
B 9876 YY	3	220	2	Ban depan

7. UI/UX Dashboard yang “CoderLegion Banget”

Di 2026, dashboard itu bukan sekadar chart. Ini tentang workflow.

Pola UI yang terasa modern

Global filter: tanggal, cabang, tipe kendaraan
Quick actions: tombol “Block unit”, “Jadwalkan servis”, “Extend booking”
Activity feed: perubahan status unit (audit trail)
Real-time badge: indikator data terakhir update

Microcopy yang membantu operasional

Daripada “Maintenance”, gunakan:

“Sedang Servis (estimasi selesai: …)”
“Hold: menunggu inspeksi”

Dengan microcopy yang jelas, dashboard operasional armada rental jadi “bahasa bersama” antara admin, driver, dan owner.

8. Security & Reliability: Jangan Sampai Dashboard Jadi Titik Lemah

Dashboard operasional itu sensitif: ada data customer, jadwal, dan status aset.

Minimal baseline yang saya sarankan

Auth: JWT + refresh token / session cookie
RBAC: admin, supervisor, driver
Audit log: siapa ubah status unit kapan
Rate limiting untuk endpoint publik

Observability yang simple tapi berguna

Log structured (JSON)
Metrics (request latency, error rate)
Tracing untuk alur booking → notifikasi → update status

FAQ

Q: Saya sudah pakai spreadsheet, perlu dashboard?
A: Spreadsheet bagus untuk input, tapi lemah untuk real-time visibility dan kontrol status. Dashboard mengurangi “interpretasi” dan mempercepat eksekusi.

Q: Harus WebSocket?
A: Tidak wajib. Kamu bisa mulai polling tiap 10–30 detik. WebSocket jadi relevan saat tim kamu banyak dan perubahan status sering.

Q: Bagaimana menghindari double booking?
A: Pastikan ada transaction/locking di sisi database saat konfirmasi booking, dan availability dihitung dari data booking yang sama.

Q: Tool frontend yang paling cepat?
A: Untuk MVP: Next.js + Tailwind + chart library. Untuk super cepat: template admin + fetch REST.

Q: KPI apa yang paling berdampak?
A: Availability harian + overdue service + overdue return. Tiga ini biasanya langsung terasa efeknya.

HowTo

Tentukan KPI inti (availability, overdue service, overdue return).
Buat data model minimal (Fleet, Booking, Maintenance, Usage Log).
Bangun API FastAPI untuk list unit, availability, servis, laporan.
Buat dashboard dengan global filter + widget prioritas (overdue).
Tambahkan audit log, RBAC, dan notifikasi operasional.

Dari Data Jadi Insight yang Bisa Dipakai Tim

Sebagai penutup, ingat bahwa tujuan utama dashboard operasional armada rental bukan “biar kelihatan canggih”, melainkan mengurangi friksi kerja: lebih sedikit cek manual, lebih sedikit miskomunikasi, dan lebih cepat ambil keputusan.

Carly Fiorina—mantan CEO Hewlett-Packard yang dikenal vokal soal kepemimpinan berbasis teknologi—pernah mengatakan: “The goal is to turn data into information, and information into insight.” Artinya: tujuan kita adalah mengubah data menjadi informasi, dan informasi menjadi wawasan. Kamu bisa cek kutipan dan profilnya di Wikiquote Carly Fiorina. Dalam konteks dashboard, ini mengingatkan kita bahwa angka mentah tidak cukup; yang dibutuhkan tim operasional adalah konteks, prioritas, dan tindakan berikutnya.

Jika kamu mengelola rental mobil di Karawang–Bekasi dan ingin operasional lebih rapi dengan pemesanan cepat serta dukungan 24 jam, kamu bisa lihat profil layanan kami di Oto Track untuk gambaran proses bisnis yang bisa dijadikan studi kasus implementasi dashboard.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Membangun dashboard operasional armada rental dengan Python dan FastAPI",
  "description": "Panduan ringkas untuk membangun dashboard operasional armada rental: ketersediaan unit, jadwal servis, dan laporan pemakaian.",
  "totalTime": "PT6H",
  "supply": [
    {"@type": "HowToSupply", "name": "Database (PostgreSQL)"},
    {"@type": "HowToSupply", "name": "Python 3.11+"},
    {"@type": "HowToSupply", "name": "FastAPI"}
  ],
  "tool": [
    {"@type": "HowToTool", "name": "VS Code"},
    {"@type": "HowToTool", "name": "Docker (opsional)"}
  ],
  "step": [
    {
      "@type": "HowToStep",
      "name": "Definisikan KPI inti",
      "text": "Pilih KPI yang paling berdampak: availability harian, overdue service, overdue return.",
      "url": "https://coderlegion.com/"
    },
    {
      "@type": "HowToStep",
      "name": "Buat data model minimal",
      "text": "Siapkan entity Fleet, Booking, Maintenance, dan Usage Log agar status unit konsisten.",
      "url": "https://coderlegion.com/12111/membangun-dashboard-monitoring-proyek-konstruksi-dengan-python-fastapi-progress-lapor?is_promoted=1"
    },
    {
      "@type": "HowToStep",
      "name": "Implementasi API FastAPI",
      "text": "Bangun endpoint untuk ketersediaan unit, jadwal servis, dan laporan pemakaian dengan validasi Pydantic.",
      "url": "https://coderlegion.com/groups/PythonDev"
    },
    {
      "@type": "HowToStep",
      "name": "Bangun UI dashboard",
      "text": "Buat global filter, widget overdue, quick actions, dan audit trail agar workflow operasional lancar.",
      "url": "https://coderlegion.com/5893/fastapi-bgtasks-dashboard"
    },
    {
      "@type": "HowToStep",
      "name": "Tambah security & observability",
      "text": "Aktifkan RBAC, audit log, rate limiting, dan monitoring error/latency untuk produksi.",
      "url": "https://coderlegion.com/"
    }
  ]
}

Best practices for RESTful API design for Dev Tools

Sun, 15 Feb 2026 18:51:56 +0000

Creating a RESTful API is more than just a set of endpoints. It’s a careful orchestration of principles that ensures your application is robust, scalable, and maintainable. Here are some essential practices to guide your API design.

Use Resource-Oriented URIs

Instead of implementing complex action-oriented verbs in your URI paths, focus on resources. For example:

Bad: /getUsers
Good: /users

This approach leads to cleaner, more predictable APIs. It encourages natural usage patterns and aligns better with HTTP methods.

Implement Proper HTTP Methods

Use the appropriate HTTP methods for CRUD operations to express intent clearly:

GET: Retrieve data
POST: Create new resources
PUT: Update existing resources completely
PATCH: Update existing resources partially
DELETE: Remove resources

By utilizing these methods correctly, your API can operate in a stateless manner and make efficient use of resources.

Status Codes Matter

HTTP status codes provide a universal language for communicating the result of API requests. Use them wisely:

200 OK for successful requests
201 Created for new resource creation
400 Bad Request for client errors like validation issues
404 Not Found for nonexistent resources
500 Internal Server Error for unexpected server-side issues

Consistency in status codes helps clients easily understand how to handle responses.

Version Your API

Versioning is crucial for maintaining backward compatibility as your API evolves. Use a clear and logical versioning strategy, like including the version in the URI:

Example: /v1/users
This practice shields clients from breaking changes and allows developers to progressively enhance the API.

Keep Responses Consistent

API responses should be predictable to improve ease of integration. Stick to a consistent structure. For instance, always wrap resources in a JSON object:

{
  "data": {
    "id": 1,
    "type": "user",
    "attributes": {
      "name": "John Smith"
    }
  }
}

This structure not only provides clarity but also allows future attributes without breaking existing clients.

Pagination and Filtering

For endpoints that might return large sets of data, implement pagination and filtering to enhance performance and usability. For example:

GET /users?page=2&limit=10
This approach prevents overloading the client with excessive data and facilitates easier navigation.

Authentication and Security

Never underestimate the importance of securing your API. Use industry-standard authentication methods:

OAuth for delegated access
API Keys for simple access control
Ensure sensitive data is transmitted over HTTPS to prevent eavesdropping.

Documentation is Key

A robust API requires excellent documentation. Tools like Swagger or Postman can help you create interactive documentation, making it easier for developers to understand how to interact with your API.
Provide examples, status codes, and error messages to facilitate smooth adoption and integration.

Error Handling

Implement clear, consistent error messages with relevant status codes to aid developers in troubleshooting. A good error response could look like:

{
  "error": {
    "code": "ValidationError",
    "message": "Email is required"
  }
}

This clarity not only helps users during integration but also significantly enhances the overall user experience.

Conclusion

Incorporating these best practices in your RESTful API design will lead to a more robust, scalable, and maintainable product. Each principle contributes to a seamless experience for developers and users alike. As you design your APIs, remember to keep the user experience at the forefront. Happy coding!

REST API - A Refresher

Mon, 02 Jun 2025 05:36:19 +0000

Overview

REST API is the HTTP interface following REST principles to manipulate resources. This quick refresher looks at some common concepts and its application in Divooka.

1. Why you should care

REST (REpresentational State Transfer) is the de-facto style for web services: roughly 8 out of 10 public APIs you’ll meet follow it, so mastering the basics lets you speak to almost any modern backend.(Integrate.io)

2. REST in 60 seconds

A REST API exposes resources (nouns such as /users/42) over plain HTTP. Clients use standard verbs to act on those resources:

Verb	Typical intent	Idempotent?
GET	Read	✔︎
POST	Create / adj. action	✖︎
PUT	Replace	✔︎
PATCH	Partial update	✖︎
DELETE	Remove	✔︎

RESTful servers must also follow six architectural constraints (uniform interface, client-server, stateless, cacheable, layered, code on demand optional).(restfulapi.net, Integrate.io)

3. Common response codes

200 OK / 201 Created – success
400 Bad Request – client error (malformed JSON, missing fields)
401/403 Unauthorized / Forbidden – auth problems
404 Not Found – wrong URI or missing record
500+ Server errors – bug, outage, etc.(Postman Blog)

4. Tiny “Hello World” example

GET https://api.example.com/items/123
Accept: application/json

Typical JSON reply:

{
  "id": 123,
  "name": "Widget",
  "price": 9.99
}

5. Trying REST in Divooka

Divooka lets you build the call as a node graph instead of filling long forms:

Send (HTTP) Request node – set GET and URL {{baseUrl}}/items/{{itemId}}.
Headers – drop a Custom Header node for key:value pairs like Accept: application/json.
(Optional) Auth node – choose Basic, Bearer, or OAuth 2.0.
Preview JSON node to parse JSON payloads – pretty-prints and type-checks the body.

Everything is visual and reusable: connect the same response into further logic (save to DB, update UI, trigger another request) without writing glue code.

You can view more practical examples on the Web API Testing page.

Environment variables

Define baseUrl, apiKey, or authToken once in Environments and reference them anywhere with Get Environment Variable nodes. Switch environments (dev/staging/prod) using Switch node.

Save and group related requests into graphs as documents, so it can be easily reused and shared.

6. Best-practice checklist

For designing your own REST APIs:

Keep URIs noun-based (/orders/17, not /getOrder).
Use correct verbs (no GET /deleteUser).
Surface pagination & filtering (?page=2&limit=50).
Version in the path or header (/v1/), never break existing clients.
Secure with HTTPS, auth, and sensible rate limits.
Document with OpenAPI; Divooka can import the spec and scaffold nodes automatically.(idratherbewriting.com)

7. Further reading

Usage documentation in Divooka.
Roy Fielding’s REST dissertation (the original source)
RFC 9110 – HTTP Semantics
Postman “REST API examples” blog for real-world patterns(Postman Blog)
Divooka Wiki → App Development > API Testing (deep-dive on every node and feature)

With these essentials you can explore any REST endpoint confidently - and wire it into your Divooka flows to suit your application needs.

What is a REST API? A Simple Introduction for Beginners

Fri, 07 Feb 2025 18:56:29 +0000

Introduction:

Have you ever used an app that seamlessly connects with other platforms, pulls data, or updates information in real time? You're experiencing the power of APIs, and more specifically, REST APIs.

Overview: In today's world of connected digital products, REST APIs play a crucial role in enabling communication between applications. If you're new to software development or web technologies, understanding how APIs work can open doors to creating more dynamic, scalable, and powerful systems.

Purpose: In this article, we'll explore what REST APIs are, how they work, their advantages, and some potential challenges you might face when using them.

What is an API?

API stands for Application Programming Interface. Think of it as a messenger that lets one program interact with another. APIs define a set of rules and protocols for how software components should interact, essentially allowing different applications to "speak" to each other. For example, when you check the weather in a mobile app, an API connects that app to a weather service to retrieve the data you see on the screen.

What is a REST API?

REST stands for Representational State Transfer, a set of guidelines for creating APIs that work over HTTP. In simpler terms, REST APIs allow applications to talk to each other using standard web protocols. It's widely used because it's simple, scalable, and effective for exchanging data between servers and clients.

Examples of great products using REST APIs include:

Twitter: Access your feed, post tweets, or search for trends using their public REST API.
Google Maps: Developers can integrate location services into their apps via Google Maps REST API.
Spotify: The REST API is used to interact with Spotify's vast music database, enabling apps to search for songs, and playlists, or even create custom playlists.

Rest API Architecture

REST APIs follow a specific set of principles that make them both lightweight and powerful. Here's a breakdown of the architecture:

Statelessness: Each request from a client to the server must contain all the information needed to understand the request. No client context is stored on the server between requests.
Client-Server: The client (user) interacts with the server (where the data is stored), and they both operate independently of each other.
Uniform Interface: REST APIs follow a simple and consistent structure that makes them easy to use and understand.
Cacheable: Responses from the server can be cached to improve performance, especially for data that doesn't change frequently.
Layered System: REST APIs can be composed of multiple layers, making it easier to scale systems by adding new layers.

HTTP and HTTPS

REST APIs are based on HTTP (Hypertext Transfer Protocol), the same protocol used to load websites. HTTPS (Hypertext Transfer Protocol Secure) is the secure version of HTTP, ensuring that data sent between a client and server is encrypted and safe from eavesdropping.

Using HTTPS for your REST API is important to maintain security, especially when transmitting sensitive information, like passwords or credit card details.

HTTP Methods and How They Correlate with REST APIs

REST APIs use standard HTTP methods to define the actions that can be performed on a resource (data). These methods include:

GET: Retrieves data (e.g., get information about a user).
POST: Sends data to the server to create a new resource (e.g., submitting a form or creating a new post).
PUT: Updates an existing resource (e.g., updating a user's profile).
DELETE: Removes a resource (e.g., deleting a post).
PATCH: Makes partial updates to a resource (e.g., changing only one field in a user's profile).

Each HTTP method is tied to CRUD (Create, Read, Update, Delete) operations, making it easy for developers to understand how to interact with resources through the API.

Step-by-Step Guide/Tutorial To REST API

For the sake of brevity, this section will not include an in-depth tutorial, but here's a high-level guide on how to use a REST API.

Obtain API Key: Most APIs require you to register and get an API key for authentication.
Understand the Endpoint Structure: APIs usually follow a URL structure that includes the domain and resource path (e.g., https://api.example.com/users).
Choose the HTTP Method: Depending on what you want to do (retrieve, create, update, or delete), choose the appropriate HTTP method.
Send the Request: Use tools like Postman or code (e.g., Python's requests library) to send requests to the API.
Process the Response: The server will send a response, typically in JSON or XML format. Your application can process this data and display it accordingly.

Benefits/Advantages

REST APIs come with several advantages:

Scalability: REST APIs work well in distributed systems, allowing them to grow and adapt to different use cases.
Flexibility: They support multiple data formats, with JSON being the most popular, making them easy to use with various programming languages.
Performance: REST APIs are lightweight and efficient, allowing for fast data transfer.
Ease of Use: REST APIs follow simple conventions, making them easy for developers to learn and implement.
Platform Independence: They can be used across different platforms, whether you're building for web, mobile, or desktop applications.

Challenges/Considerations

While REST APIs offer many benefits, there are also some challenges to consider:

Security: REST APIs, especially those that handle sensitive information, can be vulnerable to attacks like SQL injection, Cross-Site Scripting (XSS), and Man-in-the-Middle (MITM) attacks. Using HTTPS and proper authentication methods like OAuth can help mitigate these risks.
Rate Limiting: Some APIs limit the number of requests you can make in a given time, which can slow down your application.
Complexity in Large Systems: For complex applications, REST APIs can become cumbersome and difficult to maintain.
Lack of Real-Time Capabilities: REST APIs operate over HTTP, which doesn't support real-time communication as efficiently as other technologies like WebSockets.

Conclusion

REST APIs are essential tools that power the modern digital world, connecting different applications and services. By understanding how they work, you can unlock the potential to build more dynamic, scalable, and efficient applications.
Whether you're building a simple mobile app or a complex enterprise solution, mastering REST APIs is a skill every developer should have.
Are you ready to start building your REST APIs? Let me know your thoughts or questions in the comments below. Don't forget to check out other tutorials and resources on API development!

Glossary

API: Application Programming Interface, the set of rules that allows different software systems to communicate with each other.
REST: Representational State Transfer, an architectural style for designing networked applications.
HTTP: Hypertext Transfer Protocol, a protocol used for transferring data over the web.
HTTPS: The secure version of HTTP, encrypts data for protection.
CRUD: Create, Read, Update, Delete; the basic operations you can perform on data.

Coder Legion - Recent posts tagged rest

Why Rest Matters for Software Engineers

Why Rest Matters for Software Engineers

gRPC vs REST

The experiment

REST

What is REST?

Setting up the experiment for the REST API

Sample project and metrics

gRPC

What is gRPC?

Setting up the gRPC project

Sample project and metrics

Conclusion

Possible errors

What's next?

Technologies used

References

Getting Started with Google Colab: Run Python in the Cloud for Free

What is Google Colab?

⚡ Why Developers Love Colab

️ Getting Started Step-by-Step

Step 1: Open Google Colab

Step 2: Create a New Notebook

Step 3: Understand the Interface

✍️ Your First Code

Example: Hello World

Example: Data Analysis

Using Colab for AI/ML

Enable GPU

Installing Libraries

Working with Files

Upload file

Mount Google Drive

Sharing Your Notebook

Real-World Use Cases

⚠️ Limitations to Know

When Should You Use Colab?

Final Thoughts

What to Try Next

Dashboard Operasional Armada Rental Mobil dengan Python + FastAPI

1. Kenapa Dashboard Operasional Itu Penting untuk Armada Rental

Masalah yang sering kejadian di lapangan

KPI yang “wajib ada” untuk rental

2. Data Model Minimal yang Bikin Dashboard Nendang

Entity yang disarankan

Tabel ringkas status unit (agar semua orang 1 bahasa)

3. Arsitektur Cepat: FastAPI sebagai Backend, Dashboard sebagai Produk

Komponen yang saya pakai (pragmatis)

Kenapa FastAPI cocok

4. Cara Menghitung Ketersediaan Unit Tanpa Drama

Prinsip kalkulasi

Edge case yang sering dilupakan

Tabel contoh aturan overlap

5. Jadwal Servis: Dari “Ingat-ingat” Jadi Sistematis

Pola yang efektif

Checklist servis yang bisa ditampilkan

6. Laporan Pemakaian: Biar Keputusan Tarif Nggak Pakai Perasaan

Format laporan yang enak dibaca

Contoh ringkas tabel laporan mingguan

7. UI/UX Dashboard yang “CoderLegion Banget”

Pola UI yang terasa modern

Microcopy yang membantu operasional

8. Security & Reliability: Jangan Sampai Dashboard Jadi Titik Lemah

Minimal baseline yang saya sarankan

Observability yang simple tapi berguna

FAQ

HowTo

Dari Data Jadi Insight yang Bisa Dipakai Tim

Best practices for RESTful API design for Dev Tools

Use Resource-Oriented URIs

Implement Proper HTTP Methods

Status Codes Matter

Version Your API

Keep Responses Consistent

Pagination and Filtering

Authentication and Security

Documentation is Key

Error Handling

Conclusion