Onchain Apps
Blockchain apps are web apps. The chain is just another backend.
Smart contract writing is 20-30% of a production Web3 project. The other 70-80% is standard web development — hooks, routes, state management, UI components. Your Next.js skills transfer directly. The only layer that changes is where the action lands.
Same Patterns
Every onchain interaction maps to a pattern you already use.
| Web Dev Pattern | Traditional | Onchain |
|---|---|---|
| Data fetching | useQuery / useSWR | useSuiClientQuery / wagmi useReadContract |
| Mutation | Server action / useMutation | Transaction (Sui PTB) / useWriteContract |
| Auth | NextAuth / Clerk | zkLogin / wallet connect |
| Events | WebSocket / SSE | Contract events / indexer subscription |
| API route | app/api/route.ts | Same — talks to RPC instead of database |
| State | Zustand / React Query cache | Same — chain is source of truth, cache locally |
The mental shift: a database stores mutable rows. A chain stores owned objects (Sui) or contract state (EVM). Your hooks read and write to it the same way — the SDK handles the transport.
App Architecture
Next.js pages / API routes ← standard web dev
↓
React hooks (read, write, auth) ← only this layer changes
↓
SDK + Provider (wagmi, dApp Kit) ← chain-specific adapter
↓
RPC → Blockchain ← replaces database
Everything above the hooks layer is identical to traditional web dev. Everything below is handled by the SDK. The hooks layer is where you learn something new — and each platform gives you a React-native toolkit for it.
SDK Comparison
Three platforms, three React toolkits. Same job: read state, send transactions, manage wallets.
| Concern | EVM | Solana | Sui |
|---|---|---|---|
| Base SDK | viem / ethers.js | @solana/web3.js | @mysten/sui |
| React hooks | wagmi | wallet-adapter-react | @mysten/dapp-kit |
| Wallet | WalletConnect / MetaMask | Phantom adapter | Sui Wallet + zkLogin |
| Seedless onboarding | ERC-4337 (complex) | None native | zkLogin (protocol-level) |
| Tx composition | Multicall (limited) | Instructions in one tx | PTBs (1,024 ops, atomic) |
| Sponsored gas | Paymaster contracts | Relayer services | Gas station API (native) |
The DX question: which platform lets a web developer ship a working dApp fastest? Sui's zkLogin removes the wallet install barrier entirely — users sign in with Google and get a Sui address. No extension, no seed phrase, no onboarding friction.
Three Failure Layers
Where bugs actually live in onchain apps:
| Layer | What Breaks | Web Dev Analogy |
|---|---|---|
| Contract | Logic errors are permanent | Database schema bugs |
| Bridge | SDK calls, event parsing, tx construction | API client / ORM bugs |
| Off-chain | Indexers, agents, API routes | Backend service bugs |
Most integration bugs live in the bridge layer — the same place most REST API bugs live. The contract is small by design. The off-chain code is where complexity compounds.
Dig Deeper
- Data Indexers — How chain data becomes queryable: The Graph, custom subgraphs, indexer patterns
- Notifications — Transaction status and event push via Blocknative and alternatives
Context
- Smart Contracts — The protocol layer: safety comparison, standards, platform choice
- Sui Frontend Integration — dApp Kit setup, zkLogin flow, SDK patterns
- State Management — Same caching and fetching patterns, different data source
- DApp UI Dev Kits — Scaffold-ETH, Thirdweb — full-stack starter kits
- Web3 Hooks — EVM-specific hook abstractions (wagmi layer)
Links
- wagmi — React hooks for EVM chains
- viem — TypeScript interface for EVM
- @mysten/dapp-kit — React SDK for Sui
- @solana/wallet-adapter — Solana wallet integration
Questions
At what layer does onchain interaction stop being "just web dev" and require chain-specific thinking?
- What state management pattern handles wallet connection, transaction status, and chain switching without chain-specific code in the UI layer?
- When does an SDK abstraction layer add value versus hide errors you need to see?
- How do you test onchain interactions in CI without hitting a live network?
- What makes sponsored transactions (zero gas for users) a product requirement rather than a nice-to-have?