DEV Community: samurai-techlead

Building a Secure E-Commerce Chat Agent with Stored Procedures

samurai-techlead — Tue, 06 Jan 2026 14:58:56 +0000

Background

Recently, I tried to build a GPT-like chat agent for a specific e-commerce platform.

Not a generic chatbot.
Not a demo.

A real product-facing agent that could answer questions like:

"Where is my order?"
"Can I get a refund?"
"Show me my last purchase"

To do this, the agent had to access real production data — orders, shipments, payments.

That’s when I hit an important problem.

The Problem I Faced

As soon as an agent needs database access, a tempting idea appears:

“Why not just let the LLM generate SQL from the user’s question?”

It sounds simple.
It works in demos.

But in a real e-commerce system, it quickly becomes dangerous.

Scenario

You are building a chat application for a specific e-commerce platform.

The chat agent supports:

Order status inquiries
Shipping & delivery tracking
Refund eligibility checks
Purchase history summaries
Account-related questions

This is not a general-purpose GPT. It is a platform-bound assistant with access to sensitive user data.

The Core Problem

Chat agents often need database access.

A common but dangerous approach is:

Share database schema with the LLM
Ask the LLM to generate SQL from user input
Execute that SQL directly

This approach fails in production.

Why LLM-Generated SQL Is a Bad Idea

Security Risks

Prompt injection can manipulate queries
Over-broad SELECT * queries expose sensitive data
Privilege escalation becomes possible

Hallucinated Queries

Non-existent tables or columns
Incorrect joins
Wrong business logic

No Governance

No clear contract of allowed queries
Hard to audit data access
Schema changes break prompts

Core Principle

LLMs should decide what intent to fulfill, not how to query data.

This is the same principle used in traditional backend systems.

The Right Architecture: Stored Procedures as Agent Tools

High-Level Flow

Key Design Rules

Database logic lives in stored procedures
LLM never sees table names or columns
Agent only chooses which procedure to call

Step 1: Define Stored Procedures (Database Layer)

Get the Latest Order

CREATE PROCEDURE get_latest_order (
  IN p_user_id BIGINT
)
BEGIN
  SELECT
    order_id,
    order_status,
    total_amount,
    created_at
  FROM orders
  WHERE user_id = p_user_id
  ORDER BY created_at DESC
  LIMIT 1;
END;

✔ Enforces user-level data isolation
✔ No schema exposure to the agent

Get Shipping Status for an Order

CREATE PROCEDURE get_order_shipping_status (
  IN p_order_id BIGINT,
  IN p_user_id BIGINT
)
BEGIN
  SELECT
    shipping_provider,
    tracking_number,
    shipping_status,
    estimated_delivery
  FROM shipments
  WHERE order_id = p_order_id
    AND user_id = p_user_id;
END;

✔ Ownership validation at DB level
✔ Prevents cross-user access

Step 2: Expose Procedures as Agent Tools

The LLM never sees SQL.

It sees tools.

[
  {
    "name": "get_latest_order",
    "description": "Get the most recent order for the authenticated user",
    "parameters": {}
  },
  {
    "name": "get_order_shipping_status",
    "description": "Get shipping details for a specific order",
    "parameters": {
      "order_id": "number"
    }
  }
]

User identity is injected by the system — not the LLM.

Step 3: Agent Reasoning Flow

User Message

"Where is my last order?"

Agent Behavior

Identify intent: order inquiry
No order ID provided
Call get_latest_order
Use returned order_id
Call get_order_shipping_status

Step 4: User Response

Your latest order was placed on March 2.

Status: Shipped
Carrier: Yamato
Tracking Number: 1234-5678
Estimated Delivery: March 6

Advanced Example: Refund Eligibility

Stored Procedure

CREATE PROCEDURE check_refund_eligibility (
  IN p_order_id BIGINT,
  IN p_user_id BIGINT
)
BEGIN
  SELECT
    CASE
      WHEN order_status = 'DELIVERED'
       AND DATEDIFF(NOW(), delivered_at) <= 7
      THEN 'ELIGIBLE'
      ELSE 'NOT_ELIGIBLE'
    END AS refund_status
  FROM orders
  WHERE order_id = p_order_id
    AND user_id = p_user_id;
END;

Business rules stay out of prompts.

Why This Design Works

Security by Default

No arbitrary SQL execution
Strict access boundaries
Minimal blast radius

No Hallucinations

LLM cannot invent tables or joins
Only allowed operations are callable

Strong Observability

Each call can be logged:

user_id=123
tool=check_refund_eligibility
order_id=88921
timestamp=...

Stored Procedures vs LLM-Generated SQL

Aspect	LLM SQL	Stored Procedures
Security	❌ Risky	✅ Safe
Hallucinations	❌ Common	✅ Impossible
Auditing	❌ Hard	✅ Easy
Schema changes	❌ Break prompts	✅ Isolated
Enterprise-ready	❌ No	✅ Yes

Final Thoughts

Chat agents feel new — but backend fundamentals still apply.

Treat your database like a private API.

Stored procedures provide:

Safety
Stability
Observability
Enterprise-grade control

This is how you build real, production-ready e-commerce chat agents — not demos.

How To build the secret chat app using MLS and ChatE2EE

samurai-techlead — Tue, 06 Jan 2026 14:33:02 +0000

How To Build a Secret Chat App Using MLS and ChatE2EE

Designing a modern, end-to-end encrypted chat system for the web

Introduction

Building a secure chat application in 2026 is no longer just about
"encrypting messages."
Users expect:

Strong end-to-end encryption (E2EE)
Secure group messaging
Dynamic member management
Web-native performance
Cryptographic correctness without UX pain

Traditional E2EE approaches don't scale well to groups.
This is why Messaging Layer Security (MLS) exists.

This article explains how a secret chat app using MLS + ChatE2EE was
designed and implemented in practice.

Why MLS Is Necessary

Problems With Traditional Group Encryption

Pairwise encryption between every member
O(n²) key management complexity
Expensive re-keying
High implementation risk

What MLS Solves

Tree-based group key management
Efficient member add/remove/update
Forward secrecy & post-compromise security
Formally verified cryptographic design

MLS is to group chat what TLS is to the web.

Overall Architecture

Technology Stack

Frontend

TypeScript
React
Context-based state management

Cryptography

OpenMLS
Messaging Layer Security (RFC 9420)
Rust → WebAssembly

Storage

IndexedDB (web_sys)
Hybrid memory + persistent cache

Core Chat Foundation

Chat Messaging Layer

Message model
Conversation abstraction
Transport-agnostic pipeline
Deterministic ordering

MLS handles encryption only --- not UX or transport.

WASM + OpenMLS Integration

Rust bindings for JavaScript
Minimal JS ↔ Rust surface
Deterministic APIs

MLS Client Architecture

Group Lifecycle

Group creation
Welcome processing
Member addition
Secure state persistence

WASM Module Development

Why WASM

Browser-safe cryptography
Near-native performance
Rust memory safety
Reuse of OpenMLS

Runtime Responsibilities

Encryption / decryption
Group state transitions
KeyPackage generation
State serialization

Secure Key Storage

Hybrid Storage Strategy

Benefits: - Fast access - Crash recovery - Stable MLS epochs

Frontend Integration

Chat Context

MLS initialization
State restoration
Message routing
UI consistency

Message Flow

Security Guarantees

End-to-end encryption
Forward secrecy
Post-compromise security
Secure group membership
Zero server plaintext

Lessons Learned

MLS is complex but scalable
Persistence bugs are catastrophic
Welcome handling must be perfect
Debugging encrypted state is hard

Conclusion

Building a secret chat app using MLS and ChatE2EE requires effort,
but the result is a future-proof, standards-based, highly secure
communication system.

MLS is not experimental.

MLS is production-ready.

My Thoughts on Frontend Architecture & Framework Choices for 2026

samurai-techlead — Tue, 06 Jan 2026 13:57:24 +0000

My Thoughts on Frontend Architecture & Framework Choices for 2026

Frontend development changes fast.

Every year there’s a “new best framework” or a “new architecture pattern” that promises to fix everything.

So instead of saying “this is the only correct way”, I want to share my current thoughts and best practices for frontend architecture and framework choices going into 2026, based on what I actually see teams using successfully.

This is not theory — it’s what works.

Why Frontend Architecture Matters More Than Frameworks

Before talking about frameworks, I want to say this clearly:

A bad architecture with a good framework is still a bad app.

A good architecture can survive framework changes.

Most frontend pain doesn’t come from React vs Vue vs Svelte —

it comes from:

messy state management
unclear responsibilities
unscalable folder structures
tightly coupled UI and business logic

So let’s start with architecture.

Frontend Architecture Best Practices (2026 Edition)

1. Component-Driven Architecture Is the Default

In 2026, everything is component-driven.

You don’t think in pages anymore — you think in:

buttons
forms
cards
layouts
flows

Each component should:

do one thing
have clear inputs (props)
avoid hidden side effects

If your components feel reusable and boring — you’re doing it right.

2. Feature-Based Folder Structure (Not Type-Based)

This is one of the biggest improvements teams make.

Old style

components/
hooks/
services/
utils/

Feature-based

src/
 ├─ auth/
 │   ├─ login.page.tsx
 │   ├─ login.api.ts
 │   ├─ login.store.ts
 │   └─ login.styles.ts
 ├─ dashboard/
 └─ settings/

Why this works:

related code lives together
easier to delete or refactor features
new developers understand the app faster

3. Separate UI State, App State, and Server State

This is a huge one.

In modern frontend apps, not all state is the same.

A clean mental model:

UI state → local component state (modals, tabs)
App state → global client state (auth, theme)
Server state → data from APIs (cached, synced)

In practice:

UI state → component hooks
App state → Zustand / Redux / Pinia
Server state → React Query / SWR / TanStack Query

When teams mix these together, things get painful fast.

4. Monorepo When the Product Gets Bigger

If you have:

multiple apps
shared UI components
shared business logic

A monorepo becomes a big win.

Common tools:

Turborepo
Nx
pnpm workspaces

This helps with:

code sharing
consistent tooling
version management

For small apps, don’t overdo it.

For growing products, it’s worth it.

5. Design Systems Are No Longer Optional

In 2026, serious products almost always have:

design tokens
shared UI components
consistent spacing, colors, typography

This doesn’t mean a huge system on day one —

but at least:

reusable components
CSS variables
predictable styling rules

Your frontend moves faster when design decisions are centralized.

6. Micro-Frontends (Use Carefully)

Micro-frontends are not a default choice.

They make sense when:

many teams work independently
deployment independence is critical
the product is very large

They add complexity, so:

don’t start with them
earn them when you actually need them

Recommended Frontend Frameworks in 2026

Now let’s talk frameworks — not “which is best”, but which is best for what.

React + Next.js (Still the Safe Choice)

React is still everywhere, and Next.js has become the default React platform.

Why people still choose it:

massive ecosystem
strong TypeScript support
SSR, SSG, edge, API routes
easy hiring

If you’re building:

large products
SEO-critical apps
startups that may scale fast

This stack is still a very solid choice.

Svelte + SvelteKit (Simple & Fast)

Svelte feels refreshing.

Why people like it:

less boilerplate
very readable code
small bundles
fast performance

It’s great for:

startups
MVPs
teams that value simplicity

The ecosystem is smaller than React, but it’s growing steadily.

Solid.js (Performance-First)

Solid is for people who really care about performance.

Key ideas:

fine-grained reactivity
no virtual DOM
extremely fast updates

This shines in:

dashboards
real-time UIs
performance-sensitive apps

It’s not mainstream yet, but it’s respected.

Qwik (Next-Gen Thinking)

Qwik introduces a different idea: resumability instead of hydration.

Why it’s interesting:

instant interactivity
amazing performance for large pages
great SEO story

It requires a mindset shift, but it’s one of the most innovative frameworks right now.

Vue 3 + Nuxt (Balanced & Friendly)

Vue continues to be:

approachable
well-documented
enjoyable to write

Nuxt adds:

SSR
routing
full-stack capabilities

Great choice for:

teams that value clarity
long-term maintainability
balanced performance

Angular (Enterprise Stability)

Angular is still strong in enterprise environments.

Why teams choose it:

opinionated structure
built-in patterns
TypeScript by default

It’s heavier, but very stable for large organizations.

My Quick Recommendations by Use Case

Large product / startup → React + Next.js
Simple, fast, modern apps → SvelteKit
Performance-critical UI → Solid
SEO & instant load → Qwik
Clean & readable codebases → Vue + Nuxt
Enterprise teams → Angular

Final Thoughts

In 2026, frontend development is less about:

“Which framework is best?”

And more about:

“How clean is your architecture?”

Frameworks will change.

Good architecture scales.

If you focus on:

clear responsibilities
predictable state
feature-based structure
simple components

You’ll be in a good place — no matter which framework you choose.

Custodial Wallet Based Web3 Game Development

samurai-techlead — Tue, 24 Jun 2025 14:36:46 +0000

1. Introduction

Web3 gaming is rapidly transforming the way we think about digital ownership, player interaction, and in-game economies. But as a game developer, you’re likely facing a challenge: how do you make these new technologies accessible to your players while still providing the immersive experience they expect?

If you're new to the world of blockchain gaming, the term "wallet" probably comes up frequently. But when it comes to integrating wallets into your game, there's a key decision you'll need to make—custodial or non-custodial? And, for many developers, custodial wallets are quickly becoming the go-to option.

In this article, we'll dive deep into why custodial wallets are an excellent choice for Web3 game development. You’ll learn what they are, how they fit into your game’s system architecture, and the significant advantages they offer for both developers and players. Whether you’re aiming to reduce friction for new players or looking for a scalable solution that fits your game's growth, this guide will provide everything you need to make an informed decision.

2. What Are Custodial Wallets?

In the world of Web3 gaming, a wallet is essential for managing in-game assets, such as tokens, NFTs, or any other form of digital ownership. But when we talk about wallets, there are two main types that developers need to consider: custodial and non-custodial.

A custodial wallet is a type of digital wallet where a third-party service (such as a game developer or wallet provider) manages the private keys and security on behalf of the user. Essentially, the third party has control over the funds and assets stored in the wallet, but the user interacts with the wallet in a way that’s seamless and often much simpler than with non-custodial wallets.

On the other hand, non-custodial wallets are wallets where the user has full control over their private keys and assets. This is a more decentralised approach, allowing players to manage their own funds without relying on a third-party service. While this offers greater control, it also requires players to have a higher level of knowledge and technical ability, which can be a significant barrier for those unfamiliar with blockchain or cryptocurrency.

In a custodial wallet setup, players don't need to worry about managing private keys or understanding blockchain intricacies. The game itself acts as a custodian, making sure that assets are safe and easily accessible whenever the player needs them. This simplicity is one of the reasons custodial wallets are becoming so attractive in the Web3 gaming space.

3. Why Choose a Custodial Wallet for Web3 Gaming?

You may be wondering why custodial wallets are often the preferred choice for Web3 games, especially when compared to non-custodial options. The answer lies in the unique demands and challenges of the gaming world, where simplicity, speed, and user experience are paramount. Let’s take a look at some of the top reasons why custodial wallets are becoming the go-to solution for game developers and players alike.

Enhanced User Experience
One of the biggest hurdles for new players entering the world of Web3 gaming is the complexity of blockchain. Non-custodial wallets often require players to create and manage their own wallets, handle private keys, and understand the basics of cryptocurrency transactions. For most casual gamers, this can feel overwhelming and off-putting.

With custodial wallets, the game developer takes care of all of this on the backend. Players simply create an account, and the game automatically manages their digital assets in the background. This simplified approach makes Web3 games much more accessible to players who might otherwise shy away from anything that requires blockchain knowledge. The end result? A smoother and more enjoyable gaming experience for players at all levels of expertise.

Lower Entry Barriers for New Players
The steep learning curve of Web3 can prevent casual gamers from diving in. Most players are accustomed to logging in and playing without worrying about the technical side of things. With custodial wallets, players don’t have to bother with creating wallets, remembering seed phrases, or worrying about private key security. Instead, they can jump right into the game and start playing, removing a significant barrier to entry.

This is particularly important for games looking to appeal to the wider gaming community rather than just blockchain enthusiasts. By lowering the entry barriers, custodial wallets open up the game to a larger, more diverse audience.

Simplified Management of Digital Assets
Web3 games often involve complex in-game economies, where players can trade, sell, or earn tokens and NFTs. Managing these assets through a custodial wallet simplifies the process. The game itself holds and manages the player's assets, and users can easily access and interact with their tokens without having to go through the trouble of managing them on a blockchain platform.

For developers, this simplifies the integration of digital assets and reduces the risk of player confusion or mistakes. With the wallet and asset management all taken care of, players can focus on what really matters: enjoying the game.

4. System Architecture for Custodial Wallet Integration

Integrating a custodial wallet into your Web3 game isn't just about offering players a smooth experience—it also requires a solid backend system to ensure that all assets are managed securely and efficiently. Here’s an overview of how a typical custodial wallet system might be architected, and what you’ll need to consider as a game developer.

Overview of Wallet Service Provider Integration
At the core of your custodial wallet integration will be the wallet service provider—a third-party company or platform that manages the wallets on behalf of your players. Providers like Fortmatic, Torus, and WalletConnect are commonly used in Web3 applications. These services act as the intermediary between your game and the blockchain, providing secure storage and management of digital assets without requiring players to handle the complexity of private keys.

To integrate a custodial wallet system, you’ll need to connect your game’s backend with the wallet provider’s API. This allows your game to create and manage user wallets, handle asset transfers, and ensure the security of in-game assets. The wallet service provider will usually take care of encryption and private key storage, but you’ll want to ensure that you understand their system’s security measures to maintain trust.

Secure User Account Management
Security is critical when handling digital assets. For a custodial wallet, the wallet provider takes on the responsibility of managing private keys, but your game still needs to ensure that users’ accounts are securely managed and protected. You’ll need to implement strong authentication mechanisms—such as two-factor authentication (2FA) or single sign-on (SSO)—to prevent unauthorised access to user accounts.

Additionally, you’ll need a way to handle user account recovery, in case players forget their credentials or experience issues with their accounts. This may involve a combination of email-based recovery options and secure personal identification questions.

API and Backend Considerations
The API provided by your wallet service provider will be crucial for linking the wallet system with your game’s backend. The API will handle the creation of new wallets, user login, token management, and more. You’ll want to make sure your game is optimised for fast and efficient API calls, as the user experience can be impacted by slow transaction times or delays in wallet management.

Your backend system will also need to interact with the blockchain to facilitate transactions such as token transfers or NFT trades. You’ll need to choose a blockchain that fits the needs of your game (Ethereum, Polygon, Solana, etc.), and ensure your server is well-optimised for interacting with that network.

In addition, you’ll need to handle events like failed transactions or low balances gracefully, ensuring that your game can notify users of issues without disrupting their gameplay.

5. Advantages of Custodial Wallets in Web3 Games

As Web3 gaming continues to evolve, custodial wallets have become an increasingly popular choice for developers seeking to create accessible, scalable, and secure gaming experiences. While there are multiple reasons for choosing custodial wallets, let’s take a closer look at some of the key advantages they offer for both developers and players.

Simplified Onboarding Process
One of the most significant barriers to entry in Web3 games is the complexity of blockchain interactions. Players are often required to understand wallets, private keys, and the intricacies of blockchain transactions. This can overwhelm newcomers, especially those who aren't familiar with the world of crypto.

With custodial wallets, the onboarding process becomes incredibly straightforward. Players don’t need to create wallets or manage private keys. Instead, they simply sign up for an account, and the game manages all the technical aspects behind the scenes. This drastically reduces friction and makes it easier to attract a broader audience, including non-crypto-native players who may be hesitant to dive into the blockchain world.

Reduced Friction for Non-Crypto-Native Users
For non-crypto-native users, the process of setting up a wallet, securing private keys, and learning how to interact with blockchain-based assets can be daunting. Custodial wallets eliminate this complexity by removing the need for players to handle their private keys or understand blockchain mechanics. This leads to an overall better user experience, especially for those who are simply interested in playing games without needing to understand the technology powering them.

With custodial wallets, players can focus on gameplay, and the game developer manages all the complex blockchain interactions on their behalf. This makes Web3 games much more accessible to a mass audience, increasing adoption and retention rates.

Greater Control Over Player Funds
One of the often-discussed concerns with decentralisation is the challenge of ensuring that users feel their assets are secure and easily accessible. In a custodial wallet system, the game developer or wallet provider takes full responsibility for safeguarding the assets, including user tokens and NFTs. This means that if something goes wrong (e.g., a lost password or account issue), the game can provide support and facilitate recovery.

Additionally, custodial wallets allow the game to offer features like refunds or account recovery, which are typically harder to implement with non-custodial wallets. This gives players peace of mind knowing that their funds are protected and that they can regain access to their assets if they encounter any issues.

Scalability and User Growth Potential
As your game grows, you’ll need a system that can handle a large number of users and assets efficiently. Custodial wallets scale much better than non-custodial alternatives, as the responsibility for asset management lies with the game or wallet provider, not with individual players.

This allows developers to implement features like bulk user management, handle large transaction volumes more easily, and provide support for millions of players without burdening them with wallet-related complications. In turn, this enhances the game's ability to scale while maintaining a smooth user experience for a growing player base.

Reduced Risk of Player Errors
One common issue with non-custodial wallets is that players are often responsible for managing their private keys and wallet credentials. If they lose their private key or forget their seed phrase, they can lose access to their in-game assets forever.

With custodial wallets, this risk is mitigated because the game provider manages the security and recovery of the wallet. Players don’t have to worry about the potential for irreversible mistakes, and developers can offer more robust support to recover lost access.

6. Conclusion

Integrating a custodial wallet into your Web3 game can significantly enhance the player experience while reducing the barriers to entry for those unfamiliar with blockchain technology. By removing the complexity of managing private keys and simplifying wallet interactions, custodial wallets make it easier for players to dive into your game and engage with its ecosystem.

We’ve covered the key benefits of custodial wallets, such as smoother onboarding, improved security, and scalability for growth, and provided a step-by-step guide to help you implement them in your game. Whether you’re aiming to make your game accessible to a larger audience or streamline the management of in-game assets, custodial wallets offer a powerful solution.

As Web3 gaming continues to evolve, adopting a custodial wallet system could be your secret weapon in offering a frictionless experience that keeps players coming back for more. With the right wallet provider and a solid implementation strategy, you can ensure that your game remains user-friendly, scalable, and ready for the future of blockchain-powered gaming.

Now that you have the knowledge to integrate custodial wallets into your Web3 game, it’s time to take the next step and enhance your player experience. Happy developing!