DEV Community: Graita Sukma Febriansyah Triwildan Azmi

So many types of social engineering hacks, targeting web3 developers 💀

Graita Sukma Febriansyah Triwildan Azmi — Fri, 27 Feb 2026 16:47:30 +0000

Picture this.
You’re chilling, shipping features, maybe fixing a random “gas estimation failed” bug for the 4th time this day.

Then a DM lands:

“Hey, we’re doing an NFT project and need someone like you to help us.”
“Loved your GitHub profile. I see a lot of contribution you made. Do you want to contribute in our project?”
“Your repo is vulnerable. Here’s a PR to fix it.”

And because you’re a builder, you do the builder thing:

You clone, run, click, and merge.

Congratulations, you just got socially engineered.

Alright, shall we begin :)

Why Web3 devs get targeted so hard

Short answer: because you don’t just have the code, you have the access!

Something like:

deployer keys (or the machine that touches them)
CI secrets (that can publish packages, push image)
priviledged social media like Discord/Telegram that can “announce”
and so on

They can just break your workflow.

In Web3, the fastest way to drain funds is not a re-entrancy bug. It’s a developer having a normal day.

The menu of attacks (Web3 dev edition)

Below are the patterns I keep seeing — different flavors, same core trick: get you to execute or approve something you normally wouldn’t.

1) Fake recruiter → “coding assignment” malware

This one is disgustingly effective because it weaponizes your ambition.

Flow:

Recruiter reaches out (LinkedIn, Telegram, X, email)
You get a “take-home task”
Task includes repo / zip / “run this script”
You run it locally
Your machine leaks secrets / tokens / wallet material / browser data

Security teams have been tracking multiple waves of this style of campaign, including variants attributed to DPRK-linked activity. ReversingLabs described a “fake recruiter” branch targeting JS/Python developers with crypto-themed tasks (active since May 2025).

Google’s threat intel also described DPRK activity abusing the job interview process as the delivery mechanism.

Builder trap: “It’s just code, I can inspect it.”

Yeah… and you still ran it.

2) Fake audit / fake security firm / “critical vuln” panic

This one targets your responsibility reflex.

Common lures:

“We found a critical issue in your protocol”
“We’re a security partner of , please validate this quickly”
“Here’s a PoC / Foundry test / script to reproduce”

The payload is often the same: get you to run something (or open a doc) on a machine that has access to important things.

This vibe rhymes with how the Ronin/Axie compromise was reported: the initial hook wasn’t a smart contract exploit, it was a human being convinced to open something in a trusted context.

Builder trap: “If I ignore this and it’s real, I’m negligent.”

Attackers love that sentence.

3) Malicious npm/PyPI packages hiding inside “normal” dev work

If you’re a Web3 dev, you probably install random packages weekly:

wallet utils
crypto helpers
ABI tooling
build plugins
“quick scripts”

Attackers know this.

Recent reporting and research has highlighted campaigns planting malicious packages and abusing open-source trust — including fake recruiter flows that lead devs to install specific packages.

Builder trap: “It’s open source, and it has 200 stars.”

Stars are not a security model.

4) GitHub-native attacks: PRs, Actions, token theft, CI secret exfil

This is the grown-up version of phishing.

Instead of attacking you, they attack the system you rely on:

a PR that looks legit but sneaks in a postinstall / script
a compromised maintainer account
a malicious GitHub Action update
dependency bumps that pull in the payload

And because CI has secrets, CI is a jackpot.

There have been large-scale supply-chain incidents reported in the npm/GitHub ecosystem where malware focuses on stealing developer secrets and CI/CD credentials.

Builder trap: “CI ran green, so it’s safe.”

CI can be the victim too.

5) Discord/Telegram “verification” bots and community impersonation

Web3 teams live in chat apps. Attackers live there too.

Patterns:

fake “Collab Manager” accounts
cloned communities
fake “verify to enter” bots
fake airdrop/trading groups delivering malware

Some threat reports have noted malware distribution and scam flows increasingly happening through Telegram-style channels and “verification” mechanics rather than classic email phishing.

Builder trap: “It’s in the official group.”

Ask: official according to who?

6) Wallet drainers & signature tricks (devs are not immune)

Even if you “never share seed phrases,” you can still get wrecked by:

signing a malicious message
approving an unlimited allowance on a compromised dApp
signing something you didn’t simulate / understand

Drainer operations are basically a service economy now (tooling, panels, distribution playbooks).

Builder trap: “It’s just a signature, not a transaction.”

Sometimes the signature is the whole attack.

7) “Decentralized hosting” payloads (harder to takedown)

Some campaigns are experimenting with hiding malicious payload delivery in places that are annoying to block, including techniques that leverage public blockchains as part of infrastructure.

Google described DPRK-linked activity using EtherHiding to support malware delivery in a way that complicates blocking/takedown.

Builder trap: “We blocked the domain.”

Cool. The payload isn’t on a normal domain anymore.

The common mechanic: they’re not stealing your keys — they’re stealing your decisions

If you strip the details, most of these attacks are just three moves:

Establish legitimacy (brand, identity, context)
Apply urgency (“now”, “ASAP”, “critical”)
Trigger an action (run, install, merge, sign)

So the defense is not only “better antivirus.”

It’s better decision gates.

A simple decision rule (use this daily)

When someone asks you to do something “urgent,” ask three questions:

Identity: can I verify who you are out of band?
Action: what exact action do you want me to take?
Blast radius: what’s the worst-case if this is malicious?

If the blast radius includes:

“leak secrets”
“publish code”
“sign something”
“deploy something”

…then you don’t do it in a DM window. You move it into a controlled process.

Closing: attackers ship too

Social engineering attacks targeting Web3 developers are getting “better” for the same reason Web3 products get better:

people iterate. they learn. they optimize funnels.

So don’t just harden your contracts.

Harden your habits.

Because in 2026, the easiest exploit is still:

A developer, a deadline, and one “quick task.”

Thank you for reading this article, hope it’s helpful 📖. See you in the next article 🙌.

From Monolith to Services Without Regret: The Boring Migration Plan

Graita Sukma Febriansyah Triwildan Azmi — Thu, 12 Feb 2026 14:55:52 +0000

The first time I tried to “go microservices”, I did it for the most honest reason developers ever do anything:

Because it sounded like the grown-up move

Our monolith was getting bigger, deploys were slower, codebase more sticky, and a couple of endpoints were hot and fcking slow. One incident turned into a full-team debugging party. And somewhere in my head, “I think microservices were the obvious answer” like upgrading from a single server to real distributed services.

So I did what everyone does when they’re tired and ambitious, “started splitting things”.

New repo, new service name, new pipeline, new database, and new clean boundary. For a few days, it felt amazing (like I had finally escaped :D).

Then reality showed up and punched us hard:

local dev got harder to set up
debugging became distributed archeology
staging became “work in service A but not in service B”
tracing didn’t exist yet, so everything was “maybe network issue?”
deployment multiplied
auth became a mess
versioning becae a new job
and much moreeeee

The monolith wasn’t gone, it just moved into the network. That’s when I learned the unpopular truth.

microservices don't remove complexity, they relocate it

And if you migrate because you’re “annoyed”, you’ll regret it.

So I rewound. Not to abandon services forever, but to adopt a migration plan that doesn’t destroy your ability to ship. A plan so boring it actually works.

The problem was never the monolith

It was the lack of boundaries inside it. Most monolith pain comes from two things:

everything can touch everything
changes are not isolated

So the goal isn’t “split into services”. The goal is make boundaries and only then decide what deserves to become a service. If you can’t draw boundaries in a monolith, you won’t magically draw them across repos.

The boring plan: 6 steps that avoid regret

1. Make the monolith modular first (a modular monolith)

Before I extracted anything, I forced structure:

separate modules by domain (not by folder vibes)
enforce boundaries (imports, layering rules)
stop sharing random utilities everywhere
define what data each module owns

This sounds like a refactor that pays rent.

2. Pick the first services based on pain and isolation

Most teams pick services based on what’s “important”. I picked based on what’s isolatable.

Good first candidates usually have:

clear inputs/outputs
fewer dependencies
less shared data
high traffic or distinct scaling needs
a team that can own it

Bad first candidates:

“core domain logic” touching everything
workflows that span the entire product
anything that requires shared transactions across many tables

My first extraction attempt failed because I picked a “central” domain.

3) Use the Strangler pattern: route traffic gradually

Instead of cutting over in one dramatic weekend, I did this:

keep monolith endpoint as the “front door”
route a small percent of traffic to the new service
ramp up gradually
keep a kill switch to fall back to monolith fast

This changed the migration from “big bang” to “progressive rollout.”

Why it matters:

You’re not migrating code. You’re migrating risk.

4) Freeze the old behavior with contract tests

The easiest way to break things is to rewrite logic with confidence.

So I wrote contract tests around the monolith behavior:

request/response shapes
edge cases
error codes
expected side effects

Then I ran the same tests against the new service.

This prevented the classic migration bug:

“We improved it… and now it behaves differently.”

5) Split data the boring way: keep DB shared at first (sometimes)

This part is controversial, but it saved my migration.

Instead of going “separate database per service” on day one, I staged it:

Phase 1: service has its own code + deploy + scaling, but reads from the existing DB (carefully).

Phase 2: introduce a dedicated schema or tables with clear ownership.

Phase 3: move to a separate database only when you have events/replication/ownership clear.

This avoided building a full distributed data architecture prematurely.

Because the moment you separate DBs, you inherit:

eventual consistency
dual writes
eventing
reconciliation
backfills
debugging async flows

A service boundary is already a big change.

A data boundary is the real point of no return.

6) Build the boring platform stuff earlier than you want

Microservices only feel “clean” when your platform is mature.

So I had to invest in:

centralized logging
tracing (or at least correlation IDs)
consistent authN/authZ strategy
shared observability dashboards
deployment automation
versioning rules between services

Otherwise your migration becomes:

“We moved to microservices and now we can’t debug anything.”

The “services without regret” decision rule

After the boring plan, I changed my criteria.

A module should become a service only if it needs at least one of these:

independent scaling (traffic/compute profile differs)
fault isolation (it fails and shouldn’t take everything down)
team ownership boundaries (real org scaling)
security boundaries (sensitive workloads)

If the reason is “the monolith feels messy,” the fix is not services.

The fix is boundaries, standards, and refactoring.

The best outcome wasn’t “microservices”

It was boring deployments

When the plan worked, something surprising happened:

We didn’t feel like we “migrated to microservices.”

We just slowly stopped suffering.

deploys got smaller
incidents got narrower
teams gained ownership
scaling became targeted
the codebase became less scary

That’s the goal.

Thank you for reading this article, hope it’s helpful 📖. See you in the next article 🙌

Definition of Done Is a Lie (Unless It Includes These 5 Things)

Graita Sukma Febriansyah Triwildan Azmi — Thu, 12 Feb 2026 03:16:25 +0000

I used to think “done” meant: PR merged, CI green, deployed to staging. That’s it. Ship the feature, move on, next ticket.

Then I shipped a feature that was done… and immediately turned into a slow-burn production mess.

Not because the code was “bad” (okay, a bit maybe), but because the definition was bad.

No dashboard. No kill switch. No clear rollback. No runbook. No clue what was happening when users reported “it’s broken” except a vague spike in errors and a Slack thread that started with:

“Anyone knows what changed?”

That’s when I realized something brutal:

Most Definitions of Done are just “we stopped working on it.”

Not “it’s safe.” Not “it’s operable.” Not “it’s maintainable.”

So here’s what I changed. These are the 5 things that finally made “done” mean what it sounds like:

shipped, safe, and survivable.

The problem was never speed

It was fragility disguised as velocity

A weak DoD feels productive because it optimizes for one visible milestone: merge.

But the cost doesn’t disappear. It’s just deferred into:

on-call chaos
hotfix releases
“why is this slow?” investigations
support tickets you can’t reproduce
teammates afraid to touch the code

It’s like building a bridge and calling it “done” because the concrete dried—without checking if trucks can cross it.

So I reframed DoD into one sentence:

A feature is done when it can survive production without its author babysitting it.

1) Done means Observable

If it breaks, can I know what broke in under 5 minutes?

When a user says “it’s not working,” the worst response is “I can’t see anything.”

That’s not a monitoring issue. That’s a definition issue.

So now, “done” includes:

structured logs (not vibes)
request IDs / correlation IDs
key metrics: success rate, error rate, latency (p50/p95)
a simple dashboard that answers: is it healthy?
alerts only when the feature is truly critical

The shift:

I stopped treating observability as “nice to have later.”

I treat it as part of the feature—like the UI or database schema.

Because shipping without telemetry is like deploying without SSH access.

2) Done means Reversible

Can I disable it instantly without redeploying and praying?

This is the “I learned it the hard way” one.

At some point, every feature will misbehave:

edge case you didn’t predict
downstream service failing
traffic spike
data inconsistency
unexpected user behavior

3) Done means Safe by Default

If someone tries to misuse it, does it fail safely?

Many incidents aren’t “bugs.” They’re missing guardrails.

So “done” includes:

proper authorization (not just authentication)
validation for user inputs (especially file uploads)
rate limiting / abuse controls if the endpoint is “fun”
secure defaults (deny > allow)
secrets not logged, not leaked, not shipped to clients

This one matters because production isn’t just for users.

Production is also:

bots (AI crawls, those shit)
weird clients
accidental spam
malicious traffic

Done means it survives real users and real attackers.

4) Done means Correct Under Real Conditions

Not “works on my machine.” Works in the world.

Staging is polite. Production is chaos.

Production has:

concurrency
retries
timeouts
partial failures
unexpected payload sizes
real traffic patterns
real data inconsistencies

So “done” includes:

negative tests + edge case tests
idempotency where duplicates can happen (payments, messaging, webhook handlers)
bounded retries + timeouts (no infinite retry loops)
defined behavior when dependencies fail (fallbacks, graceful degradation)
load assumptions written somewhere (“expected max payload, expected latency”)

The shift:

I stopped thinking testing is about correctness.

Testing is about survivability under pressure.

5) Done means Explainable to the Next Person

If I disappear for a week, can someone operate it without summoning me?

This is the part devs underestimate because it doesn’t feel technical.

But it’s the difference between a team that ships and a team that waits.

So “done” includes:

a short runbook: how to debug, where to look, common failures
updated API docs/contracts
“how to test locally” steps (even minimal)
clear ownership: who maintains this, which service, which repo
release notes (short) if user behavior changes

What a “real” Definition of Done looks like

Here’s the compact version I wish I had earlier:

A feature is “done” when it is:

Observable (logs/metrics/traces + dashboard)
Reversible (feature flag + rollback plan)
Safe (authZ + validation + rate limiting if needed)
Correct in production reality (idempotency + timeouts + failure handling)
Explainable (runbook + docs + ownership)

The merged code is not done.

It’s just… merged.

The pushback: “This slows us down”

Yeah. It slows down this PR.

But it speeds up the next 20 releases.

Because the alternative is paying the same cost later, but with interest:

production incidents
emergency fixes
broken trust
morale drain
tech debt that turns into fear

DoD is not a bureaucracy.

It’s how you buy back your future time.

Closing: the best Definition of Done is boring

And the best part? I could finally ship with confidence—not because I became smarter, but because I stopped calling things done before they were operable.

The goal isn’t perfection.

The goal is to be able to sleep.

Thank you for reading this article, hope it’s helpful 📖. See you in the next article 🙌

💀 The Hidden Cost of “AI Features”: What I Learned Turning a Messaging App Into an Expense Tracker

Graita Sukma Febriansyah Triwildan Azmi — Wed, 04 Feb 2026 14:59:10 +0000

I create a Telegram bot and treat it as my personal ledger. It’s a bit addictive because “I can type anything and it just works”. And I realized, just ship it!

Then my chad's message themselves:

“Makan soto 20k.”
“Indihome 350k”
“Isi bensin 100k, tambah angin 5k, cilok 10k”
upload Indomaret photo receipt
a voice note after leaving a café

So I pivoted the product into what felt obvious: a chat-first expense tracker.

The killer feature was “auto-save expenses” from text, image, and audio. And once data was captured, we added analytics: weekly and monthly breakdowns, categories, trends, and a “you’re going to overshoot” signal (fancy word for overcast, wkwkw).

The product felt magical:

You don’t “log expenses”. You just send your saved messages.
The bot does the bookkeeping.

The beta version was cheap because the demo was polite

In demos, users send one clean message. One receipt. One voice note. Everything is short and predictable.

In real production, a chat UI is basically a cost amplifier:

users spam message
they resend when it feels slow
they paste long text
they upload huge images
they record 2-minute audio notes when 10 seconds would do
they ask for “weekly summary” five times because it looks fun

A messaging interface doesn’t behave like a form, it behaves like a stream. And for sure, AI love stream.. because it can charge you for every token spent :D

My original pipeline (aka “how I accidentally built a money burner”)

For each message, I did something like this:

If it’s text

detect if it’s an expense
extract amount, merchant, category, or define it
save transaction
respond with a confirmation + a friendly explanation

If it’s an image

OCR/vision extraction
parse line items or totals
extract amount, merchant, category, or define it
save transaction
respond with what it found and ask for confirmation

If it’s an audio

transcribe
run the same extraction as text
save transaction
respond with a summary

Then on top of that, I had analytics:

weekly/monthly charts
“top categories”
“spikes” (“why is transport higher this week?”)
forecasting / overcast alerts (“you’re trending 18% above your normal pace”)

So the app wasn’t “AI + database.”

It was a distributed system with metered inference.

Hidden cost #1: tokens compound in a chat product

I didn’t feel it immediately because my brain was still in “API calls are roughly the same cost” mode.

But LLM usage isn’t flat. It scales with:

prompt length (system instructions + rules + examples)
user message length
retrieved context (history, past expenses, category list)
output length (confirmations, explanations, summaries)

And chat systems naturally push you toward more context:

“Use the last 20 messages so it understands the user”
“Include last month’s spending so it can categorize smarter”
“Include the user’s recurring merchants”
“Include the budget settings”
“Include the currency rules”

Suddenly, the simplest “makan soto 20k” message is riding inside a prompt suitcase filled with your entire product.

The cheapest token is the one you never send.

Chat UX makes you forget that.

Hidden cost #2: multimodal is not one cost—it's three

Text-only expense parsing was manageable.

Images and audio were where the bill started growing teeth.

Images (receipts)

A single receipt can mean:

image upload bandwidth + storage
vision/OCR inference cost
parsing errors → retries
confirmation flows (extra model calls)
edge cases (blur, shadows, multiple totals, currencies)

And users don’t upload “small receipts.”

They upload full-res photos straight off their camera roll.

Audio (voice notes)

Audio is sneaky because it’s time-based. People talk longer than they type.

A “quick note” becomes:

transcription compute
then LLM extraction
then confirmation response

So one voice note can be more expensive than ten text messages—without looking scary in the UI.

Hidden cost #3: analytics turns “data” into “context inflation”

The analytics requests were where I got hit hardest.

Because analytics queries are vague by nature:

“How am I doing this month?”
“Why am I spending more than usual?”
“What should I cut?”
“Give me a weekly summary”
“Predict next month”

To answer these, my first instinct was: send more context.

So I started retrieving lots of transactions, bundling them into the prompt, and asking the model to reason over it.

That’s the trap.

It works… until it scales.

Because now every analytics request is:

a database read (sometimes large)
plus prompt assembly
plus a big generation (users love long insights)
and it repeats weekly/monthly for every active user

This is where “AI features” quietly become “cloud bill features.”

Hidden cost #4: latency causes retries, retries cause duplicates, duplicates cause chaos

When the AI response took too long, users did what users do:

send the same message again
refresh
tap the button twice
re-upload the receipt
re-record the voice note

And if your system isn’t aggressively idempotent, you get:

duplicate transactions
angry users (“why is lunch logged twice?”)
extra model calls
extra cleanup tools you now must build

So the cost problem turned into a data integrity problem.

And the data integrity problem turned back into a cost problem.

The builder takeaway: AI features are product architecture now

Turning a messaging app into an expense tracker taught me something simple:

In a chat UI, every UX decision is a cost decision.

auto-run analytics = cost spike
long explanations by default = cost spike
“just include more context” = cost spike
retries without idempotency = cost spike and bad data
multimodal without guardrails = cost spike and latency pain

But you don’t need to fear it.

You just need to design AI like you design infra:

budgets
fast paths
async heavy work
caching
observability
graceful fallbacks

Because once AI is inside your product, you’re not only building features anymore.

You’re operating a meter.

Thank you for reading this article, hope it’s helpful 📖. See you in the next article 🙌

Web3 UX Finally Feels Normal in 2026: Smart Wallets, Account Abstraction, and the End of “Seed Phrase Panic”

Graita Sukma Febriansyah Triwildan Azmi — Thu, 29 Jan 2026 15:43:17 +0000

A friend tried my Web3 app few years ago and bounced in under two minutes. Not because the product was bad (a bit maybe), but the ritual was bad. Install a wallet, save 12 or 24 words (actually he screenshot it, LOL). Learn what gas is, buy the right token just to pay fees. Sign a message that reads like legal boilerplate. Fail the first transaction anyway.

Fast-forwards to 2026, and the same friend tried a different build of the same idea. They signed in with a passkey. The wallet was created in-app. The first transaction worked instantly. No “get ETH first” detour. If they lost their phone, recovery was possible without sacrificial offering.

That’s the real emerging trend in 2026: not “new chains” or “new tokens”, but Web3 Onboarding and Daily Usage Getting Boring in a Good Way.

And the reason is simple: account are becoming programmable.

The problem was never “users don’t get crypto”

It was that wallets were designed like raw infrastructure, not products. Most users still interact through EOAs (Externally Owned Accounts) which is a single private key that controls everythings. The EOA model is elegant for cryptography but terrible for human.

Seed phrase = single point of failure
Every meaningful action needs a signature
Users must hold the chain’s native token for fees
No built-in recovery
No fine-grained permissions (it’s basically “all access” or nothing)

EOAs don’t just create friction; they create fear. One wrong click, one compromised device, one lost phrase—game over. That’s not a “UX issue.” That’s a product-killer.

So in 2026, the most important shift is that more apps stop treating wallets like external luggage users must carry, and start treating them like part of the product surface.

Account abstraction (ERC-4337) made wallets programmable without changing Ethereum consensus

ERC-4337 is a pragmatic step toward “account abstraction” that works today using UserOperations, an EntryPoint contract, and bundlers that include operations into blocks.

You don’t need to memorize the whole architecture. The best mental model is:

Instead of “user sends a transaction,” think: user submits an intent, and wallet logic decides how that intent gets executed.

That single idea unlocks the UX upgrades people have wanted since 2017 but couldn’t ship safely on EOAs.

1) Gas stops being the first boss fight

With account abstraction, you can sponsor fees or let users pay fees in a different token (depending on chain/tooling and paymaster support). That removes the classic trap: “I need ETH to do anything.”

In product terms: your onboarding doesn’t require a detour into an exchange.

2) Batching turns three scary popups into one normal flow

Approve → swap → stake shouldn’t be three separate moments of anxiety. AA enables a wallet to batch multiple steps into a single operation (or at least a single user decision) so the user experiences “do the thing,” not “sign three times.”

3) Session keys kill the “sign every click” nightmare

For games, social apps, and anything high-frequency, asking users to sign constantly is UX poison. Smart accounts can support scoped permissions (spend limits, allowed actions, time windows) so users can play without being interrupted every 30 seconds.

4) Recovery becomes an actual design space

Because authorization logic lives in code, wallets can implement recovery patterns: multi-device, guardians, delays, spend limits, emergency locks. You’re no longer stuck with “hope your seed phrase is safe forever.”

EIP-7702 makes the migration story less painful

Even if smart accounts are better, billions of dollars and years of behavior are tied to EOAs. That’s the awkward truth.

EIP-7702 is part of the “make EOAs smarter” path, aiming to let EOAs opt into code-like behavior without forcing everyone to abandon their existing address and start over.

For builders, the significance isn’t the exact opcode-level mechanics. It’s this:

2026 is when “upgrade the wallet experience” stops sounding like “force users to migrate.”

That’s a big reason UX improvements are finally showing up in mainstream apps.

Embedded wallets: the wallet install step starts disappearing

Another 2026 shift: users increasingly don’t “go get a wallet” first. The wallet is embedded in the app.

Embedded wallets aim to keep the benefits of self-custody (or at least non-custodial patterns) while removing the biggest drop-off point: browser extensions and seed phrase ceremonies during onboarding.

This pairs perfectly with smart accounts:

embed onboarding
create a smart account automatically
sponsor the first transactions
reduce prompts with session keys
let users “graduate” later (export, connect external wallet, add hardware key)

It’s the same playbook Web2 used for payments: start simple, add power later.

Passkeys: the missing bridge between “normal app login” and “secure wallet access”

Passkeys are phishing-resistant, passwordless sign-in using cryptographic keys stored on devices (and often synced across devices securely).

In 2026, passkeys matter because they let apps:

offer familiar login UX
reduce phishing compared to passwords
integrate cleanly into recovery and multi-device flows

If your goal is adoption beyond crypto natives, passkeys are part of the “make it feel normal” stack—not because they’re trendy, but because they reduce the cognitive load users hate.

What a “normal” Web3 flow looks like in 2026

Here’s the blueprint that keeps showing up in real products:

Onboarding (under a minute)

User signs in with passkey
App creates an embedded wallet (or links one if they already have it)
Smart account is initialized (AA-compatible)
First action succeeds immediately (fees sponsored or abstracted)

Daily usage (no constant interruptions)

routine actions use scoped session keys
multi-step actions are batched
user sees “confirm what you want,” not “sign unknown bytes”

Recovery (designed, not improvised)

multi-device recovery
guardians / secondary verification
optional time locks and spend limits
emergency “freeze” if compromise is suspected

This is where Web3 stops feeling like a hardware hobby and starts feeling like software.

The builder’s decision: pick a wallet architecture like you’d pick an auth architecture

If you’re writing for software devs, make this section crisp and opinionated.

Option A: Smart accounts from day one (ERC-4337-first)

Best for: consumer apps, games, social, anything you want to feel smooth.

Tradeoffs: you rely on bundler/paymaster infrastructure and must design safeguards carefully.

Option B: Hybrid path (EOA today, upgrade path via 7702-style approach)

Best for: products with existing users or existing addresses you don’t want to abandon.

Tradeoffs: complexity: two modes of account behavior, more edge cases.

Option C: Embedded wallet + smart account (mainstream onboarding)

Best for: retention and growth; it’s the lowest-friction path.

Tradeoffs: vendor/platform decisions, operational risk, and security responsibility.

A useful way to frame it:

Wallet architecture is now product architecture.

Closing: 2026 isn’t mass adoption—it’s mass retention

Web3 spent years optimizing for getting users to show up.

2026 is the pivot to keeping them.

When onboarding feels normal, and failure states are survivable, developers stop spending half the roadmap on “wallet education” and start building actual product features. That’s why smart wallets and account abstraction are the trend worth writing about.

The best sign you’re doing it right is simple:

Your user doesn’t think about the wallet. They think about the app.

Thank you for reading this article, hope it's helpful 📖. See you in the next article 🙌.

Deployment Workflow with GitHub Action 🚢

Graita Sukma Febriansyah Triwildan Azmi — Sat, 17 Jan 2026 05:22:44 +0000

Introduction

Deploying code can be a headache—pushing updates, running tests, and making sure everything works without breaking production. That's where deployment automation comes in. Instead of doing everything manually, you set up a system that handles the repetitive stuff for you.

GitHub Actions makes this process way easier. Since it's built right into GitHub, you don't need to juggle multiple tools or services. You can set up automated workflows that test your code, build your project, and deploy it—all triggered by things like pushing commits or merging pull requests. It's basically your personal deployment assistant that works whenever you need it.

What is GitHub Actions?

GitHub Actions is built around a few simple ideas that work together:

Workflows are like instruction manuals that tell GitHub what to do. They're just text files that sit in your project.
Jobs are the major tasks in your workflow—like "test the code" or "deploy to production." They can run one after another or all at once.
Steps are the individual actions within each job. Think of them as the actual commands you'd type if you were doing this manually.
Runners are the computers that actually do the work. GitHub provides them for free, or you can use your own if you need something specific.

Why people like using GitHub Actions:

It's already part of GitHub, so you don't need to sign up for another service or sync anything.
You can automate pretty much anything—testing, building, deploying, even sending notifications.
It's flexible enough to work with almost any language, framework, or deployment target you can think of.

Setting Up Your First Deployment

Okay, enough of the lecture, let’s start the implementation right away. For this tutorial, we’ll do a simple deployment on a Nest.js application. To help you better understand the flow, let’s take a look at this picture flow.

When you push to the staging branch, it triggers the workflow. There are two jobs: build-and-publish and deploy. The first job builds the project and uploads the package to the cloud container registry. The second job retrieves environment variables from GitHub secrets, securely sends them to the VPS, pulls the update, and runs the latest package version. That’s it. Pretty simple, right?

Alright, now let’s make our hands dirty. First, you need to create a folder like this:

- .github
    - workflows
        - staging.yaml #feel free to rename this

All GitHub Actions files go inside the .github/workflows folder.

Now, let's define the first rule to determine when the workflow should run.

name: Staging - Build, Push and Deploy

on:
  push:
    branches:
      - staging

env:
  REGISTRY: ghcr.io
  PROJECT_KEY: github-action-example

In this step, we want the workflow to be triggered when someone pushes code to the staging branch. We'll also define environment variables that will be used in the next steps.

Then, we’ll define our first job, which is Build and Push.

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    outputs:
      image_tag: ${{ steps.get_sha.outputs.short_sha }}
      repo_owner: ${{ steps.lowercase.outputs.owner }}

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Get commit SHA
        id: get_sha
        run: |
          echo "short_sha=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
          echo "full_sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Lowercase repository owner
        id: lowercase
        run: echo "owner=$(echo '${{ github.repository_owner }}' | tr '[:upper:]' '[:lower:]')" >> $GITHUB_OUTPUT

      - name: Extract metadata for Docker
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ steps.lowercase.outputs.owner }}/${{ env.PROJECT_KEY}}
          tags: |
            type=ref,event=branch
            type=sha,prefix=,format=short
            type=raw,value=staging-latest

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
          build-args: |
            COMMIT_SHA=${{ steps.get_sha.outputs.short_sha }}
        env:
          DOCKER_BUILDKIT: 1

We set permissions to read content and write packages. This lets us read the repository content (source code) and publish to GitHub Container Registry. We also create outputs for image_tag and repo_owner.
First, we check out the current branch and get the short and full SHA commit. Then we set up Docker Buildx (basically a Docker builder) and log in to GitHub Container Registry. Next, we transform the repository owner to lowercase (ghcr forces package names to be lowercase :D). Finally, we grab the metadata, build the image, and push the package to the registry.

Great, now let’s define our second job, which is deploy.

deploy:
    runs-on: ubuntu-latest
    needs: build-and-push
    environment: staging
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Create .env file from .env.example
        env:
          SECRETS_JSON: ${{ toJSON(secrets) }}
        run: |
          # Parse secrets JSON
          echo "$SECRETS_JSON" > /tmp/secrets.json

          # Read .env.example and create .env with actual values
          while IFS= read -r line || [ -n "$line" ]; do
            # Skip comments and empty lines
            if [[ "$line" =~ ^[[:space:]]*# ]] || [[ -z "${line// }" ]]; then
              continue
            fi

            # Extract key name (before =)
            if [[ "$line" =~ ^([A-Z_][A-Z0-9_]*)= ]]; then
              key="${BASH_REMATCH[1]}"

              # Get value from secrets
              value=$(jq -r --arg key "$key" '.[$key] // empty' /tmp/secrets.json)

              echo "${key}=${value}" >> .env
            fi
          done < .env.example

          # Clean up temp files
          rm -f /tmp/secrets.json

          echo "Generated .env file:"
          cat .env

      - name: Copy env files to server
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.VPS_STAGING_HOST }}
          username: ${{ secrets.VPS_STAGING_USER }}
          key: ${{ secrets.VPS_STAGING_KEY }}
          source: '.env'
          target: ${{ env.PROJECT_KEY }}
          overwrite: true
          debug: false

      - name: SSH Deploy
        uses: appleboy/ssh-action@v0.1.6
        with:
          host: ${{ secrets.VPS_STAGING_HOST }}
          username: ${{ secrets.VPS_STAGING_USER }}
          key: ${{ secrets.VPS_STAGING_KEY }}
          debug: false
          script: |
            # Navigate to staging deployment directory
            cd ${{ env.PROJECT_KEY }}

            # Restore git repository state
            git restore .

            # Pull latest changes
            git pull origin staging

            # Login to GitHub Container Registry
            echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin

            # Set environment variables for image tags
            export IMAGE_TAG=${{ needs.build-and-push.outputs.image_tag }}
            export REPO_OWNER=${{ needs.build-and-push.outputs.repo_owner }}
            export BUILT_IMAGE=ghcr.io/${REPO_OWNER}/${{ env.PROJECT_KEY }}:${IMAGE_TAG}

            # Pull backend image
            docker pull ${BUILT_IMAGE}

            # Replace placeholders in docker-compose-prod.yml
            sed -i "s|--built-image--|${BUILT_IMAGE}|g" docker-compose-prod.yml

            # Stop existing containers
            docker compose -f docker-compose-prod.yml down

            # Sleep for a few seconds to ensure proper shutdown
            sleep 5

            # Start services
            docker compose -f docker-compose-prod.yml up -d

This job depends on the build-and-push job, so it waits until that finishes. We specify the GitHub environment as staging (more on this below).
First, we check out the current branch. Then we create an .env file based on .env.example and inject values from GitHub environment variables. Next, we securely send the .env file via SSH to our project directory. Finally, we pull the latest updates, retrieve the newest package, and run the application.

If you are interested in seeing the full implementation code, feel free to check this repo.

Nice work! Now let's check out GitHub Actions:

We have two actions triggered—one failed and one successful. Click on either action to see more details.

Here you can inspect your workflow and see what's happening. Just expand each step to see more details about the process.

Conclusion

So yeah, GitHub Actions is pretty solid for automating deployments. Once you've got your workflows set up, you don't have to manually push updates or worry about whether you forgot a step. It just handles the build, test, and deploy cycle for you. Whether you're working solo on a side project or with a team on something bigger, automating this stuff frees you up to actually build features instead of babysitting deployments.

Bonus: Setting up GitHub Environment

In our workflow, we're using GitHub Environment to store sensitive secrets and environment variables. Whenever you need to update or add new secrets, you can do it directly in GitHub. Just go to your repository settings and click on Environments. From there, you can create a new environment with whatever name you want.

Next, add a deployment rule to specify which branch can use this environment.

Now you can just add your environment secrets.

Thank you for reading this article, hope it's helpful 📖. Don't forget to follow the account for the latest updates 🌟. See you in the next article 🙌.

All you need to know and to get started building your first MCP 🤖

Graita Sukma Febriansyah Triwildan Azmi — Sun, 11 Jan 2026 03:10:10 +0000

What is MCP?

Definition and basic overview

Model Context Protocol (MCP) is a standard method for connecting AI applications with external systems. It can be a database, function, tool (e.g., search the web, create PDFs), or any process that helps AI better understand context and perform tasks. If you haven't realized it, most AI products already have this integration. A great example: when you ask something in ChatGPT or Grok, sometimes you'll see a background process called "search the web." That's MCP behind the scenes.

Why you should learn it

Today, anyone can create a small app to speed up daily tasks with AI. However, results often fall short because the app lacks full context about the question. What if you could give the AI complete information from your database? That's where MCP comes in. It helps AI better understand context before generating responses. The AI can execute available tools in the MCP and use the results to produce more accurate, context-aware outputs.

Architecture of MCP

Key participants

There are 3 key participants of MCP, which are:

MCP Host: The AI application that hosts, manages, and coordinates one or multiple MCP servers. It is responsible for deciding when to request external context and which tools should be used.

MCP Server: The service that exposes tools and context. It defines available capabilities, executes requests, and returns structured results back to the host.

MCP Client: The component that maintains the connection to an MCP server. It handles communication, sends requests, receives responses, and forwards context to the MCP host.Key participants

Building Blocks for MCP

Beyond the key participants, MCP relies on several core building blocks. These components work together to make tool execution reliable, secure, and context-aware. Not every MCP server needs all of them, but production-ready systems usually implement most of these blocks.

Tool Definitions

Tool definitions describe what the MCP server can do. Each tool clearly specifies:

The tool name
What the tool does
Required input parameters
The expected output structure

These definitions allow the AI to reason about which tool to call, when to call it, and how to use the result. Well-designed tool definitions are critical—ambiguous or overly complex tools often lead to poor AI decisions.

Good tool definitions are:

Explicit and predictable
Narrow in responsibility
Deterministic in output

The clearer the definition, the better the AI can use it.

Transport Layer

The transport layer defines how the MCP client and server communicate. It handles message delivery, connection lifecycle, and data streaming.

1. stdio (Standard Input/Output)

This method uses standard input and output streams for communication. The MCP server runs as a child process and communicates via stdin/stdout.

Best suited for:

Local development
CLI-based tools
Single-user environments

It’s simple, fast, and easy to debug, making it ideal for early-stage MCP development.

2. SSE (Server-Sent Events)

SSE enables one-way, real-time communication from server to client over HTTP. The server can push updates whenever new data is available.

Best suited for:

Remote MCP servers
Web-based clients
Long-running or streaming tasks

Because SSE is built on standard web protocols, it works well with existing infrastructure and firewalls.

Context Injection

Context injection provides relevant background information to the AI before it generates a response. This may include:

User profile data
Recent conversation history
Database records
Application state

Instead of forcing the AI to guess, MCP allows you to explicitly supply the information it needs. Strong context injection dramatically improves accuracy, relevance, and consistency.

Designing good context is often more important than model choice. Poor context leads to hallucinations; good context leads to reliable outputs. You can learn more on how to build better context injection at https://context7.com/.

Security & Permissions

Security controls who can access which tools and data. This is essential when MCP is connected to sensitive systems such as:

User databases
Financial data
Internal APIs

Common security mechanisms include:

Authentication (API keys, tokens, OAuth)
Authorization (role-based or permission-based access)
Tool-level restrictions

A best practice is to treat MCP tools as privileged operations and only expose what is strictly necessary.

Observability & Error Handling

Observability helps you understand what the MCP system is doing at runtime. This includes:

Tool invocation logs
Execution latency
Success and failure rates
Error messages and stack traces

Proper error handling ensures that:

Failures are surfaced clearly to the host
Partial failures don’t crash the system
The AI can recover or retry when possible

Without observability, MCP systems become difficult to debug and unsafe to scale.

Helpful Resources

If you want to go deeper and start building with MCP, the following resources are a great place to begin:

Getting Started Guide

Learn the fundamentals of MCP, its design philosophy, and how to set up your first MCP server.

👉 https://modelcontextprotocol.io/docs/getting-started/intro
Official Examples

Explore real-world MCP implementations and see how tools, transports, and context are put together.

👉 https://modelcontextprotocol.io/examples
Community Discussions & Support

Ask questions, share ideas, and learn from others building with MCP.

👉 https://github.com/orgs/modelcontextprotocol/discussions

Secure protected API with HMAC! Next Level of API Keys 🔐

Graita Sukma Febriansyah Triwildan Azmi — Sun, 31 Mar 2024 09:42:24 +0000

Is using API Keys enough to protect private APIs? Certainly not. The way API Keys work is by checking and validating whether the request sent by the client contains an API key, which is usually embedded in the header or query request. If the API key exists and is valid, the request is allowed, otherwise not.

This simple method may sound secure because only someone with a valid API key can access it. However, there's a security aspect that allows someone to steal the API key. The API Keys method embeds the API key directly into the header or query of the request, allowing others to see the content inserted into that request. As a result, someone can intercept the request and steal the API key 😮.

There are many API authentication methods that can be used to protect private APIs, one of the most popular being *JWT *(JSON Web Token). This method requires the client to log in to the system and obtain a token to access the API. However, this method is sometimes not ideal for APIs that involve data sharing or matrix reports because the client must log in first and secure their token to access the API. It should be noted that JWT tokens are embedded in the header, which can also be intercepted and stolen by others.

What is HMAC?
Another authentication method to consider is *HMAC *(Hash-based Message Authentication Code). This method uses a Public key embedded in the header or query and a Secret key to calculate the hash of a request data. It is important to note that the secret key will not be embedded in the request but will be used for hashing the request data. The resulting hash (usually called the signature) is then embedded along with the public key. By implementing HMAC, the server will validate the request by comparing the hash value. If the hash values match, the request will be allowed, otherwise not.

The HMAC method depends on the similarity of the secret key and the hashing algorithm used. For example, using "this-is-super-secret-key" as the secret key and HmacSHA256 as the chosen hashing algorithm. Then the server and client must use the same secret key and hashing algorithm to verify that the request is authentic. With this technique, someone attempting to intervene in the request will not be able to use the same signature for another request.

Pros and Cons
Although using HMAC seems secure enough, there are still advantages and disadvantages to this method. It would be better if this method is combined with other security measures such as IP Locking, Rate Limiting, and so on. The advantages offered by this method are as follows:

Data Integrity: ensuring secure communication by verifying the integrity of the request.
Protection Against Unauthorized Access: the API can only be accessed by clients with a valid secret key.

The disadvantages of this method are as follows:

Key management and social engineering: ensuring that the secret key is not leaked into the wrong hands.
Performance overhead: verifying the signature by a server receiving too many requests will require higher computational resources.

Auth Flow
So what is the actual process of the HMAC method, is it simple or quite complicated? Let's look at the following diagrams to get an idea.

It looks easy, right? The request data is combined with the secret key to create the digest algorithm and then the HMAC is calculated. Okay, now take a look at the following diagram to see how the process goes.

Both the server and client agree on the public key, secret key, and algorithm to be used.
The client will create a signature based on the requested data with the secret key.
The client inserts the public key and signature into the header request.
The server receives the request and verifies it by replicating the signature creation with the data (taken from the header and body request) and the same secret key.
If the signature matches, the request will be allowed, and vice versa, if not, it will be returned with an error 401 (Unauthorized).

How to code?
Okay, now it's time for practice! Here is a simple pseudocode to implement the HMAC method. If you're interested in seeing actual program code using the Nest.js framework, please check the following GitHub repository.

PUBLIC_KEY = req.headers[x-api-key];
SIGNATURE_KEY = req.headers[x-signature-key]
REQUEST_DATA = req.body;

// Check if public key and signature exist
if (!PUBLIC_KEY && !SIGNATURE_KEY) {
  throw Error(401)
}

// Regenerate Signature
SERVER_SIGNATURE = generateSignature(PUBLIC_KEY, SIGNATURE_KEY, REQUEST_DATA)

// Verify Signature
if (SERVER_SIGNATURE == SIGNATURE_KEY) {
  return OK(200)
} else {
  return Error(401)
}

Conclusion
Hmm, so are you interested in implementing the next level of API Keys? By using the HMAC method, API security will be maintained with cryptographic principles that are impossible to reverse engineer (perhaps if Quantum Computing is operational, cryptographic algorithms will be different 😃).

Thank you for reading this article, hope it's helpful 📖. Don't forget to follow the account for the latest updates 🌟. See you in the next article 🙌.

Node.js Send Email using Google OAuth2

Graita Sukma Febriansyah Triwildan Azmi — Tue, 25 Apr 2023 08:33:06 +0000

One common requirement of back-end application development is sending a message via email. This feature can support business processes such as verifying user data, notifications, account security, marketing, and many other use cases.

Then, how can we send an email message in a Node.js application?

One of the libraries that are widely used in sending emails is Nodemailer. There is the easiest way of implementation which using the Google App Password service. However, this method has been labelled by Google as less secure because the result of generated password is easy to memorize and less complex, so the security level is lower.

Alternatively, there is a way in sending an email using the Google OAuth2 method. OAuth2 (Open Authorization 2.0) is an authentication and authorization protocol used to allow third parties to access protected resources. This method has a high level of security and has been used as a security standard in the technology industry.

Ok, shall we begin :)

The first thing to do is to create a project in the Google Developer Console (make sure you have a Google account) :D

After the project is successfully created, go to the left tab in the section API & Services > OAuth Consent Screen then select External configuration. Next, fill in the app name data, user support email, and developer contact information, then follow the next instructions and save. To activate the OAuth Consent Screen configuration, do Publish App and confirm.

Great, it's time to configure the OAuth Client ID. On the tab API & Service, select the menu Credential > Create Credentials > OAuth Client ID. After that, fill the application type with a web application, a name with the application name (feel free to naming), and add the URI https://developers.google.com/oauthplayground in the Authorized redirect URIs section. Creating an OAuth Client ID generates credentials in the form of an ID and a secret (keep it safe, you can download it in JSON format).

Nice, the next step is to test OAuth Client ID and get the refresh token. Visit Google Developer OAuth Playground, set OAuth Client ID and secret configuration using your credentials, then select http://mail.google.com/. Next, you will be redirected to the Google Authentication pages, choose the same account used to create OAuth Client ID. If you are facing a page that is not safe, open the menu Advanced Options and click Continue (not safe) (this is happen because we are not submitting the verification app to Google, but you can ignore it for a moment). The result is an authentication code, refresh token, and access token (once more, keep it safe).

Wow, the configuration is quite long, whereas we are not yet writing a single piece of code. But now, let's write some code. Start with creating an empty folder then initialize the project (fill it according to the project initialization instructions).



npm init

We will code using Typescript, if you are more prefer using Javascript just install the 3 dependencies needed (however you will need some adjustments from Typescript to Javascript).



npm i --save-dev typescript ts-node @types/node



npm i dotenv nodemailer googleapis

Great, now create a file with an .env extension to store the credentials locally.



OAUTH_EMAIL=
OAUTH_CLIENT_ID=
OAUTH_CLIENT_SECRET=
OAUTH_REFRESH_TOKEN=

Nice, now create an index.ts file. The first thing to do is import the required dependencies and get the value of our environment variables.

Next, create an OAuth2 Client object and make a getAccessToken request. This function returns a value in the form of an accessToken code which is used as the authorization when sending emails.

Lastly, create a transporter configuration with SMTP and set the mailOptions as the email sending object.

Congratulations! Email sending using the OAuth2 method was successful. With the steps that have been followed, the email sent will be guaranteed to be secure and properly authenticated.

Conclusion

Using the OAuth2 method to send email via Nodemailer has several advantages, including: increasing security by avoiding using usernames and passwords, enabling good integration with third-party email services and can increase application scalability.

If you want to get this source code, feel free to take a look at this GitHub repo.

Thank you for reading this article, hope it's useful 📖. Don't forget to follow the account to get the latest information🌟. See you in the next article🙌.

Express file upload using Multer

Graita Sukma Febriansyah Triwildan Azmi — Mon, 03 Apr 2023 07:34:45 +0000

When you are developing an API (Application Programming Interface) there must be a requirement which allows users to be able to upload or download file. A simple example of this implementation is the user able to change his picture profile. In this case, data sent by the user is not JSON (Javascript Object Notation), but the file data type. To send this data, the user has to send through the body using multipart/form data format.

What is the library to be used to create an API which able to upload or download files?

The answer to that question is Multer. Multer is one of the node.js libraries in the form of middleware which able to handle files through multipart/form data. You need to know that multipart/form data is one of content-type inside HTML form.

Multer works with adding an object body and object file to the request body. Through this, there is data containing a value from the text field and file data which is attached in HTML form.

How to create an API which able to upload and download the file in node.js?

To answer this question, we will build a simple express app which has two endpoints for uploading and downloading a file. The first step is to install the multer dependencies.
npm i express multer

Ok, before we start to write the code, we will create a folder structure like this:



src/
├── upload/
└── index.js

Great, next we will import the required dependencies.

Nice, now we will create multer configuration, upload function, and delete file function.

You can see in the configuration section, we setting uploads folder as a file storage directory. Then we set file naming so that there are no similarities in names. On the upload function, we set diskStorage as storage and apply a file limit size of 25Mb. On the deleteFile function, we create a function which accepts one argument as the file we want to delete.

Hmm... looks like something is missing. Validation? Yup, this part is responsible to ensure the file format under the data we want.

Excellent, now is the time for us to implement the configurations and functions that have been made in the route API.

Great job, now we have two routes which are uploads with HTTP method POST and uploads/:id with HTTP method GET. On the route POST, we applied a function upload.single with an argument 'file'. This 'file' is the body of the form data use to send the file. You can change the name of 'file' with others, such as 'picture'. Next, a check is applied to ensure the file is not empty and valid with our format. On the route GET, we use params :id to get the file that we want. Next, it will check whether the file exist or not.

Conclusion

To create an API which able to receive a file, we can use Multer. On the route we have created, it applied a function upload.single to accept one file. If you want to accept more than one file, you can use the function upload.array.

If you want to get this source code, feel free to take a look at this GitHub repo.

Thank you for reading this article, hope it's useful 📖. Don't forget to follow the account to get the latest information🌟. See you in the next article🙌.