Forem: Timothy Leung

Discovering n8n — Wish I Found It Sooner (Part 2)

Timothy Leung — Mon, 26 Jan 2026 09:05:07 +0000

This is workflow diagram in n8n

Hello everyone, I studied n8n for four days and then took its certification exam (Part 1), and I passed. I wouldn’t have known otherwise that it’s very easy to get started with and can handle many different types of projects. One example I’ve seen is a workflow for scheduling YouTube video uploads. You can really see how much potential it has! But no matter how complex things get, you should always start simple. Now I’d like to share a simple workflow with everyone.

Step-by-step: Understanding this n8n workflow

This workflow runs on a schedule, fetches order data via an API, checks a condition, then splits into two paths:

Path A: store/update orders and generate a detailed CSV for processing orders
Path B: calculate the total blocked orders and display a completion message

1) Schedule Trigger (start automatically)

Node: Schedule Trigger

Purpose: Starts the workflow at a defined interval (for example, every hour or every day).

Setup:

Choose a schedule type (interval or Cron)
Set time zone (optional)

2) HTTP Request (fetch orders from an API)

Node: HTTP Request

Purpose: Calls an external endpoint and returns order data (usually JSON).

Setup:

Method: GET (common)
URL: your orders endpoint
Authentication: API key/Bearer token (if required)
Response format: JSON

Expected output: order items/records to be processed downstream.

3) IF (branch based on a condition)

Node: IF

Purpose: Routes the execution depending on a rule (for example, whether orders exist, or whether status matches a value).

Setup ideas:

“Do we have any orders?”
“Is order status = processing?”
“Is blocked count > 0?”

Result: Two branches: true and false.

Path A — Processing orders → Upsert → CSV export

4) Upsert row(s) (insert or update records)

Node: Upsert row(s)

Purpose: Writes orders into a destination (database/spreadsheet) and updates existing rows based on a unique key.

Setup:

Select the destination (e.g., DB table / sheet)
Choose a unique match key (e.g., order_id)
Map incoming fields to columns (status, amount, timestamps, etc.)

5) Convert to CSV — Processing Orders

Node: Convert to CSV — Processing Orders

Purpose: Converts the processing-orders dataset into CSV.

Setup:

Choose included fields/columns
Enable headers (recommended)
Ensure only processing orders reach this step (via IF/filter)

Output: CSV content (text/binary depending on node).

6) Detailed Processing Orders CSV (save/send the CSV)

Node: Detailed Processing Orders CSV

Purpose: Final action for the CSV, such as:

upload to cloud storage (Drive/S3)
email attachment
save file for reporting

Tip: Use a timestamped filename, e.g. processing_orders_YYYY-MM-DD.csv.

Path B — Blocked orders → totals → message

7) Total Blocked Orders (aggregate or summarize)

Node: Total Blocked Orders

Purpose: Computes metrics such as:

number of blocked orders
total blocked amount

Setup:

Make sure only blocked orders reach this node
Use an aggregate/function step to compute totals

Code:

const items = $input.all();

let totalRecord=items.length;


let bookedSum = 0;

for (const item of items) {
  const v = Number(item.json.orderPrice ?? 0);
  if (!Number.isNaN(v)) bookedSum += v;
}



return [{ json: { totalRecord, bookedSum } }];

8) Show Message for Completed Orders (notify/log)

Node: Show Message for Completed Orders

Purpose: Provides a completion notice (execution log, Slack, email, etc.).

Example message:

“Workflow completed. Blocked orders: X. Processing orders CSV generated.”

{{ $json.count }} orders are booked

Then, it becomes:

Now, you can click Executive Workflow to check how does it go.

How to verify it in the Execution Window

In the execution view, confirm:

the HTTP request returns items successfully
the IF node routes to the correct branch
the CSV step produces the expected row/column set
totals and notifications match the data

I am preparing for Part 2 and hope I can pass next week. When the time comes, I will share my exam tips and strategies.

Connect with Me

GitHub: https://github.com/timleunghk
LinkedIn: https://www.linkedin.com/in/timothy-leung-48261b8b

Discovering n8n — Wish I Found It Sooner (Part 1)

Timothy Leung — Mon, 12 Jan 2026 06:15:49 +0000

I can't believe I didn't find n8n earlier. If I met it earlier, I could make many many wonderful Apps. This is my first image when I know n8n.

Introduction

I recently discovered n8n, and honestly, I can’t believe I didn’t find it earlier. If I had discovered it sooner, I could have built so many useful (and fun) automations.

n8n is a workflow automation tool that lets you connect apps and services with a visual, node-based editor. You can run it in the cloud, but you can also self-host it—so you fully control your data and environment.

In this article, we’ll do two things:

Set up n8n locally with Docker (safe, isolated, and easy to reset).
Create a simple Webhook workflow and send a test request to trigger it.

By the end, you’ll have n8n running at http://localhost:5678 and you’ll be able to trigger your first workflow from PowerShell.

Setup Locally

You may start programming in n8n cloud editon. So, you can skip this step. However, if you setup your local environment, you will get a full picture of the universe of n8n.

Before you start this setup, I recommend using Docker because it isolates everything from your host machine. Even if something goes wrong, it won’t impact your main environment.

I’ll show you how to install n8n locally with Docker, step by step. On Windows, install Docker Desktop. On macOS or Linux, install Docker.

Step 1: Create Folder / Directory

You can type following commands to create these folders

mkdir C:\n8n-demo
cd C:\n8n-demo

You can copy this docker compose script first.

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      # Basic
      - N8N_HOST=localhost
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - WEBHOOK_URL=http://localhost:5678/
      - N8N_EDITOR_BASE_URL=http://localhost:5678/

      # Timezone
      - TZ=Asia/Hong_Kong
      - GENERIC_TIMEZONE=Asia/Hong_Kong

      # Security / hygiene (recommended)
      - N8N_ENCRYPTION_KEY=change_me_to_a_long_random_string

      # Optional: disable diagnostics
      - N8N_DIAGNOSTICS_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Step 2: Start n8b

cd C:\n8n-demo
docker compose up -d
docker compose ps

Docker will start download images and process setup automatically based on your setup in above script. Please wait few seconds to finish it. After that, you can access your n8n website http://localhost:5678. If you want to access your n8n outside your PC, please modify the code

- WEBHOOK_URL=http://localhost:5678/
- N8N_EDITOR_BASE_URL=http://localhost:5678/

- WEBHOOK_URL=http://<YOUR IP ADDRESS>:<<YOUR PORT NUMBER>
- N8N_EDITOR_BASE_URL=http://<YOUR IP ADDRESS>:<YOUR PORT NUMBER>
- N8N_SECURE_COOKIE=false

OR use dynamic DNS service

- WEBHOOK_URL=https://<YOUR DYNAMIC DNS URL>
- N8N_EDITOR_BASE_URL=https://<YOUR DYNAMIC DNS URL>

Hello n8n, Hello World!

If you see this screen, Conguratulation! It means you've entered an universe of n8n!

You can now provide your name, e-mail and password and then submit. You'll get a activation key in your mailbox. It makes you access it for lifetime!! That's why I suggest you use local environment.

Say "Hello World" with Webhook

The Webhook node in n8n lets your workflow receive incoming HTTP requests (such as GET, POST, or PUT). When a request hits the webhook URL, it triggers the workflow so you can process the data and respond. In this article, we’ll use it to return a simple “Hello, World!” response from n8n.

Here is your first screen of creating your first workflow

Create your Webhook

Step 1: Click on the "+" icon.
Step 2: Type "Webhook" as shown below

Step 3: Select "Webhook" (The first one)

Then, you can see the properties screen of webhook as below:

Then, modify the following values:

HTTP Method: POST
Path:hellopath
Authentication:None
Response:Immediately

Step 4: Ping It!
Before starting ping, click Listen for test event button. After clicking this button, it is start listening now.

While it is listening, open your Power Shell Command Windows and then type the following command

Invoke-RestMethod -Method Post `
  -Uri "http://localhost:5678/webhook-test/hellopath" `
  -ContentType "application/json" `
  -Body '{"ping":"pong"}'

If you see message returns Workflow has started, congratulations! You've already create your own automation successfully!

Closing Thoughts

That’s it! You’ve now installed n8n locally with Docker and triggered your first workflow using a webhook. In the next article, we can build on this by adding more nodes (for example, transforming the incoming JSON, sending a reply, or connecting to external services) and turning this simple test into a real automation.

Connect with Me

GitHub: https://github.com/timleunghk
LinkedIn: https://www.linkedin.com/in/timothy-leung-48261b8b

The Deadline That Made Me Rethink My Architecture: Building Timesheetflow with Domain Thinking

Timothy Leung — Sun, 04 Jan 2026 13:58:54 +0000

“Can your system enforce a month-end deadline, handle late submissions fairly, and still produce a clean payroll summary?”

That one question changed how I approached what I initially thought was “just Excel processing”.

I was building Timesheetflow—a small system to automate monthly employee timesheets that are still submitted as Excel files (because, realistically, many teams still live in spreadsheets).

At first, I designed it like a typical file-processing app:

read Excel files
validate rows
merge results
export a summary

It worked.

But it didn’t explain the business. And it didn’t protect the business rules that actually matter at month-end.

The Real Workflow (What the Business Actually Does)

Timesheetflow’s workflow is simple—and very real:

Admin sets a processing deadline (usually month-end)
Employees upload their own monthly timesheet to a Google Drive folder before the deadline
submissions are for the current month only
At the deadline, the system processes timesheets one by one
Approvers review and approve one, many, or all timesheets
late submissions are allowed but clearly marked Late
Admin downloads an Excel salary summary for that month

When I wrote it down like this, I realized something:

This isn’t an “Excel automation” problem.

This is a monthly payroll close problem.

What I Thought the Problem Was

My first approach was very implementation-driven:

“There’s a Drive folder”
“There are Excel files”
“I need to parse and export”

So my architecture naturally became a pipeline:

Drive client downloads files
a parser extracts rows
a validator checks columns
an exporter builds a consolidated report

It looked clean… but the code kept reading like:

“update tables, move files, generate output”

Instead of:

“close the month, enforce the deadline, approve submissions, finalize payroll”

That difference sounds subtle, but it changes everything—especially when requirements evolve.

What I Realized Afterward

Good architecture isn’t just about layers and patterns.

It’s about meaning.

The moment I treated the month-end workflow as a _domain _(instead of a batch job), the design got clearer:

A deadline isn’t a timestamp field—it’s a rule that changes system behavior.
“Late” isn’t a warning label—it affects approval visibility and auditability.
“Latest submission wins” isn’t a query trick—it’s a policy the business depends on.

The Ubiquitous Language I Started Using

Once I stopped thinking in “files” and started thinking in “business”, the vocabulary became obvious:

Monthly Run / Payroll Period (the month being closed)
Deadline (the cutoff time)
Timesheet Submission (one employee’s monthly entry)
Late Submission (allowed, but flagged)
Latest Submission Wins (policy when employees upload multiple versions)
Approval (approve/reject, bulk approve valid)
Salary Summary Export (the admin deliverable)
When your code uses this language, you don’t need long comments to explain what it does.

Before vs After (Pipeline Thinking vs Domain Thinking)

Before: “Process files”

// Pipeline mindset: process whatever is in the folder
var files = drive.ListXlsxFiles(folderId);

foreach (var file in files)
{
    var rows = ParseExcel(file);
    Validate(rows);
    Save(rows);
}

ExportSalarySummary();

It works—but it hides the real rules:

Which month is this?
Is the deadline enforced?
Which file wins if an employee uploads twice?
What happens after approval?

After: “Close a monthly run”

// Domain mindset: close a payroll period with explicit rules
run.LockAtDeadline(now);

run.RefreshSubmissionsFromDrive();   // latest submission wins
run.FlagLateSubmissions();           // uploaded after deadline

foreach (var submission in run.ActiveSubmissions())
{
    submission.ValidateCurrentMonthOnly();
}

approvals.ApproveAllValid(run);      // late is a badge, invalid blocks approval

var report = payroll.ExportSalarySummary(run); // Excel for admin

Now the code reads like the business process:

lock the period
evaluate submissions under known rules
approve what’s valid
export the payroll summary

That shift made everything easier to maintain and explain.

Key Domain Rules (That Matter More Than Excel)

Here are the policies I implemented in Timesheetflow’s MVP:

1) Current month only

Employees can submit timesheets for the active month only.

2) Deadline locks the run

At the deadline, the run transitions into a “locked” phase for processing.

3) Late submissions are allowed, but flagged

After the deadline, submissions are marked Late and stay visible in approval/export.

4) Latest submission wins

If an employee uploads multiple timesheets for the same month:

the system uses the most recent file (by Drive timestamps)
older ones are marked superseded

5) Invalid beats late

If a timesheet is invalid, it’s invalid—whether it’s late or not.
Late is a badge. Invalid is a blocker.

6) Salary export is the admin deliverable

The end result is not “processed rows”—it’s a monthly Excel summary that payroll/admin can use.

Implementation Notes (Tech Stack)

Timesheetflow is built with:

ASP.NET Core (.NET 8) for Web + API
Hangfire for deadline scheduling and background processing
ClosedXML for Excel parsing/export
Google Drive as the submission channel (Workspace folder + service account access)

Even with a simple stack, modeling the domain clearly made the system feel “product-like” instead of “script-like”.

Key Takeaways

This wasn’t really an Excel problem—it was a month-end payroll close problem.
Deadlines, late flags, and “latest submission wins” are domain rules, not utility logic.
When code mirrors the business language, it becomes easier to read, test, and extend.
The best architecture doesn’t just run—it communicates intent.

Closing Thoughts

I started Timesheetflow thinking I was building an Excel automation tool.

But the real value came when I stopped designing around files and started designing around the workflow the business lives by every month.

If you’ve ever had a moment where a “simple automation” turned out to be a domain problem in disguise, I’d love to hear it.

Connect with Me

GitHub: https://github.com/timleunghk
LinkedIn: https://www.linkedin.com/in/timothy-leung-48261b8b

If you’d like, I can also share:

a minimal domain model (MonthlyRun, TimesheetSubmission, Approval) for .NET 8
a Hangfire job layout for the deadline + processing pipeline
an example Salary_Summary.xlsx structure (ByEmployee / Details / Exceptions)
Just tell me whether you want the article to include code that compiles (full sample classes), or keep it at conceptual snippets like this post.

The Interview Question That Made Me Rethink My Architecture: Understanding Domain‑Driven Design

Timothy Leung — Sun, 21 Dec 2025 04:20:22 +0000

“Can you explain how you’ve used Domain‑Driven Design in your past projects?”

That one simple question stopped me cold.

🌱 The Interview Question
It was my second interview — and also my last one for that position.
After the first round, the interviewer had mentioned that a technical test would be required.
So, when I got the invitation to the second interview, I spent almost a week preparing — mostly focusing on LINQ and Entity Framework in .NET Core.

My programming journey started with Visual Basic 6, then moved to VB.NET, and later to C# and Python.
In my C# years, I mostly worked with ADO.NET, writing raw SQL queries and stored procedures.
That’s why I wasn’t familiar with these newer methodologies — and I knew that was a weakness I had to fix.

So I spent a week catching up. It only took a couple of days to get the big picture (thanks to my previous experience), and the rest of the week went into polishing and preparing for the test.

🤔 What I Thought DDD Was
During the interview, I explained my architecture like this:

Repositories communicated with the database through Entity Framework
Services used these repositories to handle business logic
Controllers acted as endpoints, exchanging data with frontend or mobile apps
After I finished, the interviewer smiled and said:

“Tim, you’re smart, honestly.”

When the interview ended, I asked an AI what that architecture style was called.
The answer came back: Domain‑Driven Design.

That moment surprised me — I had been applying some parts of DDD all along, without even realizing it.

💡 What I Realized Afterward
At first, I thought DDD was just about extra layers: entities, repositories, services… like a neatly organized folder structure.

But I later realized DDD is not about structure — it’s about meaning.

It’s about how the structure represents the real business domain.
The key idea is the ubiquitous language — code that mirrors how the business actually talks about its work.

Instead of thinking:

“This function updates a table.”

DDD makes you think:

“This function completes an order.”

The difference sounds small, but it completely changes how you design, read, and discuss your code.

The interviewer hadn’t been testing my knowledge of frameworks — he’d been testing whether I could connect technical implementation with business intent.
And that is what Domain‑Driven Design is all about.

🧭 What DDD Really Means (in Simple Terms)
Here’s how I now understand DDD’s main ideas:

Domain – The real-world problem space you’re modeling (orders, payments, customers…).
Ubiquitous Language – A shared language between developers and domain experts.
Entities – Objects that have identity and lifecycle (like Order, Customer).
Value Objects – Define characteristics without identity (like Money, Address).
Aggregates – Groups of entities that change together as one unit.
Repositories – Abstract persistence, letting you save or load aggregates without leaking database logic.

🧱 Applying That Insight
Before that interview, my OrderService looked like this:
csharp

public void CompleteOrder(int orderId)
{
    var order = _repository.GetById(orderId);
    order.Status = "Completed";
    _repository.Update(order);
}

It works — but it’s mainly data‑driven.

After learning about the domain perspective, I rewrote it to express intent, not CRUD actions:

csharp

public void CompleteOrder(Order order)
{
    order.MarkAsCompleted();
    _repository.Save(order);
}

Now, the focus is on what the business is doing — not how the database changes.
That one small shift made my architecture feel cleaner, more readable, and more meaningful.

✍️ Key Takeaways
DDD isn’t about fancy patterns or layers — it’s about representing the business domain in code.
Even if you’re not applying full DDD, thinking in domain terms makes your code clearer and more maintainable.
The best architecture doesn’t just run — it communicates.

🔚 Closing Thoughts
That interview taught me something I didn’t expect —
sometimes, you already understand good architectural principles — you just haven’t learnt the name for them yet.

And that’s okay.
Understanding comes in layers — just like good architecture.

🧩 Thanks for reading! If this story resonated with you or helped clarify what DDD really means, consider leaving a comment — I’d love to hear your own “aha!” moments too.

🌐 Connect with Me
💻 GitHub: https://github.com/timleunghk
💼 LinkedIn: https://www.linkedin.com/in/timothy-leung-48261b8b/

⭐ If you enjoyed this article, feel free to follow me on dev.to or star my GitHub projects — I’m always exploring new ways to make code tell better stories.