Forem: Deny Herianto

Building an AI Code Reviewer for GitLab CI with Google Gemini

Deny Herianto — Wed, 04 Mar 2026 12:07:39 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

Niteni, Javanese for "to observe carefully", is an AI-powered code review tool for GitLab CI pipelines, powered by the Gemini REST API.

GitLab's Free tier doesn't have a built-in AI review feature. I wanted something that would run inside a standard CI job, post inline diff comments (not a wall of text), and provide one-click "Apply suggestion" buttons, all without pulling in any npm runtime dependencies.

That last constraint was deliberate. CI environments are ephemeral. Every npm install is wasted time and a potential failure point. So Niteni uses only Node.js built-ins: https, fs, path, os, and url. Gemini does the heavy lifting via a direct REST call.

How Gemini fits in

Niteni sends the full MR diff to Gemini and asks it to return a structured list of findings, each with a severity level (CRITICAL, HIGH, MEDIUM, LOW), file path, line number, description, and optional suggestion. Those findings get posted as inline GitLab discussion comments with suggestion blocks the reviewer can apply in one click.

async review(diffContent: string): Promise<ReviewResult> {
  const apiResult = await this.reviewWithAPI(diffContent);
  if (apiResult && this.isValidStructuredReview(apiResult)) {
    return apiResult;
  }
  throw new Error('Review failed: empty or malformed structured response.');
}

A direct HTTP call to generativelanguage.googleapis.com, no CLI, no extensions, no sandbox issues. Just an API key and a network connection.

Demo

The tool runs as a GitLab CI job. After a push, it posts inline comments like this:

You can try it yourself: github.com/denyherianto/niteni

What I Learned

1. Gemini CLI ≠ CI-friendly

My first approach used a cascading strategy: Gemini CLI /code-review extension → CLI prompt → REST API. The CLI approaches failed every time in CI because Gemini CLI restricts its toolset in non-interactive (non-TTY) mode, the /code-review extension can't even run git diff. No Docker image change fixes this. The simplest solution turned out to be the best: just call the API directly.

2. Structured output beats regex parsing

Early versions asked Gemini for markdown and parsed it with regex. This was fragile, brackets optional, format drift between model versions, lastIndex state bugs in exec() loops:

// Handles both: **[CRITICAL]** and **CRITICAL**
const findingRegex = /\*\*\[?(CRITICAL|HIGH|MEDIUM|LOW)\]?\*\*\s*`([^`]+)`/g;

Migrating to Gemini's structured output (responseMimeType: "application/json" + responseSchema) eliminated the entire parsing layer. Findings come back as typed JSON objects. No regex, no format drift, no silent data loss.

3. GitLab CI variable "pass-through" is a trap

This looks innocent:

variables:
  GEMINI_API_KEY: $GEMINI_API_KEY  # ← circular reference

GitLab expands this to the literal string $GEMINI_API_KEY instead of the secret value. The fix: don't re-declare project-level CI/CD variables. They're available in every job automatically.

4. `execFileSync` over `execSync` for security

The original code built shell commands as strings. Branch names come from user input in CI, a branch named main; rm -rf / would be a shell injection. Switching to execFileSync('git', ['diff', '--merge-base',origin/${targetBranch}]) calls the binary directly, no shell interpretation.

5. URL-encoding every path parameter

GitLab project IDs can be namespaced paths (my-group/my-project). Without encodeURIComponent(), a branch named feature/auth silently becomes a path traversal. Every parameter, project ID, MR IID, file path, branch ref, gets encoded.

Google Gemini Feedback

What worked well:

Structured output / JSON mode is the standout feature. Once I switched from markdown + regex to responseSchema, reliability jumped dramatically. The schema enforcement means I can trust the shape of the response and write typed TypeScript around it.
temperature: 0.2 produces consistent, deterministic reviews. This is important for CI, you don't want findings to appear and disappear between pipeline runs on the same code.
65k output token limit means Niteni can review large diffs without truncation. This was a real concern early on.
The REST API itself is clean and well-documented. Direct HTTP calls from Node's https module work without friction.

Where I hit friction:

Error messages from the API are sometimes opaque. A JSON parse failure mid-response (unterminated string at character 1326) gave no signal about why the output was truncated. More structured error payloads would make debugging easier.
Rate limits during testing are easy to hit when you're running the tool repeatedly against the same MR. Clearer rate limit headers in responses would let the client back off gracefully instead of just failing.

Overall, Gemini's structured output capability was the key unlock for making Niteni reliable enough to trust in automated CI pipelines. The shift from "parse whatever the LLM returns" to "enforce a schema and get typed objects" is something I'd apply to any future LLM integration.

Code: github.com/denyherianto/niteni

Building Disaster Pulse: What Happened When I Let AI Decide If a Disaster Is Real

Deny Herianto — Tue, 03 Mar 2026 16:39:54 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

I live in Indonesia. We sit on the Ring of Fire, an archipelago of 17,000 islands, home to 40% of the world's active volcanoes, and a long, painful history of disasters that moved too fast and warned too late.

In November 2025, Tropical Cyclone Senyar made landfall in northeastern Sumatra with around 1,090–1,207 people died. Over 1.1 million people were displaced. The cyclone itself was relatively small, the real damage came from deforested watersheds that had no natural buffer left. Information about the disaster spread across TikTok, WhatsApp, news sites, and government agencies, all at once, in fragments, with varying levels of accuracy.

That's the origin of Disaster Pulse, an AI-powered disaster intelligence platform I built for the Gemini 3 Hackathon.

What I Built with Google Gemini

Disaster Pulse is a real-time disaster detection and alert system designed for Indonesia. When Cyclone Senyar hit Sumatra, information came from everywhere, BMKG (Indonesia's meteorological agency), TikTok videos of people filming floodwater from rooftops, WhatsApp forwarded messages, news RSS feeds, and user reports from people trying to locate missing relatives. Most of it was noise. Some of it was life-or-death signal.

The app's job is to separate those two.

Here's where Gemini comes in: I built a 5-agent reasoning pipeline powered by Gemini to process every incoming signal before it becomes an alert on the dashboard.

Observer → Classifier → Skeptic → Synthesizer → Action

Each agent has a single job:

Observer: Reads the raw signal (text, video frame, user report) and writes factual observations
Classifier: Assigns event type, severity, and affected radius
Skeptic: Actively looks for reasons the previous agents are wrong, hallucination prevention
Synthesizer: Weighs all evidence and produces a confidence-scored verdict
Action: Decides whether to create a new incident, update an existing one, or discard the signal

The VideoAnalysisAgent is the one I'm most proud of. It uses Gemini's multimodal capabilities to analyze video frames from social media, checking for visual flood indicators, fire signatures, and structural damage, then applies a freshness rule: if the video metadata suggests it was filmed more than 6 hours ago, the severity score gets downgraded. Old content shouldn't trigger live alerts.

Beyond the AI pipeline, the app includes:

Real-time dashboard with incident severity cards
Live map showing affected zones
Community verification system (human-in-the-loop)
SSE-powered live intelligence ticker showing agent activity
Mobile-first PWA for field workers

Tech stack: NestJS (API), Next.js 15 (web), PostgreSQL, Drizzle ORM, Gemini API, Turborepo monorepo.

Demo

https://disaster-pulse.denyherianto.com

Here's a quick look at the core pipeline in action. The Live Intelligence Ticker shows each agent processing a signal in real time:

[Observer]    Reading signal: TikTok video, 0:42, location metadata: North Sumatra
[Classifier]  Event type: flood | Severity: high | Confidence: 0.84
[Skeptic]     ⚠ Video upload timestamp 14h ago, possible recirculation of 2022 Palu footage
[Synthesizer] Verdict: DOWNGRADE severity to low | Freshness penalty applied
[Action]      Signal discarded, insufficient confidence threshold

What I Learned

Multi-agent architecture is harder than it looks

I thought about building a single "smart prompt" to classify disasters. I'm glad I didn't.

The Skeptic agent alone probably saves the most embarrassment. Early on, without it, the pipeline would happily classify someone's video of a smoke machine at a concert as "fire, high severity." The Skeptic looks at the Classifier's output and asks: what if this is wrong? That adversarial framing is the difference between a toy and something I'd trust in production.

But chains have failure modes. If the Observer writes a vague summary, the Classifier gets bad input, the Skeptic has nothing solid to critique, and the Synthesizer is guessing. I learned to write very explicit output schemas for each agent, not just "describe what you see" but "output JSON with fields: event_type, confidence, evidence_list, contradictions."

Structured output with Gemini was a game-changer here.

Multimodal processing isn't free

Video analysis sounds straightforward until you're pulling frames from a TikTok video at 3 AM, sampling every 2 seconds, and sending each frame to the Gemini API with a detailed prompt. Token costs add up fast. I had to be strategic: sample at lower frequency for longer videos, cache identical frames (TikTok compression creates a lot of duplicates), and set hard limits on video length per analysis job.

The freshness rule emerged from a real problem: during Cyclone Senyar, videos from the 2022 Cianjur earthquake and the 2018 Palu tsunami were getting recirculated on TikTok alongside actual Sumatra flood footage. People were sharing old disasters in the panic of a new one. Without the freshness check, the pipeline would treat a 2018 video as a live signal. Metadata-based time-checking was a simple fix that meaningfully improved signal quality.

The empty state kills demos

I almost demoed with no data. I had built the entire pipeline and UI but hadn't thought about what judges see when they open the app for the first time.

Nothing.

I scrambled and built a demo seed system, a script that populates the database with a realistic scenario based on Cyclone Senyar: flood alerts across North Sumatra, multiple user verification reports with conflicting severity estimates, landslide signals from Mandailing Natal, and full agent traces showing the reasoning chain. A hidden trigger in the frontend (tap the logo 5 times) resets and re-seeds everything.

Lesson: build for the demo from day one. The feature doesn't matter if the judge sees a blank screen.

The hardest part wasn't the AI, it was making the AI visible

I had a sophisticated 5-agent pipeline running, but from the user's perspective, disaster cards just... appeared on a dashboard. There was no way to see why something was classified high severity or what the Skeptic had flagged.

This is the black box problem. In disaster alerting, a black box is a liability. With Cyclone Senyar, the difference between "flooding in Mandailing Natal" and "flooding in Mandailing Natal, confidence 0.91, corroborated by BMKG water level data + 3 user reports + video analysis" is the difference between a coordinator acting or waiting for more information.

Building the AI Transparency Panel, a "Why?" button that exposes the full agent trace, changed the product from a dashboard into a decision-support tool. That distinction matters enormously for real-world impact.

One moment that stuck

At some point during the hackathon, I was debugging the Skeptic agent and fed it a signal I thought was obviously a live Sumatra flood report, a news article with dramatic photos of floodwater submerging houses.

The Skeptic came back: "The article references events from 2022. The images match historical flood patterns from that period. This signal should not trigger a live alert."

It was right. I had been testing with old data I'd scraped as examples, and the agent caught it.

There's something a little unsettling about an AI being more careful than I was. But mostly it made me trust the architecture. That's what I want to keep building toward: systems that are genuinely more careful, not just faster.

Google Gemini Feedback

What worked really well

Structured output is exceptional. Gemini's ability to reliably return JSON matching a schema is the foundation the entire multi-agent pipeline is built on. Without it, I'd be writing fragile regex parsers to extract data from free-text responses. With it, every agent output is predictable, typeable, and chainable. This is the feature I'd highlight to any developer building agentic systems.

Multimodal + long context together. The combination of sending video frames and having the model hold enough context to reason across them is genuinely powerful. For the VideoAnalysisAgent, I send multiple frames with temporal metadata and ask the model to reason about change over time. It handles this well.

Speed on Gemini Flash. For a real-time alert system, latency matters. Flash is fast enough that the agent pipeline completes within a few seconds for most signals, which means dashboard updates feel live rather than batched.

Where I hit friction

Rate limits during development are brutal. When you're building a pipeline that chains 5 API calls per signal and testing with a seed of 20 signals, you hit limits fast. The error messages could be more actionable, "quota exceeded" without any indication of which quota (per-minute, per-day, per-project) cost me real debugging time.

Structured output edge cases aren't well documented. What happens when the model can't produce valid output for a schema? Sometimes the API returns a malformed response silently rather than throwing an error. I had to add defensive validation at every agent step to catch this. It's a correctness issue I didn't expect going in.

Grounding/search integration has a learning curve. I wanted to cross-reference incidents with historical BMKG data, but integrating Google Search grounding into a multi-step pipeline, where only some steps should use grounding, required more plumbing than I expected. I ended up implementing a separate SignalEnrichmentAgent just for this, which added complexity.

Streaming in chained calls needs better SDK support. I wanted to show real-time agent "thinking" in the UI, streaming tokens from each agent as they processed. Gemini supports streaming, but building it into a pipeline where one agent's output feeds the next's input required significant SSE infrastructure on my side. I got it working, but the SDK could make this pattern easier.

This project isn't going back in a drawer. Next steps: Cloud Run deployment, formal BMKG API integration, offline PWA capability, and eventually, getting it in front of people who actually coordinate disaster response in Indonesia.

Disaster Pulse is open source. Feedback welcome, especially from anyone working in disaster response.

Github: https://github.com/denyherianto/disaster-pulse

Built with Gemini API, NestJS, Next.js, and a lot of coffee.

Why Your IndexedDB Data Keeps Disappearing

Deny Herianto — Tue, 03 Mar 2026 16:28:44 +0000

You build a web app. You store data in IndexedDB. It works great, until one day a user reports that all their data is just... gone. No error. No warning. It's as if it never existed.

This happened to me with Mock Studio, a Chrome extension that stores API mocks in IndexedDB using Dexie.js. Users would work for days building up their mock configurations, then come back to find everything wiped. We dug in and found three root causes, all fixable. Here's what we learned.

The Short Version

IndexedDB data can silently disappear because:

Chrome evicts your entire database when storage quota is exceeded, and your app might be filling it up faster than you think.
An abrupt connection close mid-write loses uncommitted data, service worker restarts can trigger this.
A "clear then import" pattern leaves you with nothing if the import fails, even inside a transaction.

Root Cause #1: Chrome Will Evict Your Entire Database

This is the one that hurts the most because it's invisible until it's too late.

Browsers allocate storage to origins (a combination of scheme + host + port). When an origin exceeds its quota, Chrome doesn't trim your data gracefully, it evicts the entire origin's storage: IndexedDB, Cache API, localStorage, all of it. Gone.

How we hit this

Our extension's network logging feature stored every captured HTTP request in IndexedDB, including the full response body:

const newRequest = {
  method: request.request.method,
  url: request.request.url,
  status: request.response.status,
  content: content || undefined,  // ← full response body, no size check
  // ...
};

await db.networkLogs.add(newRequest);

We had a row count limit of 50,000 records. Sounds reasonable. But 50,000 records × potentially megabytes of response body each = gigabytes of storage. On a busy app making lots of API calls, this table would balloon fast.

When the storage quota was exceeded, Chrome evicted CMockDB, wiping out all the user's mocks, projects, and environments along with the logs. The user lost everything because of a logging side-feature they didn't even know existed.

The fix

Stop storing what you don't need. We only needed aggregate stats (counts, average times, error rates), not raw response bodies. Removing the raw log storage entirely solved the problem.

If you do need raw logs, apply a size-based limit, not just a row count:

// Check byte size before storing
const contentSize = new Blob([content]).size;
const entry = {
  ...requestData,
  content: contentSize < 50_000 ? content : undefined, // skip bodies > 50KB
};

Or cap by row count but make it realistic, 500 rows of potentially-large records is very different from 500 rows of small records.

How to protect your extension from eviction

For Chrome extensions specifically, add unlimitedStorage to your manifest.json:

{
  "permissions": [
    "storage",
    "unlimitedStorage"
  ]
}

This exempts your extension's storage from Chrome's quota-based eviction. Without it, your extension is subject to the same eviction policy as any website.

For regular web apps, you can request persistent storage, the browser will ask the user for permission and the data won't be evicted without explicit user action:

const persisted = await navigator.storage.persist();
if (persisted) {
  console.log('Storage will not be evicted');
}

You can also check how much quota you're using before it becomes a problem:

const estimate = await navigator.storage.estimate();
console.log(`Using ${estimate.usage} of ${estimate.quota} bytes`);

Root Cause #2: Service Worker Restarts Can Abort In-Flight Writes

Chrome terminates idle service workers after about 30 seconds of inactivity and restarts them on demand. When a restart happens while a database write is in progress, the write can be lost.

How this works in practice

When a new service worker instance starts up, it opens a new connection to IndexedDB. If your existing page (say, a DevTools panel) already has an open connection, the browser fires a versionchange event on the old connection. The standard pattern for handling this is to close the old connection immediately:

this.on('versionchange', () => {
  this.close(); // Let the upgrade proceed
});

This is correct, but it's incomplete. After close() is called, any subsequent operations on that db instance will fail with a "Database is closing" or "Connection is closing" error. Your Zustand store might have already applied an optimistic UI update, but the actual DB write never completed. On the next page load, the data isn't there.

The fix

Reopen the connection after closing it:

this.on('versionchange', () => {
  this.close();
  this.open().catch((err) => {
    console.warn('Failed to reopen DB after version change:', err);
  });
});

This ensures the connection is restored automatically after the upgrade completes, without requiring a full page reload.

Root Cause #3: "Clear Then Import" Leaves You With Nothing on Failure

This one is a logic trap that's easy to fall into. If you implement a backup/restore feature, you probably wrote something like this:

await db.transaction('rw', [db.projects, db.mocks, ...], async () => {
  // Step 1: Wipe everything
  await db.projects.clear();
  await db.mocks.clear();
  // ...

  // Step 2: Import new data
  await db.projects.bulkAdd(data.projects);
  await db.mocks.bulkAdd(data.mocks); // ← what if this throws?
});

It's all in a transaction, so if bulkAdd throws, the transaction rolls back, right?

Yes, but you still end up with an empty database.

A transaction rollback undoes every operation in the transaction, including the clear() calls. So technically the data is restored. But if the rollback itself fails (e.g., a connection drops mid-rollback, or the browser crashes), or if your error handling logic doesn't expect the rollback path, the user sees an empty app.

More critically: if you're using Dexie and the bulkAdd encounters a constraint error with default options, it may reject with a partial write, some records added, some not, and the rollback may not be as clean as you expect depending on the error type.

The fix

Take a snapshot before you clear anything, and use it as an explicit fallback:

const snapshot = await exportAllData(); // capture current state

try {
  await db.transaction('rw', [...tables], async () => {
    await db.projects.clear();
    await db.mocks.clear();
    // ...
    await db.projects.bulkAdd(data.projects);
    await db.mocks.bulkAdd(data.mocks);
    // ...
  });
} catch (err) {
  // Import failed, restore the snapshot explicitly
  await db.transaction('rw', [...tables], async () => {
    await db.projects.clear();
    await db.mocks.clear();
    // ...
    await db.projects.bulkAdd(snapshot.projects);
    await db.mocks.bulkAdd(snapshot.mocks);
    // ...
  });
  throw err; // re-throw so the UI can show an error message
}

This is more verbose but the intent is explicit: if the import fails, the user's previous data is unconditionally restored.

Summary

Issue	Why It Happens	Fix
Full database eviction	Unbounded storage growth hits browser quota	Size-cap logged data; request persistent storage; use `unlimitedStorage` in extensions
Lost writes on reconnect	Service worker restart closes DB connection mid-write	Reopen DB automatically after `versionchange` close
Empty DB on import failure	Transaction rollback isn't always reliable as a recovery strategy	Snapshot before clearing, restore explicitly in catch block

The Bigger Lesson

IndexedDB is the closest thing to a real database that the browser gives you, but it doesn't behave like one in a few important ways:

No durability guarantee under quota pressure, the browser can reclaim storage without asking.
Connection lifecycle is tied to page/worker lifecycle, disconnections can happen at any time.
Transactions are atomic but not indestructible, network/browser crashes can interrupt them.

If your app uses IndexedDB to store data that users care about, treat it like you would any database: monitor usage, cap growth, handle reconnection, and always have a recovery path on destructive operations.

This post is based on a real debugging session on Mock Studio, a Chrome extension for mocking HTTP APIs. The fixes described here are live in production.

Built an open-source AI code review bot for GitLab using Gemini. Zero runtime dependencies, inline diff comments, and one-click suggestion buttons. Here's every gotcha I hit along the way!

Deny Herianto — Sun, 15 Feb 2026 16:16:12 +0000

Building Niteni: Gemini Code Review Bot for GitLab with Zero Dependencies

Deny Herianto ・ Feb 15

Building "Niteni": Gemini Code Review Bot for GitLab with Zero Dependencies

Deny Herianto — Sun, 15 Feb 2026 14:48:03 +0000

Niteni, Javanese for "to observe carefully." That's what this tool does: it watches your merge requests and tells you what you missed.

I built Niteni to solve a simple problem: I wanted automated, inline code review comments on GitLab merge requests, powered by Google's Gemini, without pulling in half of npm. Here's how it went and the surprising number of things that bit me along the way.

The Idea

GitLab's CI/CD pipelines are powerful, but there's no built-in AI review feature available on the Free tier like GitHub Copilot Reviews. I wanted something that would:

Run inside a standard GitLab CI job
Post findings as inline diff comments (not a wall-of-text MR note)
Provide one-click "Apply suggestion" buttons
Work without any runtime dependencies beyond Node.js itself

That last point was a deliberate constraint. CI environments are ephemeral. Every npm install in a pipeline is wasted time and a potential point of failure. So Niteni uses only Node.js built-ins: https, child_process, fs, path, os, and url.

Architecture: Direct API Call

Early prototypes tried a cascading strategy — Gemini CLI /code-review extension first, then CLI direct prompt, then REST API. But the CLI approaches proved unreliable in CI: Gemini CLI restricts its tool set in non-interactive mode, so the /code-review extension can't even run git diff. No amount of Docker image changes fixes this — it's a fundamental limitation of non-TTY environments.

The solution was simpler: just call the API directly.

async review(diffContent: string): Promise<string> {
  console.log('Reviewing code changes via Gemini REST API...');
  const apiResult = await this.reviewWithAPI(diffContent);
  if (apiResult && this.isStructuredReview(apiResult)) {
    console.log('Gemini REST API review completed successfully.');
    return apiResult;
  }

  throw new Error('Review failed: API response was empty or not in the expected structured format.');
}

A direct HTTP call to generativelanguage.googleapis.com gives us full control over the prompt, the model parameters (temperature: 0.2 for consistent output), and the response format. No CLI installation, no extension dependencies, no sandbox issues — just an API key and a network connection.

The isStructuredReview() method validates the response with a regex check for ### Summary, ### Findings, or severity markers like **CRITICAL**. This prevents malformed output from being posted as a review comment.

Gotcha #1: GitLab CI Variable Circular References

This one cost me hours of debugging. In .gitlab-ci.yml, if you do this:

niteni-code-review:
  variables:
    GEMINI_API_KEY: $GEMINI_API_KEY
    GITLAB_TOKEN: $GITLAB_TOKEN
  script:
    - niteni --mode mr

It looks reasonable, you're just "passing through" the project-level CI/CD variables. But GitLab interprets this as a circular reference. The variable GEMINI_API_KEY expands to the literal string $GEMINI_API_KEY instead of the actual secret value.

The fix: Don't re-declare project-level CI/CD variables in the variables: section. They're already available in every job automatically. Only declare variables in the job if they're new values (like GEMINI_MODEL: gemini-3-flash-preview).

Gotcha #2: Token Authentication is a Maze

GitLab supports three authentication methods, and picking the wrong header silently fails:

Token type	Header
Personal/Project access token	`PRIVATE-TOKEN: glpat-xxx`
CI job token	`JOB-TOKEN: $CI_JOB_TOKEN`
OAuth token	`Authorization: Bearer xxx`

My first implementation always used PRIVATE-TOKEN. It worked locally but failed in CI because $CI_JOB_TOKEN requires the JOB-TOKEN header. The config module now auto-detects the token type:

function resolveToken() {
  const gitlabToken = env.GITLAB_TOKEN && !env.GITLAB_TOKEN.startsWith('$')
    ? env.GITLAB_TOKEN : null;
  if (gitlabToken) return { token: gitlabToken, tokenType: 'private' };
  if (env.CI_JOB_TOKEN) return { token: env.CI_JOB_TOKEN, tokenType: 'job' };
  return { token: '', tokenType: 'private' };
}

Notice the !env.GITLAB_TOKEN.startsWith('$') guard that catches the circular reference gotcha from above. If the variable expanded to a literal $GITLAB_TOKEN string, we fall through to CI_JOB_TOKEN.

Gotcha #3: Inline Diff Comments Need `diff_refs`

GitLab's MR discussion API accepts a position parameter for inline comments. But the position requires three SHA values: base_sha, start_sha, and head_sha. These come from the MR's diff_refs field.

If diff_refs is null (which happens with certain merge strategies or force-pushes), the inline comment fails with a 400 error. The fallback? Post as a general discussion comment instead.

if (diffRefs) {
  try {
    await gitlab.postMergeRequestDiscussion(mrIid, body, position);
  } catch {
    // Fallback: post as general discussion without position
    await gitlab.postMergeRequestDiscussion(mrIid, body);
  }
}

This two-tier posting strategy means the review always gets posted, even if it can't be pinned to the exact line.

Gotcha #4: Parsing LLM Output is Fragile

Gemini's output is structured markdown, but LLMs don't always follow instructions perfectly. The finding regex needs to handle variations:

// Both formats appear in practice:
// **[CRITICAL]** `file.ts:42`    (with brackets)
// **CRITICAL** `file.ts:42`      (without brackets)
const findingRegex = /\*\*\[?(CRITICAL|HIGH|MEDIUM|LOW)\]?\*\*\s*`([^`]+)`/g;

The \[? and \]? make brackets optional. Without this, half the findings were silently dropped.

Another subtlety: the regex-based parser uses exec() in a loop, which maintains lastIndex state. When we peek ahead for the next match to determine where a finding block ends, we need to reset lastIndex afterward. Miss this, and findings get merged or skipped.

Gotcha #5: Shell Injection in CI Environments

The original code used execSync() to run git commands:

// DANGEROUS in CI where branch names come from user input
execSync(`git diff origin/${targetBranch}...HEAD`);

If someone creates a branch named main; rm -rf /, this becomes a shell injection. In CI, branch names are attacker-controlled input.

The fix: Switch to execFileSync() with argument arrays. This calls the binary directly without shell interpretation:

execFileSync('git', ['diff', '-U5', '--merge-base', `origin/${targetBranch}`]);

Similarly, the Gemini API key was originally passed as a URL query parameter. Moving it to the x-goog-api-key header prevents it from appearing in logs, proxy caches, and browser history.

Gotcha #6: Large Diffs and CLI Limits

An earlier version of Niteni tried passing diffs as CLI arguments to gemini -p "...". This hits the OS argument length limit (ARG_MAX) with large diffs. The workaround was writing to temp files with @filename syntax — but this added complexity with file cleanup, PID-based naming for parallel jobs, and error handling.

This was one of several reasons we moved to the REST API: HTTP request bodies have no practical size limit, and the diff is just a JSON string in the request payload. The API approach eliminated an entire class of problems.

Gotcha #7: ReDoS in Glob Pattern Matching

The diff filter converts glob patterns like *.min.js into regex. The naive approach:

// Original - vulnerable to ReDoS
pattern.replace(/[.*+?^${}()|[\]\\]/g, '\\$&').replace(/\\\*/g, '.*');

This escapes the * first, then tries to un-escape it. But it also escapes ., +, and other regex metacharacters that appear in filenames. The order of operations matters, escape everything except glob characters, then convert glob characters:

const escaped = pattern
  .replace(/[.+^${}()|[\]\\]/g, '\\$&')  // escape regex chars (NOT *)
  .replace(/\*/g, '.*')                    // convert glob * to regex .*
  .replace(/\?/g, '.');                    // convert glob ? to regex .

The difference is subtle but critical. The original version would double-escape patterns and produce incorrect matches.

Gotcha #8: URL Encoding Everything Twice (or Not at All)

GitLab project IDs can contain slashes when using namespaced paths like my-group/my-project. These need to be URL-encoded in API paths. But if you encode a numeric project ID like 12345, it stays the same. The code must handle both cases:

const encodedProjectId = encodeURIComponent(this.projectId);
const url = new URL(`${this.apiUrl}/projects/${encodedProjectId}${path}`);

Every path parameter, MR IID, note ID, discussion ID, file paths, branch refs, gets encodeURIComponent(). It's tedious but necessary. A branch named feature/auth without encoding becomes a path traversal.

Testing Without External Dependencies

The test suite uses Node's built-in node:test and node:assert modules. No Jest, no Mocha, no Vitest. This keeps the dependency tree at exactly two entries: typescript and @types/node.

import { describe, it } from 'node:test';
import * as assert from 'node:assert';

The simulation mode (niteni --mode simulate) uses hardcoded mock data that exercises the full parsing pipeline without making any API calls. It's both a demo tool and a manual integration test, you can see exactly what Niteni would post to GitLab.

What I'd Do Differently

Structured output from Gemini. Instead of parsing markdown with regex, I'd use Gemini's JSON mode or function calling to get structured findings. The regex parser works but is inherently fragile.
Rate limiting for large MRs. Posting 20+ inline comments in rapid succession can hit GitLab's API rate limits. A simple delay between requests would help.
Caching reviewed files. If a file hasn't changed between pipeline runs, there's no need to re-review it. A SHA-based cache would cut token usage significantly.
Better diff context. The current approach sends raw diffs. Sending surrounding context (the full file, or at least more lines around changes) would give Gemini better understanding of the code.

The Result

Niteni runs in about 30 seconds in CI, reviews diffs up to 100K characters, and posts findings with one-click suggestion buttons. It catches real bugs, SQL injections, missing auth middleware, hardcoded secrets, loose equality comparisons.

The zero-dependency approach paid off. Install is git clone && npm ci && npm run build. No native modules, no platform-specific binaries, no post-install scripts. It works on node:20-alpine with just git and bash added.

If you're interested in the code: github.com/denyherianto/niteni

Shipping a Portfolio That Actually Represents Me

Deny Herianto — Thu, 22 Jan 2026 02:37:20 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hi, I’m Danny, a frontend engineer who enjoys building products that sit at the intersection of clean UI, solid engineering, and real-world impact.

This portfolio is my attempt to reflect how I think and work today: pragmatic, curious, and focused on building things that actually ship. Rather than treating a portfolio as a static résumé, I wanted it to feel like a living system that shows how I approach problems, make decisions, and grow over time.

Portfolio

Live portfolio: https://denyherianto.com

Embedded live using Google Cloud Run:

How I Built It

I began by defining clear requirements for what the portfolio needed to achieve. Focusing on communication, not decoration. Once the constraints were clear, I used Gemini Chat to polish the idea itself: refining the structure, clarifying the narrative, and stress-testing how my work should be presented to different audiences.

After the concept was solid, I moved into design ideation using aura.build. This stage was about rapidly exploring layout options, visual hierarchy, and content flow. Aura made it easy to experiment, discard weak ideas early, and converge on a clean, readable design without over-committing.

With the design direction established, I used Google AI Studio during implementation to further refine content, project descriptions, and future-facing AI interactions.

The portfolio is deployed on Google Cloud Run, providing a simple, scalable production setup with minimal operational overhead. The entire workflow followed a deliberate loop: define → polish → design → build → ship, closely mirroring how I approach real-world product development.

What I'm Most Proud Of

I’m most proud that this portfolio allows visitors to understand how I think without needing a call or a chat.

Instead of relying on visuals or buzzwords, I focused on clear structure, direct explanations, and context behind each piece of work. Every section is designed to answer the kinds of questions that usually come up in interviews, how I approach problems, make decisions, and ship.

Thanks for checking it out, and thanks to the DEV and Google AI teams for running this challenge.

Peta GeoJSON & TopoJSON Indonesia (38 Provinsi)

Deny Herianto — Wed, 17 Dec 2025 15:34:16 +0000

Indonesia secara resmi kini memiliki 38 provinsi, dan jika Anda pernah mencoba membangun aplikasi berbasis peta, seperti dashboard, peta pemilu, alat logistik, pelacakan bencana, atau visualisasi data. Besar kemungkinan Anda pernah merasakan masalah berikut:

Data provinsi tidak lengkap
Batas wilayah yang sudah tidak relevan
Penamaan yang tidak konsisten

Mengapa Ini Penting

Peta bukan sekadar visual yang menarik. Peta adalah fondasi dari data Anda.

Jika daftar provinsi tidak akurat, maka seluruh sistem ikut bermasalah. Peta choropleth menjadi keliru. Analitik tidak sesuai dengan wilayah sebenarnya. Tooltip menampilkan nama yang salah.

Indonesia telah menambah beberapa provinsi baru, Papua Selatan, Papua Tengah, Papua Pegunungan, dan Papua Barat Daya. Sehingga banyak dataset lama kini sudah tidak relevan. Bahkan, banyak sumber publik masih hanya menampilkan 34 provinsi.

Cakupan

Data Lengkap

38 provinsi, termasuk:
- Papua Selatan
- Papua Tengah
- Papua Pegunungan
- Papua Barat Daya

Dua Tipe Format

GeoJSON
- Mudah digunakan
- Kompatibel dengan Leaflet, Mapbox GL, dan overlay Google Maps
TopoJSON
- Ukuran file ~80–90% lebih kecil
- Waktu muat lebih cepat
- Ideal untuk D3.js dan visualisasi skala besar

Bersih & Konsisten

Nama provinsi yang telah dinormalisasi
ID stabil untuk proses data join
Tidak ada geometri duplikat
Jalur (path) yang telah disederhanakan dan ramah web

GeoJSON vs TopoJSON (Ringkasan)

Fitur	GeoJSON	TopoJSON
Keterbacaan	✅ Tinggi	⚠️ Sedang
Ukuran File	❌ Besar	✅ Sangat Kecil
Performa Browser	⚠️ Bisa lambat	✅ Cepat
Paling Cocok Untuk	Peta sederhana	Visualisasi data, dashboard

Jika Anda membangun dashboard interaktif, TopoJSON adalah pilihan yang tepat.

Jika Anda butuh yang plug-and-play, GeoJSON sudah sangat memadai.

Contoh Kasus Penggunaan

Dataset ini ideal untuk:

📊 Dashboard pemerintahan & layanan publik
🌋 Pelacakan bencana & banjir
🗳️ Peta pemilu & demografi
🚚 Perencanaan logistik & cakupan layanan
📍 Produk SaaS berbasis lokasi
📱 Visualisasi data yang mobile-first

Contoh: Menggunakan GeoJSON dengan Leaflet

import L from "leaflet";
import indonesiaProvinces from "./indonesia-38-provinces.geojson";

L.geoJSON(indonesiaProvinces, {
  style: {
    color: "#1e40af",
    weight: 1,
    fillOpacity: 0.6,
  },
  onEachFeature: (feature, layer) => {
    layer.bindPopup(feature.properties.province);
  },
}).addTo(map);

Contoh: Menggunakan TopoJSON dengan D3.js

import * as d3 from "d3";
import { feature } from "topojson-client";

// Import file TopoJSON (mendukung Vite / Webpack / Next.js)
import topoData from "./indonesia-38-provinces.topo.json";

const width = 800;
const height = 600;

const svg = d3
  .select("#map")
  .append("svg")
  .attr("width", width)
  .attr("height", height);

const projection = d3
  .geoMercator()
  .fitSize([width, height], feature(topoData, topoData.objects.indonesia_provinces));

const path = d3.geoPath().projection(projection);

// Konversi TopoJSON → GeoJSON
const provinces = feature(
  topoData,
  topoData.objects.indonesia_provinces
);

svg
  .selectAll("path")
  .data(provinces.features)
  .enter()
  .append("path")
  .attr("d", path)
  .attr("fill", "#60a5fa")
  .attr("stroke", "#1e3a8a")
  .append("title")
  .text(d => d.properties.province);

Unduh

Unduh dataset melalui repositori berikut:

https://github.com/denyherianto/indonesia-geojson-topojson-maps-with-38-provinces

GeoJSON & TopoJSON Maps of Indonesia (38 Provinces)

Deny Herianto — Wed, 17 Dec 2025 15:05:27 +0000

Indonesia officially has 38 provinces, and if you’ve ever tried to build a map-based app or dashboards, election maps, logistics tools, disaster tracking, or data visualizations. You’ve probably felt the pains:

Incomplete province data
Outdated boundaries
Inconsistent naming

Why You Should Care

Maps aren’t just pretty pictures. They’re the backbone of your data.

If your province list is off, you’re in trouble. Choropleth maps end up wrong. Analytics don’t match real regions. Tooltips show the wrong names.

Indonesia’s added new provinces, Papua Selatan, Papua Tengah, Papua Pegunungan, Papua Barat Daya. So older datasets are now out of date. A lot of public sources still only show 34 provinces.

What’s Included

Complete Coverage

38 provinces, including:
- Papua Selatan
- Papua Tengah
- Papua Pegunungan
- Papua Barat Daya

Two Formats

GeoJSON
- Easy to use
- Compatible with Leaflet, Mapbox GL, Google Maps overlays
TopoJSON
- ~80–90% smaller file size
- Faster loading
- Ideal for D3.js and large-scale visualizations

Clean & Consistent

Normalized province names
Stable IDs for data joins
No duplicated geometries
Simplified paths (web-friendly)

GeoJSON vs TopoJSON (Quick Recap)

Feature	GeoJSON	TopoJSON
Readability	✅ High	⚠️ Medium
File Size	❌ Large	✅ Very Small
Browser Performance	⚠️ Can lag	✅ Fast
Best For	Simple maps	Data viz, dashboards

If you’re building interactive dashboards, TopoJSON is your friend.

If you want plug-and-play simplicity, GeoJSON works great.

Common Use Cases

This dataset is ideal for:

📊 Government & civic dashboards
🌋 Disaster & flood tracking
🗳️ Election & demographic maps
🚚 Logistics & coverage planning
📍 Location-based SaaS products
📱 Mobile-first data visualizations

Example: Using GeoJSON with Leaflet

import L from "leaflet";
import indonesiaProvinces from "./indonesia-38-provinces.geojson";

L.geoJSON(indonesiaProvinces, {
  style: {
    color: "#1e40af",
    weight: 1,
    fillOpacity: 0.6,
  },
  onEachFeature: (feature, layer) => {
    layer.bindPopup(feature.properties.province);
  },
}).addTo(map);

Example: Using TopoJSON with D3

import * as d3 from "d3";
import { feature } from "topojson-client";

// Import TopoJSON file (Vite / Webpack / Next.js supported)
import topoData from "./indonesia-38-provinces.topo.json";

const width = 800;
const height = 600;

const svg = d3
  .select("#map")
  .append("svg")
  .attr("width", width)
  .attr("height", height);

const projection = d3
  .geoMercator()
  .fitSize([width, height], feature(topoData, topoData.objects.indonesia_provinces));

const path = d3.geoPath().projection(projection);

// Convert TopoJSON → GeoJSON
const provinces = feature(
  topoData,
  topoData.objects.indonesia_provinces
);

svg
  .selectAll("path")
  .data(provinces.features)
  .enter()
  .append("path")
  .attr("d", path)
  .attr("fill", "#60a5fa")
  .attr("stroke", "#1e3a8a")
  .append("title")
  .text(d => d.properties.province);

Download

You can download the datasets directly from the repository:

https://github.com/denyherianto/indonesia-geojson-topojson-maps-with-38-provinces

Simplifying Figma MCP Server: How to Start in Minutes

Deny Herianto — Mon, 03 Nov 2025 15:19:53 +0000

Overview

Unlock efficient design-to-code workflows by connecting Figma to Cursor using the Model Context Protocol (MCP) server. This guide covers both the official Figma Dev Mode MPC server and community alternatives, offering actionable steps, troubleshooting, and best practices.

What is MCP and Why Use It?

MCP (Model Context Protocol) lets tools like Cursor read and translate Figma design context directly, speeding up token extraction and React/Tailwind code generation. Developers can automate UI component mapping and asset extraction, improving accuracy and workflow efficiency.

Why this matters

If you’ve ever felt the gap between designer’s Figma file and developer’s codebase, you’re not alone. The MCP (Model Context Protocol) Server in Figma brings more than just a screenshot. It brings actual design context into your development tools so you generate code that truly matches your design system, not just in look, but in structure too.

What is the Figma MCP Server?

In simple terms: it’s a bridge between your Figma designs and your development environment.

It surfaces variables, components, layouts, style tokens and more from Figma into your IDE, so AI-assisted tools (or manual workflows) know exactly what you meant when you sketched that button or card.
Instead of feeding an image or a PDF, you’re giving your tools data—and data = better accuracy, fewer mis-aligned features, less “why does this look different in code” drama.
Ideal if you have a design system, or want one, and you want to reduce friction between designers and developers.

A) Official way (recommended): Figma Dev Mode MCP → Cursor

Prerequisites:

Figma Desktop app (latest) with a Dev or Full seat on Professional/Organization/Enterprise. (Guide to the Figma MCP server)
Cursor (latest) with MCP enabled. (Model Context Protocol (MCP) | Cursor Docs)

Steps:

Turn on the MCP server in Figma Desktop
a. Open Figma Desktop → Menu → Preferences → Enable Dev Mode MCP Server.
b. You’ll see it’s running locally at: http://127.0.0.1:3845/mcp. Keep that URL.
Add the server in Cursor
Cursor → Settings → Cursor Settings → MCP → + Add new global MCP server, then use this config:

   {
     "mcpServers": {
       "Figma": {
         "url": "http://127.0.0.1:3845/mcp"
       }
     }
   }

Verify it worked

Open Cursor chat (Agent/Composer). Type #get_code to see Figma tools (e.g., get_code, get_variable_defs, optionally get_image). If nothing shows, restart both Figma Desktop and Cursor.

Use it (two easy flows)

Selection-based: select a frame/layer in Figma, then prompt Cursor to generate code for your selection.
Link-based: copy a Figma frame/layer link, paste it in chat, and ask for code/tokens.

Available tools include:

get_code → produces React+Tailwind by default (you can ask for Next.js/Vue/etc.).
get_variable_defs → lists variables/styles used (great for tokens).
Enable Preferences → Dev Mode MCP Server Settings → get_image to include screenshots for layout fidelity; also enable Code Connect to map Figma nodes to your components.

Troubleshooting quick hits

Must be Figma Desktop (server runs locally over SSE). Check the URL/port http://localhost:3845/mcp.
In Cursor, you can view MCP Logs (Output panel → “MCP Logs”) to see connection errors/timeouts.

B) Alternative: Community Figma MCP server (stdio / token-based)

If you want a standalone MCP server that talks to Figma’s REST API (handy for headless/remote setups or deeper API methods), you can run one locally and point Cursor at it.

Pick a server
Example:
GitHub - GLips/Figma-Context-MCP: MCP server to provide Figma layout information to AI coding agents like Cursor
Get a Figma Personal Access Token (PAT)
Figma → Settings → Security → Personal access tokens → Generate new token (copy it once).
Add the Framelink Figma MCP server to your IDE

{
  "mcpServers": {
    "Framelink Figma MCP": {
      "command": "npx",
      "args": [
        "-y",
        "figma-developer-mcp",
        "--figma-api-key=YOUR-KEY",
        "--stdio"
      ]
    }
  }
}

How to Use:

Option 1: Select a Frame, Then Chat in Cursor

Open the Design
a. In Figma Desktop, open your file.
b. Click the frame or section you want (e.g. Hero, Pricing Page, Dashboard).
Generate Tokens (recommended)
In Cursor chat, type: #get_variable_defs
- Cursor shows colors, fonts, spacing used in your selection.
- Save these into tokens.ts or tailwind.config.ts.
Generate Code
a. In Cursor chat, type: #get_code
b. Then add a prompt like: Generate a Next.js page with React + Tailwind from my current selection. Use components from @/components/ui. Map all values to tokens, no hardcoded hex or px.
c. Cursor will create page.tsx (and child components if needed).
Refine
a. If output uses plain , ask Cursor: Replace raw buttons with my <Button /> component.
b. Keep iterating until it matches your system.

Option 2: Copy & Paste a Figma Link

Get the Link
In Figma, right-click the frame → Copy/Paste → Copy link.
Paste into Cursor
In Cursor chat, paste the link. Example: https://www.figma.com/file/xxxxxx?node-id=123-456
Ask for Code
After the link, add a prompt: Turn this Figma frame into a responsive Next.js page using React + Tailwind. Use my components in @/components/ui. Map to tokens from get_variable_defs.
Export Assets (if needed)
Ask Cursor: Export images/vectors from this frame into public/assets/... and update imports.

Which option to Use?

Frame selection → Best when you already have Figma open. The MCP server passes selection data directly.
Copy link → Best when someone shares a link in Slack/Docs. Cursor fetches design data for that node.

Mastering Role-Based Access Control in Your Javascript CMS

Deny Herianto — Mon, 03 Nov 2025 14:35:43 +0000

Implementing Role-Based Access Control (RBAC) in a CMS Frontend

Role-Based Access Control (RBAC) is a critical part of building secure, maintainable, and scalable content management systems (CMS). This article explores the strategies, pitfalls, and best practices for implementing RBAC, particularly in React and Next.js environments, with a focus on configuration, code structure, and practical application.

Why RBAC Matters in CMS

A CMS empowers experts to manage digital content without deep technical knowledge, saving organizations significant time and resources. However, with convenience comes the need for strict security and efficient workflows. RBAC ensures that only authorized users access sensitive data and critical site features, helping maintain integrity and compliance.

Roles

Roles are a critical part of ensuring the safety of the data stored in a CMS, creating efficient workflows, building independent teams. Each role has specific permissions that the user is allowed to perform and view in the CMS.

When it comes to roles, I recommend great flexibility, i.e. the ability to create and define user accounts and groups freely (roles like "contributor", "manager" etc. are not hard-coded, but put into a configuration file that can be changed per application). The role configuration is unaccessible to the user, but the engine itself should be free from hard-coded roles.

Key Approaches to Access Control

Action-Based Access Control: Grants permissions based on specific actions (e.g., create, read, update, delete) that users can perform.
Role-Based Access Control: Grants permissions based on user roles (such as Contributor, Manager, or Admin), which group together sets of privileges.

While each method has merit, a combined approach often yields the most maintainable and secure system in modern CMS implementations.

Common Role Definitions

A typical CMS will include roles such as:

Super Admin: Full access, including user and site management.
Admin: Manage content and users, but may not access system settings.
Manager: Schedule and supervise content but with limited system access.
Contributor: Create and edit content within set boundaries.
Author: Submit content, sometimes with limited publishing rights.

RBAC vs ACL flow

Roles Checker - per Page

Roles Checker - per Action

Access Level

Below are my approach options regarding access level definitions. We can combine the definitions of the 2 approaches. Roles will be defined on BE and Action Permissions will be defined on FE.

Examples below:

Action-based approach

Based on Common CMS roles and access levels:

Role-based Approach

Based on What names for standard website user roles?:

Problems and Challenges

Implementing RBAC can introduce issues if not planned carefully:

Roles and permissions hard-coded in the app are hard to maintain.
Exposing role configuration to end-users creates security risks.
Ensuring consistent access checks, especially with server-side rendering (SSR), is non-trivial.
Permissions must adapt to evolving business needs without complete rewrites.

Designing Flexible Permissions Configs

A robust solution avoids hard-coded roles by storing them in configuration files (e.g., configs/roles/index.ts). This enables:

Adjusting roles and permissions independently of the CMS core.
Abstracting role definitions away from UI components.
Easy scaling as new roles or features emerge.

Example configuration for roles and permissions:

// configs/roles/index.ts
export const ROLES = {
  SUPER_ADMIN: 'super.admin',
  ADMIN: 'admin',
  MANAGER: 'manager',
  CONTRIBUTOR: 'contributor',
};

// configs/policies/users.ts
export const permissions = {
  '/users': {
    roles: [ROLES.SUPER_ADMIN, ROLES.ADMIN, ROLES.MANAGER],
    actions: {
      create: [ROLES.ADMIN],
      delete: [ROLES.SUPER_ADMIN],
    },
  },
};

Implementation Strategies in React/Next.js

Using Higher-Order Components (HOC)

Higher-Order Components wrap pages or components to enforce authentication and permission checks, enabling server-side rendering (SSR) where required.

<root>/utils/lib/withPermission.tsx

import { useCallback } from 'react'
import NextApp from 'next/app'
import { useUserStore } from 'stores/user'

const withPermission = (App: NextApp | any) => {
  return (props) => {
    const { user } = useUserStore((state) => ({
      user: state.user,
    }))

    const hasAccess = useCallback(
      (name, permissions) => {
        if (permissions?.[name]?.['*']) {
          return permissions[name]['*'].some((role) =>
            user?.roles?.includes(role)
          )
        }

        return true
      },
      [user]
    )
    const { name, permissions } = App?.auth
    const allowed = permissions.length && hasAccess(name, permissions)
    return <>{allowed ? <App {...props} /> : <div>Permission Denied...</div>}</>
  }
}

export default withPermission

<root>/pages/manage-users/index.tsx

import React from 'react'
import Head from 'next/head'
import Layout from 'components/Layout'
import { permissions, roles } from 'configs/policies'
import withPermission from 'utils/lib/withPermission'

export const App = () => {
  return (
    <>
      <Head>
        <title>CMS - Manage Users</title>
      </Head>

      <Layout>Manage Users</Layout>
    </>
  )
}

App.auth = {
  name: 'MANAGE_USERS',
  permissions,
  roles,
}

export default withPermission(App)

Pros

Cons

Can only check per page, not per action
Need to define per page
Cannot check auth & session first before checking roles

Using Component Wrapper

<root>/components/AccessControl/index.tsx

import { usePermission } from 'utils/hooks/usePermission'

const AccessControl = ({ allowedPermissions, children, renderNoAccess }) => {
  const { checkPermissions } = usePermission()

  const permitted = checkPermissions(allowedPermissions)

  if (permitted) {
    return children
  }
  return renderNoAccess()
}

AccessControl.defaultProps = {
  allowedPermissions: [],
  renderNoAccess: () => null,
}

export default AccessControl

<root>/pages/manage-users/index.tsx

import React from 'react'
import Head from 'next/head'
import Layout from 'components/Layout'
import { permissions } from 'configs/policies'
import AccessControl from 'components/AccessControl'

export const App = ({ allowedPermissions }) => {
  return (
    <>
      <Head>
        <title>CMS - Manage Users</title>
      </Head>

      <Layout>
        <AccessControl
          allowedPermissions={
            allowedPermissions['*'] || allowedPermissions['read']
          }
          renderNoAccess={() => <div>No access</div>}
        >
          <div>
            <div id="title">Manage Users</div>
            <AccessControl
              allowedPermissions={allowedPermissions['create']}
              renderNoAccess={() => null}
            >
              <div id="write">Write</div>
            </AccessControl>
            <AccessControl
              allowedPermissions={allowedPermissions['delete']}
              renderNoAccess={() => null}
            >
              <div id="write">Delete</div>
            </AccessControl>
          </div>
        </AccessControl>
      </Layout>
    </>
  )
}

const PAGE_NAME = 'MANAGE_USERS'

App.auth = {
  name: PAGE_NAME,
  permissions,
}

App.getInitialProps = () => {
  return { allowedPermissions: permissions[PAGE_NAME] }
}

export default App

<root>/utils/hooks/usePermission.ts

import { useCallback } from 'react'
import { useUserStore } from 'stores/user'

export function usePermission() {
  const { user } = useUserStore((state) => ({
    user: state.user,
  }))

  const checkPermissions = useCallback(
    (permissions) => {
      if (permissions.length === 0) {
        return true
      }

      if (permissions) {
        return user?.roles?.some((permission) =>
          permissions?.includes(permission)
        )
      }
    },
    [user]
  )

  return {
    checkPermissions,
  }
}

Pros

Can check per page & per action

Cons

Need to define in each page

Using Hooks

Custom hooks like usePermission() allow components to check user permissions dynamically and render views accordingly.

<root>/utils/hooks/useAuth.tsx

import { usePermission } from 'utils/hooks/usePermission'

...

export function AuthGuard(props) {
  const router = useRouter()

  const { children, name, permissions } = props
  const { hasNextAuthSession, hasUser } = useAuthGuard()
  const { checkPermissions } = usePermission()

  const defaultPermissions = [
    ...new Set([
      ...(permissions[name]?.['*'] ?? []),
      ...(permissions[name]?.['read'] ?? []),
    ]),
  ]
  const permitted = checkPermissions(defaultPermissions)

  if (hasNextAuthSession && hasUser) {
    if (permitted) {
      return children
    }

    router.push('/permission-denied')
  }

  return (
    <>
      <LoadingState>Memuat...</LoadingState>
    </>
  )
}

Pros

No need to define per page

Cons

Can only check per page, not per action

Example: AccessControl Component

import { useRouter } from 'next/router'
import type { ReactElement } from 'react'
import React from 'react'

import { usePermission } from 'utils/hooks/usePermission'

export type AccessControlProps = {
  actions?: string[]
  allowedPermissions?: string[]
  children: ReactElement
  noAccessMessage?: string
  redirectUrl?: string
}

const AccessControl = ({
  actions,
  allowedPermissions,
  children,
  noAccessMessage,
  redirectUrl,
}: AccessControlProps) => {
  const { checkPermissions, currentPathPermissions } = usePermission()
  const [permitted, setPermitted] = React.useState(true)
  const router = useRouter()

  React.useEffect(() => {
    const isPermitted = checkPermissions(
      allowedPermissions.length
        ? allowedPermissions
        : currentPathPermissions(actions)
    )
    setPermitted(isPermitted)

    if (!isPermitted) {
      if (noAccessMessage) console.log({ message: noAccessMessage })
      if (redirectUrl) router.replace(redirectUrl)
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [])

  if (permitted) {
    return children
  }

  return null
}

AccessControl.defaultProps = {
  allowedPermissions: [],
}

export default AccessControl

Usage

<AccessControl allowedPermissions={['read']}>
  <Content />
</AccessControl>
<AccessControl allowedPermissions={['create']}>
  <CreateButton />
</AccessControl>

Guide: Adding RBAC to CMS Features

Add Role Groups: Ensure relevant groups are defined in /configs/roles/index.ts.
Configure Permission Policies: Configure page or feature-level permissions in /configs/policies/index.ts or similar.
Use Access Control in Components: Integrate HOCs or hooks to check for permissions within your components.

References and Useful Links

By following these practices, you ensure your CMS remains secure, flexible, and easy to maintain as requirements evolve.

Forem: Deny Herianto

Building an AI Code Reviewer for GitLab CI with Google Gemini

What I Built with Google Gemini

How Gemini fits in

Demo

What I Learned

1. Gemini CLI ≠ CI-friendly

2. Structured output beats regex parsing

3. GitLab CI variable "pass-through" is a trap

4. execFileSync over execSync for security

5. URL-encoding every path parameter

Google Gemini Feedback

Building Disaster Pulse: What Happened When I Let AI Decide If a Disaster Is Real

What I Built with Google Gemini

Demo

What I Learned

Multi-agent architecture is harder than it looks

Multimodal processing isn't free

The empty state kills demos

The hardest part wasn't the AI, it was making the AI visible

One moment that stuck

Google Gemini Feedback

What worked really well

Where I hit friction

Why Your IndexedDB Data Keeps Disappearing

The Short Version

Root Cause #1: Chrome Will Evict Your Entire Database

How we hit this

The fix

How to protect your extension from eviction

Root Cause #2: Service Worker Restarts Can Abort In-Flight Writes

How this works in practice

The fix

Root Cause #3: "Clear Then Import" Leaves You With Nothing on Failure

The fix

Summary

The Bigger Lesson

Built an open-source AI code review bot for GitLab using Gemini. Zero runtime dependencies, inline diff comments, and one-click suggestion buttons. Here's every gotcha I hit along the way!

Building Niteni: Gemini Code Review Bot for GitLab with Zero Dependencies

Deny Herianto ・ Feb 15

Building "Niteni": Gemini Code Review Bot for GitLab with Zero Dependencies

The Idea

Architecture: Direct API Call

Gotcha #1: GitLab CI Variable Circular References

Gotcha #2: Token Authentication is a Maze

Gotcha #3: Inline Diff Comments Need diff_refs

Gotcha #4: Parsing LLM Output is Fragile

Gotcha #5: Shell Injection in CI Environments

Gotcha #6: Large Diffs and CLI Limits

Gotcha #7: ReDoS in Glob Pattern Matching

Gotcha #8: URL Encoding Everything Twice (or Not at All)

Testing Without External Dependencies

What I'd Do Differently

The Result

Shipping a Portfolio That Actually Represents Me

About Me

Portfolio

How I Built It

What I'm Most Proud Of

Peta GeoJSON & TopoJSON Indonesia (38 Provinsi)

Mengapa Ini Penting

Cakupan

Data Lengkap

Dua Tipe Format

Bersih & Konsisten

GeoJSON vs TopoJSON (Ringkasan)

Contoh Kasus Penggunaan

Contoh: Menggunakan GeoJSON dengan Leaflet

Contoh: Menggunakan TopoJSON dengan D3.js

Unduh

GeoJSON & TopoJSON Maps of Indonesia (38 Provinces)

Why You Should Care

What’s Included

Complete Coverage

Two Formats

Clean & Consistent

GeoJSON vs TopoJSON (Quick Recap)

Common Use Cases

Example: Using GeoJSON with Leaflet

Example: Using TopoJSON with D3

4. `execFileSync` over `execSync` for security

Gotcha #3: Inline Diff Comments Need `diff_refs`