Forem: danielAsaboro

Accounts: The Digital DNA of Solana

danielAsaboro — Sun, 15 Dec 2024 10:08:00 +0000

In 1953, James Watson burst into a Cambridge pub and declared "We have discovered the secret of life!" He and Francis Crick had just unveiled DNA's double helix - a four-letter code that orchestrates all living things, from bacteria to blue whales. What made their discovery so profound wasn't just mapping life's blueprint, but revealing how something so simple could create such boundless complexity.

History has shown us that the most revolutionary systems often emerge from radical simplification. Unix transformed computing by declaring that "everything is a file". This reduced complex hardware interactions to simple read and write operations. A programmer could now command a printer, read from a keyboard, or access network packets using the same basic commands.

LEGO built an empire on this same insight. Their standardized studs and tubes - identical plastic blocks - enable children to construct everything from medieval castles to space stations. Similarly, the Internet thrives on a simple foundation: packets - a universal protocol that breaks all digital communication into simple, standardized units. This foundational simplicity enables seamless global connectivity, whether streaming video or sending emails.

Even art follows this pattern. Music's infinite variety springs from just 12 notes in the chromatic scale, spawning countless genres across centuries and cultures. Modern computing relies on basic logic gates - "AND," "OR," and "NOT" - yet these simple operations power everything from calculators to artificial intelligence.

These systems - spanning science, technology, toys, networks, and art - may seem vastly different on the surface but they reveal a crucial insight: when we find the right elemental building block, transformation follows. True simplicity isn't a constraint - it's the foundation for boundless possibilities.

Solana embodies this same powerful principle

It radically declared that "everything is an account."

Just as DNA's four nucleotides can encode all of life's complexity, Solana's unified account structure serves as the universal building block for every transaction, program, and piece of data on the network. This isn't just an architectural choice; it's the key to understanding how Solana achieves its remarkable speed and scalability.

To be fair, when I first started developing on the Solana Blockchain, this concept felt alien. Coming from traditional development, I expected different data structures for different purposes - one type for storing data, another for programs, and yet another for user wallets. But Solana challenged this assumption entirely.

Make no mistake though, this uniformity isn't limiting - it's liberating. Let me show you how…

The Anatomy of an Account

Just as every DNA strand shares the same basic structure of nucleotides arranged along a sugar-phosphate backbone, every Solana account has fundamental properties that define its structure:

An address (32 bytes, like DNA's position on a chromosome)
A balance in SOL (like cellular resources)
Data (like genetic information)
An owner (a program that can modify the account's data, similar to gene regulatory systems)
Size (amount of space allocated)
Executable flag (whether it contains program code)
Rent settings (rent exemption)

Account Types: Different Genes, Same DNA

Like how different genes serve different functions while using the same genetic code, Solana accounts take on specialized roles through different configurations:

a) Program Accounts

Think of these as the enzyme-producing genes of Solana. They store executable code that can process instructions and modify other accounts. Just as enzymes catalyze specific biological reactions, program accounts execute specific on-chain operations. The System Program, for instance, is like a housekeeping gene, managing fundamental operations like account creation and SOL transfers.

b) Data Accounts

These are like the vast stretches of regulatory DNA that store critical information. Data accounts can hold any arbitrary data: marketplace listings, game states, social media posts, or governance proposals. Just as regulatory DNA controls when and how genes are expressed, data accounts often control program behavior.

c) Token Accounts

Consider these the protein-coding genes of the Solana ecosystem. They store information about token ownership and balances. Just as proteins have specific shapes and functions, token accounts have standardized structures (defined by the SPL Token Program) that enable fungible and non-fungible token operations.

Advanced Account Patterns

a) Signer Accounts and Authorization

Just as DNA has mechanisms to control gene expression, Solana has sophisticated systems for controlling account access. Signer accounts act like transcription factors, providing necessary authorization for specific operations. This creates a natural security model where complex operations require multiple specific "signatures," similar to how complex biological processes often require multiple regulatory proteins.

b) Account Seeds and Derivation

The concept of account seeds in Solana parallels how DNA sequences can be used to predict protein structures. Just as specific DNA sequences reliably produce specific proteins, account seeds can deterministically generate specific addresses. This enables powerful patterns like Program Derived Addresses (PDAs), where accounts can be predictably located without requiring private keys.

Account Interactions: The Cellular Symphony

Biology emerges from countless molecular interactions orchestrated by DNA, and Solana's power similarly comes from how accounts interact.

When a transaction arrives, it triggers a cascade of interactions reminiscent of cellular signaling pathways. Program accounts, like cellular enzymes, execute their code on data accounts, which serve as both substrates and products of these computational reactions. Token accounts participate in this dance by transferring assets between parties, much like proteins shuttling molecules between cellular compartments.

Cross-Program Composition

The real magic happens in cross-program composition. Programs can call other programs, creating complex chains of execution similar to biochemical cascades. This composability enables rich applications to emerge from simple account interactions, just as complex biological systems emerge from simple molecular mechanisms.

Transaction Processing and Parallelization

Like cellular machinery processing multiple genes simultaneously, Solana's runtime can process multiple transactions in parallel. This is made possible by the unified account structure, which allows the runtime to easily identify independent operations. The result is a system that can achieve remarkable throughput while maintaining consistency.

The Cost of Digital Existence

Just as cells require energy to maintain their DNA and molecular machinery, accounts in Solana must pay for their existence through a mechanism called "rent."

This storage fee, paid in lamports (fractional SOL), scales with the account's size - larger accounts require more resources, just as more complex cellular structures demand more energy to maintain.

Rent Economics and Network Health

The rent system isn't merely a pricing mechanism; it's fundamental to the network's health. Accounts can become exempt from rent by maintaining a minimum balance, similar to how cells maintain energy reserves for essential functions.

Those that can't maintain this balance face deletion, allowing Solana to reclaim their space - a process remarkably similar to how biological systems break down and recycle defunct cells and damaged DNA. This digital metabolism ensures network resources are used efficiently, with inactive accounts naturally falling away while vital ones persist.

Security Through Simplicity

The standardization of accounts creates a robust security model. Like how DNA repair mechanisms can identify and fix damaged sequences, Solana's runtime can easily verify account modifications against consistent rules. This uniformity makes it harder to introduce vulnerabilities through edge cases or unexpected interactions.

Memory Safety and Runtime Guarantees

The unified account structure enables strong runtime guarantees about memory safety and state transitions. Just as cellular machinery ensures DNA is correctly replicated and expressed, Solana's runtime ensures accounts are accessed and modified according to strict rules. This creates a predictable and verifiable system of state transitions.

Building the Future: Development Patterns

Understanding accounts as Solana's DNA opens new possibilities for protocol design. When designing a new protocol, the question becomes not "what different types of structures do I need?" but rather "how can I arrange these universal building blocks to create the functionality I want?" It's like being a genetic engineer, but instead of genes, you're working with accounts.

This paradigm shift fundamentally changes how we approach blockchain development. Just as genetic engineers don't invent new types of nucleotides but rather arrange existing DNA building blocks in novel ways, Solana developers work with a consistent set of account primitives to create complex systems.

The Account Engineering Mindset requires a fundamental shift in thinking - away from creating custom types and specialized storage solutions, towards thinking in terms of accounts and their relationships. This account-centric approach means carefully considering data flows, permissions, and component interactions through account relationships.

The most elegant Solana programs emerge through composition over complexity.

Rather than building specialized structures, experienced developers combine existing account patterns in novel ways, breaking down complex requirements into simpler account interactions that compose together - much like how complex biological systems emerge from chains of simple chemical reactions.

When designing Solana programs, developers must consider both account economics and lifecycles. Each account carries real costs in network resources, demanding efficient designs that minimize size while maximizing utility. Well-designed programs include mechanisms for cleaning up unused accounts and reclaiming resources, just as biological systems recycle cellular components.

Nature's use of DNA as a universal format enables remarkable efficiency, security, and adaptability.

Solana's unified account structure provides similar benefits - there's no need for complex routing between different types since all components speak the same language through unified accounts.

The beauty of Solana's design, like DNA itself, lies in how unlimited complexity emerges from elegant simplicity. By embracing this universal structure, developers create sophisticated systems while maintaining the security and performance benefits of standardization.

This is the profound insight at Solana's core: just as life's endless variety emerges from four simple nucleotides, the future of decentralized computing can emerge from the elegant simplicity of unified accounts.

Welcome to Solana: A Web2 Developer's Travel Guide to the Blockchain Nation

danielAsaboro — Sat, 14 Dec 2024 09:55:46 +0000

"Papers, please!"

It's a phrase that makes even the most seasoned traveller's heart skip a beat. Standing at border control, passport in hand, you're about to enter a new country.

Every nation has its own rules, its own culture, its own way of doing things. Some stamp your passport with intricate designs, others scan your biometrics, and a few might even ask you to sing their national anthem (looking at you, Bhutan).

Entering the world of Solana blockchain feels remarkably similar. And just like a modern country, it has its own customs, its own "official language," and yes - its own rather particular way of checking your papers. But don't worry; unlike that nerve-wracking moment at immigration, I'll be your friendly local guide.

A Personal Note

Three months ago, I was that bewildered tourist, staring at Solana terms like PDAs and SPL tokens the way most people stare at visa requirements written in bureaucratese. Now, after countless hours of exploration (and more than a few wrong turns), I'm ready to be your guide through this fascinating blockchain nation.

In this guide, we'll explore Solana not as a mere blockchain protocol, but as a thriving digital nation. We'll walk through its carefully designed institutions (built-in programs), understand its unique governance model (consensus mechanism), and learn how its citizens (accounts) interact within its borders. Think of this as your comprehensive citizenship guide – everything you need to know to become a productive member of the Solana ecosystem.

Want to explore a specific aspect of our digital nation? Feel free to use this guide to jump directly to any section that interests you. Whether you're curious about setting up your digital passport (wallet), understanding our national currency (SOL), or exploring our economic zones (DeFi), each section is designed to be independently accessible while still connecting to the broader narrative.

The Immigration Process (Getting Started)
The Government Structure (Built-in Programs)
The National Infrastructure & Constitution
Citizens and Their Laws (Accounts & Smart Contracts)
Local Customs & Public Works (Programming & Runtime)
International Relations (Cross-Chain Communication)
The Economic Zones (DeFi and dApps)
Emergency Services (Security Features)

The Immigration Process (Getting Started)

Like any journey to a new country, your first steps in Solana require some paperwork. Here's what you'll need:

Your Digital Passport (Wallet)

Picture yourself at a futuristic spaceport. Instead of a leather-bound booklet with stamps, your passport here is entirely digital - we call it a wallet. But this isn't your average digital billfold. Like the retinal scanners and fingerprint readers of modern airports, your Solana wallet contains sophisticated cryptographic credentials that prove you belong in this digital nation.

At its heart are three critical components, each playing a vital role in your identity. They are:

Private Key
Public Key
SeedPhrase

Think of your public key as your cosmic address - a unique identifier that lets others find and interact with you across the vastness of the blockchain. It's like having your own personal QR code that anyone can scan to send you messages or assets.

Your private key? That's your digital DNA - an absolutely unique signature that proves you are who you claim to be. Guard it as carefully as you would the keys to your house, because in this digital realm, possession of the private key literally makes you... you.

And then there's the seed phrase - your ultimate backup plan. Imagine if you could distill your entire identity into twelve simple words. That's exactly what a seed phrase does. It's like having a magical incantation that can recreate your entire digital presence if everything else is lost. Store it somewhere fireproof, waterproof, and definitely not in a text file labeled "crypto stuff."

The National Currency (SOL)

Every nation has its currency, but SOL is no ordinary money. Welcome to the economy of tomorrow, where currency transcends simple transactions to become the lifeblood of an entire digital ecosystem.

Think of SOL as a Swiss Army knife of finance - a tool that transforms based on how you use it.

When you're shopping in the digital bazaars of Solana, SOL works just like traditional money - a medium of exchange for buying NFTs, trading tokens, or investing in new projects. But that's just its most basic function.

Need to run a program or execute a smart contract? SOL becomes your computing currency. It's like paying for electricity or water in the physical world - a necessary resource that powers the nation's infrastructure. Each transaction, each program execution, requires a tiny amount of SOL, ensuring the network stays efficient and spam-free.

SOL's most fascinating role might be in governance.

Through staking, your SOL becomes like a government bond and voting right rolled into one. By staking your tokens, you're not just earning returns - you're helping secure the network and having a say in its future.

And then there's rent - a unique concept in the Solana nation. Just as you pay rent for physical storage, accounts on Solana require SOL to maintain their space on the blockchain. It's like paying for your digital real estate, ensuring efficient use of network resources.

Think of it this way: If the Solana network is a thriving digital city, SOL isn't just its currency - it's the fuel that keeps its engines running, the votes that guide its future, and the resource that maintains its infrastructure. In this digital nation, your SOL is your stake in the entire ecosystem.

Residency Papers (Account Creation)

In Solana, establishing residency means creating accounts. Unlike traditional countries where you might have one residency permit, Solana citizens often maintain multiple accounts:

Base Account: Your primary residence
Program-Derived Accounts (PDAs): Government-assigned addresses for specific purposes
Token Accounts: Like having different bank accounts for different currencies

The Government Structure (Built-in Programs)

Every nation needs its core government services. In Solana, these come in the form of built-in programs. Unlike others, Solana's bureaucracy runs with algorithmic precision. Imagine a government where every department operates 24/7, processes requests in milliseconds, and never makes you wait in line. Welcome to Solana's built-in programs.

The Department of Treasury (System Program)

At the heart of our digital nation sits the System Program - think of it as a combination of the Treasury Department and the Department of Interior. It's the bedrock institution that:

Handles the fundamentals of citizenship
Creates new accounts with mathematical precision
Manages the flow of SOL throughout the ecosystem
Ensures every transaction follows the rules
Maintains the very infrastructure that makes our digital nation possible

The Central Bank (Token Program)

Down the street from the Treasury, you'll find our version of the Federal Reserve - the Token Program. But unlike traditional central banks, this one can:

Mint new types of currencies (tokens) with just a few lines of code
Process thousands of transfers per second without breaking a sweat
Maintain perfect records of every token ever created or moved

// A glimpse at how our Central Bank operates:
TokenProgram.transfer(
    fromAccount,
    toAccount,
    amount,
)

The Department of State (Associated Token Program)

Think of this as our foreign relations office, but with a twist. The Associated Token Program standardizes how citizens interact with different types of tokens. It's like having a universal translator for digital assets. It creates predictable addresses for token accounts and makes sure your assets are always exactly where you expect them to be.

The Electoral Commission (Stake Program)

Finally, we have our unique take on democratic participation. The Stake Program manages the network's security through economic incentives:

🗳️ Citizens can stake their SOL to become active participants in network security
💼 Validators are chosen based on their stake, ensuring skin in the game
🔒 The whole system runs automatically, with rewards and slashing happening in real-time

The National Infrastructure & Constitution

Picture a vast metropolis stretching across digital space. But unlike any city you've known, this one runs on pure mathematics and consensus. At its heart beats a revolutionary innovation: Solana's Proof of History (PoH).

The Cities (Nodes)

If Solana is a country, its nodes are its cities – bustling hubs of activity that never sleep. In these digital metropolises:

• Validator nodes stand like gleaming skyscrapers, processing thousands of transactions per second. Each one is a combination courthouse and record office, validating transactions and maintaining the official ledger.

• Between them, RPC nodes act as neighborhood information kiosks, helping regular citizens like us interact with the network. They're the friendly faces of our digital bureaucracy.

The Universal Clock (Proof of History)

What truly sets Solana apart is its revolutionary traffic system. Imagine trying to coordinate a global flash mob without being able to agree on what time it is. That's the problem most blockchains face. Solana solved this with an ingenious solution: a blockchain with its own built-in clock.

Think of PoH as a cosmic metronome:

// Every event gets its own timestamp
event1 -> hash -> event2 -> hash -> event3
// Creating a verifiable sequence of time

The Results? They're staggering:

400 millisecond block times
Up to 65,000 transactions per second
A throughput that would make an NYSE trader's head spin

The Constitution (Consensus)

But a fast clock alone isn't enough – you need everyone to agree on the rules. That's where Solana's consensus mechanism comes in. It's like having:

🏛️ A supreme court that rules on transactions in milliseconds
🤝 A system where everyone agrees on "what happened when"
⚡ The speed of dictatorship with the fairness of democracy

Citizens and Their Laws (Accounts & Smart Contracts)

In our digital nation, citizenship takes on fascinating new forms. Every account is both a citizen and a piece of property, each with its own unique rights and capabilities.

The Citizens (Accounts)

Walk down any street in Solana, and you'll meet three types of digital citizens:

Program Accounts
Data Accounts
Native Accounts

Let's take a brief overview:

Program Accounts - Our civil servants, tirelessly executing code 24/7. Unlike human bureaucrats, they never take coffee breaks or call in sick. Each one contains executable code that follows its instructions with perfect precision.
Data Accounts - Think of these as the homes and businesses of our digital nation. They store everything from personal balances to complex financial instruments. Like real estate in the physical world, they require rent to maintain their space on the blockchain.
Native Accounts - The special institutions that keep our nation running, like the SOL mint. They're built into the very fabric of Solana, as fundamental as a country's central bank or supreme court.

The Laws (Smart Contracts)

Here's where things actually get really interesting.

Unlike traditional contracts that require courts and lawyers to enforce, smart contracts are self-executing pieces of code. It's like having:

Traffic laws that make it physically impossible to speed
Business agreements that settle instantly without dispute
Property transfers that complete the moment conditions are met

// Laws that enforce themselves
class TokenContract {
    transfer(from: Account, to: Account, amount: number) {
        if (from.balance >= amount) {
            // Transfer happens automatically
            // No lawyers needed
            // No courts required
        }
    }
}

When Alice sends Bob 5 SOL, there's no bank to approve the transfer, no clearing house to process it, and no way for the transaction to fail if Alice has the funds. The code simply... executes.

The real magic is in what this enables. These self-enforcing laws create an environment where:

Trust is built into the mathematics
Agreements execute with computer precision
Innovation can flourish without bureaucratic overhead

Local Customs & Public Works (Programming & Runtime)

Every nation develops its own way of doing things, its own customs and practices that make it unique. In Solana, this manifests in both its programming culture and its public infrastructure.

The Local Languages

While Rust remains the "official language" of Solana - like Mandarin in China - our digital nation has become increasingly polyglot. Through tools like Poseidon, developers can now write smart contracts in familiar TypeScript:

// Modern Solana development
export default class MyContract {
    initialize(state: State, owner: Signer) {
        // Write code as naturally as breathing
    }
}

Think of it as having universal translators - write in the language you know best, and Poseidon translates it into high-performance Rust code that Solana understands natively.

The Public Infrastructure

But a nation needs more than just languages - it needs robust infrastructure. Solana's runtime is built like a city's utility system, but with some crucial differences:

The Transit System

Imagine a subway that:

Never stops running (400ms block times)
Gets faster as more people use it (parallel processing)
Automatically routes around congestion (Gulf Stream)

// Every transaction flows through optimized channels
transaction -> mempool -> validator -> block

The Utility Grid

Just as cities charge for electricity and water, Solana has its own utility model:

🏠 Rent - Pay for the space your accounts occupy
💡 Compute Units - Like electricity for your programs
🌊 Memory - A flowing river of temporary storage

Here's the clever part: Just as you can prepay your utilities, Solana allows for "rent exemption" - a one-time payment that maintains your account forever. It's like buying your piece of the blockchain outright.

International Relations (Cross-Chain Communication)

Just as no modern nation exists in isolation, Solana maintains a vibrant network of diplomatic relations with other blockchain ecosystems. These relationships are facilitated through a sophisticated infrastructure of bridges and protocols, each serving a unique purpose in the grand scheme of cross-chain communication.

Embassies and Consulates (Bridges)

Imagine Wormhole as the main international airport of Solana, a bustling hub where assets and data from other chains arrive and depart in a constant flow. It's a portal through which the citizens of Solana can access the wider multiverse of blockchain technologies, and through which denizens of other chains can experience the speed and efficiency of Solana.

If Wormhole is the airport, then Portal Bridge is the secure customs checkpoint. It ensures that all incoming assets and data are scrutinized and verified, maintaining the integrity and security of Solana's native environment. Like a vigilant border guard, Portal Bridge stands watch over the flow of cross-chain traffic.

For those who prefer a more grounded mode of transport, Allbridge serves as Solana's international rail system. It provides a stable, reliable connection to other chains, facilitating the steady flow of assets and information across blockchain borders.

Trade Agreements (Protocols)

However, infrastructure alone does not make for successful international relations. Just as nations forge trade agreements and treaties, Solana engages in a variety of protocols to facilitate cross-chain interaction.

These include mechanisms for cross-chain asset transfers, allowing the seamless movement of tokens and NFTs between Solana and its blockchain neighbours.

Moreover, Solana participates in protocols for international data communication, ensuring that important information can be shared securely and efficiently across chain boundaries. In the spirit of global cooperation, Solana also engages in collaborative security measures, working with other chains to maintain the safety and integrity of the broader blockchain ecosystem.

The Economic Zones (DeFi and dApps)

Every thriving nation needs a robust economy. Welcome to the bustling marketplace of the future! If Solana is a digital nation, then its DeFi protocols and dApps are the vibrant bazaars and gleaming shopping districts where the real action happens.

Down Protocol Plaza... Stroll past Raydium's bustling trading floors, where millions in digital assets change hands every hour. Next door, Marinade Finance's validators work their magic, turning staked SOL into liquid assets faster than a barista makes your morning coffee.

In the Lending District:

Solend's smart contracts stand like modern banks but without the marble columns and stuffy loan officers
Port Finance offers sophisticated financial instruments that would make Wall Street jealous
And Oxygen Protocol runs its automated market maker with the precision of a Swiss watch

The Digital Arts District

Picture galleries floating in digital space, where art, music, and culture blend seamlessly with commerce. Here's what you might see on any given day:

🎨 Magic Eden's sprawling marketplace: Where digital artists showcase their latest creations And collectors bid in real-time auctions
🎮 Star Atlas's massive gaming complex: Thousands of players piloting virtual spaceships Building entire economies in the digital void

Social Squares

And then there's the social heart of our digital city - platforms where communities gather, share, and create together:

• Squads Protocol hosting decentralized team workspaces
• Dialect enabling real-time messaging between wallets
• GenesysGo provides the infrastructure that keeps it all connected

Emergency Services (Security Features)

Every nation needs to protect its citizens. Ever wondered what keeps a digital nation safe? While there are no police cars with flashing lights in Solana, its security system is far more sophisticated - and never sleeps.

The Digital Defense Force

Picture a security system that combines the best of Fort Knox's physical security with the precision of a quantum computer. Solana's validators stand guard 24/7, each one running sophisticated algorithms that would make a cryptographer's head spin.

Critical Security Checkpoints:

// Every transaction must pass through multiple layers of verification
transaction
    .verify_signatures()       // Like checking multiple forms of ID
    .verify_account_keys()     // Making sure you are who you say you are
    .verify_program_access()   // Confirming you have proper clearance

Your Personal Security Detail:

Multi-signature capabilities act like having multiple keys to a vault
Program authorization ensures that only approved code runs
Account permissions let you control exactly who can do what

The Safety Net System

Like any well-designed infrastructure, Solana has built-in circuit breakers and recovery systems. When issues arise, multiple systems spring into action:

a) Error Logging

Detailed Transaction Traces: Pinpoint problem sources.
Enable Quick Fixes: Facilitate efficient debugging.

b) Recovery Protocols

Automatic State Rollbacks: Maintain consistency during failures.
Transaction Retry Mechanisms: Ensure operation continuity.
Graceful Error Handling: Minimize disruption and improve user experience.

Think of it as having both airbags and seat belts - multiple layers of protection working together to keep your digital assets safe.

You've just completed your orientation tour

From Solana's high-speed highways of transactions to its secure vaults of digital assets. But like any new citizen, your journey is just beginning.

Picture yourself standing at the edge of a digital frontier. Behind you lies the familiar territory of traditional development. Ahead stretches an endless landscape of possibility, where smart contracts dance with decentralized applications, and every new block brings fresh opportunities.

What's Next On Your Journey?

In our next guide, we'll roll up our sleeves and build something real. No more metaphors about digital countries - we're going to write actual code. Think of it as your first business venture in this new land, starting with a simple but powerful smart contract.

// A peek at what we'll build:
export default class MyFirstContract {
    static PROGRAM_ID = new Pubkey("...")

    initialize(state: ContractState, owner: Signer): Result {
        // Your first steps into Solana development
    }
}

Remember: Every master builder in Solana started exactly where you are now. They were once a tourist in a new technology. The key isn't to understand everything at once, I didn't – Still don't. But you must keep building, one block at a time - That's how you get better.

Until our next meeting, keep exploring. Ask questions in the Solana Discord. Try out different wallets. Maybe even deploy your first test program. Because in this digital nation, curiosity isn't just welcomed - it's the currency of innovation.

See you on-chain! 🚀

Web3 explained for Web2 Developers: My Personal Journey from SQL to Solana

danielAsaboro — Fri, 13 Dec 2024 17:24:30 +0000

I used to roll my eyes at blockchain. Really, I did. Every time someone mentioned "crypto" or "Web3," I'd mentally file it away in my "crypto-bro hype" folder and move on. But something strange happened during my late-night coding sessions this September.

You know those moments when curiosity gets the better of you? Maybe it was the third cup of coffee, boredom, or perhaps it was watching one too many of my respected peers dive into this space. Whatever it was, I decided to peek under the hood. Just a quick look, I told myself. Three months later, I found myself excitedly whiteboarding blockchain concepts for my bewildered team members at 11 PM.

These lessons have been invaluable in solidifying my understanding, and now I want to share this knowledge with you. This article is my attempt to do so.

Let me start this story where we're all comfortable...

Understanding Blockchain Through Familiar Territory

Every developer's story starts with databases. Remember your first SELECT * FROM users? That moment when everything clicked and databases suddenly made sense? Or perhaps you're like me, and it was MongoDB's findOne() that made you fall in love with data storage.

We all have our go-to systems—PostgreSQL, MariaDB, Cassandra—trusted companions that never let us down when it comes to storing, retrieving, and updating data. They're reliable, efficient, and feel like old friends.

Here's the intriguing part: these traditional databases, as familiar as they are, represent just one way to think about data—how we store it, how we access it, and what we do with it. Blockchains aren't in any way different, they just approach data in a way that challenges conventional thinking.

That's when my perspective started to expand, and the possibilities became endless.

The Problem with Traditional Storage

Do you know what really got me thinking? I kept running into the same wall with different projects, each time thinking "There has to be a better way."

First, it was a voting system I tried building for a local organization. PostgreSQL, robust authentication, audit logs - the works. But when the client asked, "How can voters be absolutely certain their votes weren't changed after the fact?" I sat there, coffee getting cold, realizing that "just trust our admin team" wasn't going to cut it.

Despite all our security measures, there was always this uncomfortable truth: someone with database access could technically alter the votes. No amount of authentication or audit logs could completely eliminate that risk.

Take my friend's recent project

It's a digital collectibles marketplace built on MongoDB.

Sounds straightforward, right? But when users started asking questions like "How do I know you won't duplicate my rare items?" or "What happens to my assets if your company goes under?", the limitations became painfully obvious. Every answer started with "You'll have to trust that we..."

And then there were the practical headaches:

Need to prove a record hasn't been modified? Better build a complex audit system.
Want to let users verify their own data? Hope you enjoy maintaining API documentation.
Trying to create a truly peer-to-peer system? Good luck with those distributed database headaches.
How do you respond to "What happens to my assets if your company goes under"? "How can I prove I own the original if you control the database?"

Even a seemingly simple loyalty points system for a chain of restaurants exposed these limitations. Customers wanted to trade points with each other, but preventing double-spending without a central authority? That's when I started seeing these trust issues everywhere.

Every answer began with that same uncomfortable phrase: "You'll have to trust that we..." Every "secure" system I'd built was secure only because someone - an admin, a company, a cloud provider - said it was. And in most cases, that was fine. But what about when it wasn't?

That's when Bitcoin's whitepaper started making a whole lot more sense...

I still remember the exact moment Bitcoin clicked for me. It wasn't about cryptocurrency at all - it was about something far more profound. Picture this: It's 2008, and someone using the pseudonym Satoshi Nakamoto asks what seems like an impossible question: "What if we could create a database that nobody owns, but everyone can trust?"

At first, I thought, "Yeah, right. Good luck with that." But then I dug deeper, and that's when its elegance hit me. Think about what happens when you send money through your bank. You're trusting them to:

Make sure you actually have the money
Take it from your account
Put it in someone else's account
Not mess up anywhere along the way

Now, imagine doing all that without the bank. Sounds impossible, right? That's exactly what made Bitcoin brilliant. Instead of one bank checking the books, you've got thousands of computers worldwide all verifying transactions together. It's like having an entire stadium of accountants checking your math - try sneaking a bogus transaction past that!

But here's what really made me sit up at 2 AM, spilling my coffee: Bitcoin solved the "double-spend" problem. In plain English, it made it impossible to use the same digital money twice. That might not sound impressive until you realize no one had ever figured out how to do that without a central authority watching everything.

The Ethereum Plot Twist

Just when I thought I understood blockchain, Ethereum showed up and flipped my world again. See, Bitcoin was like a really good calculator - fantastic at one thing (moving money), but that was about it. Ethereum? That was like going from a calculator to a smartphone.

The Smart Contract Revolution

Here's what blew my mind about Ethereum: imagine writing code that, once deployed, runs exactly as written. No servers to crash. No admins to pull the plug. No company that could go bankrupt and take your service down. Coming from traditional backend development, this concept hit me like a ton of bricks.

These "smart contracts" (terrible name, by the way - they're neither smart nor contracts) are like backend code with superpowers. Every time I deploy a regular API, there's this nagging thought: "What if AWS goes down? What if someone hacks the server? What if the database corrupts?" But with Ethereum's smart contracts? Once they're out there, they just... run. Forever. Exactly as written.

But there was a catch (isn't there always?). Ethereum was like trying to run a modern app on a calculator - slow and expensive. Imagine paying $50 in gas fees just to store a tweet-sized piece of data. That's when Solana entered the chat.

The Solana Speed Demon

Picture this: I'm sitting there, frustrated with Ethereum's molasses-like 15 transactions per second, when I discover Solana. At first, I thought the numbers were a typo. Thousands of transactions per second? At fractions of a penny? It was like watching the first SSD after years of working with hard drives.

Solana brought something called Proof of History (PoH) to the table.

Think of it as a blockchain with a built-in clock. Instead of all the computers having to constantly agree on what time it is (which is what slows down other blockchains), Solana's nodes can just get on with their work. It's elegant. It's fast. And most importantly, it actually makes sense for real-world applications.

Why This Matters for Developers

You know what's funny? After all the technical deep dives, my biggest revelation was almost embarrassingly simple: the blockchain is just a database with attitude. We're not learning entirely new concepts - we're just looking at data storage through a different lens.

Think about it:

Instead of SELECT queries, we have read operations anyone can perform
Instead of INSERT statements, we have transactions that get verified by the network
Instead of database administrators, we have consensus mechanisms
Instead of access control lists, we have cryptographic signatures

The beauty of blockchain isn't in its complexity – it's in its simplicity. It's just a different type of database with unique properties: no central authority needed, impossible to tamper with data, code runs exactly as written, and anyone can verify what's happening.

You already know how to code. You already understand databases. Blockchain is just the next step in that evolution – a database that belongs to everyone and no one at the same time.

Here's what really got me excited:

TypeScript.

Yes, you read that right. Not Solidity, not Rust, but good old TypeScript. Thanks to a framework called Poseidon (a collaboration between Solana Foundation and Turbine), we can bring everything we love about Web2 development - type safety, familiar syntax, awesome tooling - into the Web3 world.

The Future is Closer Than You Think

I'll be honest - three months ago, if you'd told me I'd be building blockchain applications in TypeScript, I would've laughed. But here I am, excited to share this journey with you. In the upcoming series, we'll dive into:

Setting up a Solana development environment (it's easier than you think)
Writing our first smart contract (in TypeScript!)
Understanding Solana's programming model (it's actually quite elegant)
Building real-world applications (yes, actually useful ones)

You don't need to be a cryptography expert. You don't need to understand every detail of consensus mechanisms. You just need to be curious and willing to look at problems differently.

I hope this series of articles will help you realize that understanding blockchain isn't about learning entirely new concepts—it's about applying what we already know in a new context. So, it doesn't matter if you're a seasoned SQL developer or NoSQL enthusiast—your skills are transferable, and the journey to Web3 is shorter than you think.

Remember: every senior developer you know was once a beginner at something. Three months ago, I was rolling my eyes at Web3. Now? I can't wait to show you what's possible.

StateNotifierProvider: How to link your stateNotifier to your UI Widgets

danielAsaboro — Fri, 10 Nov 2023 06:41:04 +0000

In the previous post, we created our custom StateNotifier class by extending the StateNotifier class. However, the state changes weren't in any way linked to our Widgets/UI code.

I also hinted that it's the job of a special type of Provider (the StateNotifierProvider) to do that linking for us. It's similar to how a FutureProvider or StreamProvider links the result of a Future or Stream to the UI.

In summary:

• Future => FutureProvider
• Stream => StreamProvider
• StateNotifier => StateNotifierProvider

That cleared, let's see how to do it.

1. Create a StateNotifierProvider




final cartProvider = StateNotifierProvider<CartNotifier, Cart>((ref) {
  return CartNotifier();
});

That looks like a mouthful.

So let's break it down.

StateNotifierProvider is a class or type provided by Riverpod that allows you to create a provider for managing the application state. It requires two generic type parameters:

The user-defined StateNotifier type created by extending StateNotifier
The State type that the Provider will hold.

In our case, it's <CartNotifier, Cart>.

In addition to what was said earlier, the CartNotifier is also responsible for managing the provider's state. While the Cart represents the data structure that the CartNotifier will manage.

StateNotifierProvider is an anonymous function




StateNotifierProvider((ref) { return CartNotifier(); });

It takes a reference to ref as a parameter, which is used to access other providers or perform side effects within the provider initialization.

Then it creates an instance of the CartNotifier class, which we already said is responsible for managing the provider's state. You can also call a StateNotifierProvider a Constructor Function (a special function that creates and initializes an object instance of a class) for this reason.

In summary


 dart

final cartProvider = StateNotifierProvider<CartNotifier, Cart>((ref) {
  return CartNotifier();
});

The block of code above creates a Riverpod provider named cartProvider that uses a CartNotifier to manage the state of type Cart.

When you access cartProvider in your code, it will provide the current state of Cart managed by the CartNotifier.

2. Use ref.watch() to read and continuously listen to the state Changes in your UI




// Preceding code body removed for brevity

class EachProductWidget extends ConsumerWidget {
  final Product product;
  final int index;

  const EachProductWidget({
    super.key,
    required this.product,
    required this.index,
  });
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return Card(
       // The UI code to display each product as a Card
       // UI code removed for brevity and clarity.
    );
  }
}

class ProductListView extends ConsumerWidget {
  const ProductListView({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final cart = ref.watch(cartProvider);
    return Scaffold(
      body: Container(
        height: 600,
         // UI/Widget Code goes here
        // It contains a listview builder
       // iterating through the list...
      // of provided products;
      ),
    );
  }
}

It's that simple.

Use ref.read() to call the modification methods




// surrounding code removed for brevity
    IconButton(
                  icon: Icon(Icons.remove),
                  onPressed: () {
                    ref
                        .read(cartProvider.notifier)
                        .decreaseQuantityAtIndex(index);
                  },
                ),

While we could use ref.watch and it would work, ref.read is the better candidate for calling the state modification methods because it reads the provider once but without listening to state changes.

This ensures we never run into race conditions.

You will observe that we are not reading the provider, but the "notifier" method on it. This is because that's the only to access the modification method on a provider.

Reading the provider alone won't expose those methods

If you forget anything, don't forget this:

• Use ref.watch in Build Methods, and
• use ref.read in Callbacks;

No need to call SetState or notifyListeners — Riverpod does that automatically for you.

If you are confused with the whole thing...

Remember that converting Futures, Streams, and Simple Objects into their respective Providers is a one-step, simple process. That's because they don't have methods acting on them.

The case is different with Complex Objects which also have methods acting on them. This is why we first wrap it in a StateNotifier before converting it into its respective Provider;

Still confused? Reach out to me on Twitter;

Todo Challenge

We've achieved a lot at this point in our state Management journey.

We learnt how to Create, Read, Update, and Delete data that influences our app's state. We learnt how to make our widgets respond to user input and cause changes on another widget without relying on callbacks.

It's been a job well done.

However, our simple cart service isn't entirely complete yet. There are a few loose ends that need to be tied up. So, I'm leaving you with five final challenges:

Complete the implementation of the addToCart method.
Make the Wishlist icon respond to the isWishlisted field.
Create a method for decreasing the item count in the cart.
Create a method to delete a product from the Cart completely.
Provide a warning to the user when they attempt to decrease the item count when it's already at count 1.

Tweet at me with your solutions @AsaboroD

StateNotifier, ChangeNotifier — Why, When, and How to use them.

danielAsaboro — Fri, 10 Nov 2023 06:39:12 +0000

StateProvider becomes unnecessarily challenging when you need to perform operations more complex than the basic counter increment and decrement example that we are commonly used to in Flutter.

In fact, it will fail when it comes to executing asynchronous operations or data transformations which involves applying conditional logic to a List Of Products in a Cart like in a Checkout Page.

And that's because it's just not suited for that specific purpose.

In cases where you are somehow able to manoeuvre your way through, your app's business logic will be littered all around the UI. This lack of clear separation of concerns can quickly lead to a tangled and hard-to-maintain codebase – a sure recipe for disaster in any sizable project.

Thankfully, there's a better Alternative...

Class Variant Providers.

All the Providers we discussed in the previous episode (Provider, FutureProvider, StreamProvider, and StateProvider) are called Function variant Providers because they are basically all functions.

Like functional programming, that comes with an implication:

Disorganization,
Little to no encapsulation,
Near-zero reusability,
No form of modularity etc...

Making maintainability and Testing very difficult.

OOP, on the other hand, lets you bundle data and methods that operate on it within a class. This makes documentation, debugging, and collaboration easy peasy.

The same Principle applies to Class Variants Providers

Class variants let you encapsulate the state and the logic for handling and providing data in a class. There are two ways of doing that in RiverPod:

StateNotifier and
ChangeNotifier

But I see ChangeNotifier as an Impostor

Its use is heavily discouraged because it allows mutable states. Mutable States have been historically known to be susceptible to subtle bugs, race conditions, and synchronization overhead.

While ChangeNotifier is heavily relied upon in Provider, it's only added in Riverpod to make the transition from Provider to Riverpod easy. So we will not talk about it beyond that.

As a result, StateNotifier will be this piece's focus.

StateNotifier: What is it?

StateNotifier is a simple solution to control state in an immutable manner". It's native to Flutter. And RiverPod only re-exports (not that you should care).

Alright, enough of the pedantic details.
Nothing beats seeing it in action.

StateNotifier In Action

Say you are tasked with building the Cart Page Features of an E-commerce app. Below are some of the required useful functionalities...

Ability to:

Flat-out delete an Item(s).
Mark an Item as a Wish and Move to the WishList
Increase or Decrease the quantity of an Item on the list
Recalculate the total price after each change.

Can you implement all of this with a StateProvider?

If yes, please link to your code In the comment section :)

While you are it, let's see how with a StateNotifier in 7 simple steps.

Step 1: Define what makes a Product




class Product {
  final int id;
  final String name;
  final double price;
  final int quantity;
  final bool isWishlisted;

  Product({
    required this.id,
    required this.name,
    required this.price,
    this.quantity = 1,
    this.isWishlisted = false,
  });

  @override
  String toString() {
    return 'Product{id: $id, name: $name, price: $price, quantity: $quantity, isWishlisted: $isWishlisted}';
  }
}

You notice how all fields are marked final...?

This makes the class immutable which is a good thing as it becomes easier to compare the previous and the new state to check whether they are equal, implement an undo-redo mechanism, and debug the application state.

Step 2: Define what a Cart Entails




//... preceding code removed for brevity

class Cart {

  final List<Product> _productList;

  Cart({required this.productList}) : _productList = productList;

  double get totalPrice {
    //TODO
  }

  List<Product> get productList => _productList;

  Cart copyWith({List<Product>? productList}) {
    return Cart(
      productList: productList ?? _productList,
    );
  }
}

Step 3: Now, create a StateNotifer class that notifies the Provider for every state Change in the enclosed class.

You do this by extending the StateNotifier class and passing the Class you want to track its changes as a parameter to the StateNotifier class type.




class CartNotifier extends StateNotifier<Cart> {
  CartNotifier() : super((Cart(productList: [])));
}

If that looks confusing, let's break it down:

If you take a glimpse at the source code, you will find out that a StateNotifier is an abstract class which means it can't be instantiated but it can be extended.


 dart

abstract class StateNotifier<T> {
// class definition goes here
}

You will also notice that it's a Generic class of type T (StateNotifier), which means you can pass whatever class you like to its type parameter.

When you do that, the resulting StateNotifier class will Notify others of every state changed in the pass Class type.

Said differently, your type T is the class you want to convert into a StateNotifier Class, and your classNotifier Class is the resulting combination after the operation.

Moving on...

What you see in the Super function call is just me calling the constructor of the SuperClass that was extended. This is what we've been doing all our lives when we create a Stateless or Stateful Widget.



class HomePageScreen extends StatelessWidget {

  const HomePageScreen({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }
}

Step 4: Add your state modification methods to the StateNotifier class




//All previous package imports apply but are removed for brevity

class CartNotifier extends StateNotifier<Cart> {
  CartNotifier()
      : super((Cart(productList: <Product>[])));

  void addToCart() {
  //TODO
  }

  void removeThisElementFromCart() {
    //TODO
  }

  void increaseQuantityAtIndex() {
    //TODO
  }

  void decreaseQuantityAtIndex() {
    //TODO
  }

  void toggleWishlist() {
     //TODO
  }
}

Do you see how each modification function returns nothing?
Their only job is to change state, nothing more.

I won't implement the addToCard method for two reasons: It will stretch the length of the tutorial and Two, which is the most important — it's a good take-home practice exercise.

Instead, we will implement the removeThisElementFromCart method. As a result, I will give you a list of Products to manipulate as a starting Point.



import 'package:flutter/material.dart';

import 'package:flutter_riverpod/flutter_riverpod.dart';

List<Product> productListPassed = [

  Product(

    id: 1,

    name: 'Product A',

    price: 19.99,

    quantity: 3,

    isWishlisted: true,

  ),

  Product(

    id: 2,

    name: 'Product B',

    price: 29.99,

    quantity: 5,

    isWishlisted: false,

  ),

  Product(

    id: 3,

    name: 'Product C',

    price: 9.99,

    quantity: 2,

    isWishlisted: true,

  ),

  // Add more products as needed

];

class CartNotifier extends StateNotifier<Cart> {

  CartNotifier()

      : super((Cart(productList: productListPassed)));

void addToCart() {

  //TODO

  }

void removeThisElementFromCart(int productIndex) {

    final productList = state.productList;

    productList.removeAt(productIndex);

    state = state.copyWith(productList: productList);

  }

}

Let's break down what just happened in the removeThisElementFromCart Method

we know how our Cart is basically a List of Products and to access each product, all we need to do is identify its index (which is what is passed to the function as a parameter)

In line 1 of the function body...

we extracted the current list of products in the state object and saved it to the "productList" variable.

The variable "state" is Riverpod's way of representing the current state of the Class passed to the StateNotifier Class which in our case is the Cart object.

As you can see in the following screenshot, it also gives you access to all the fields and methods available on the Cart Object

Line 2 is pretty straightforward

We removed the item at the passed index. YOu can read about the removeAt method here on Flutter Documentation website.

All it does is remove the item at the specified index from the list, reduce the length by one, and move other items down by one position.

And Finally...

In line 3, we reassign the state variables.

Internally, this triggers two actions.

It compares the previous state value with the current one,
It calls NotifyListeners() only when the values are not equal.

NotifyListeners is what informs all subscribed listeners to a state object of a change in value. But before it can do that, we need to link our StateNotifier class to our Widgets(UI Elements).

And the only way to do that is by using a Provider.

Since our StateNotifier is not just your typical object, we can't use a futureprovider, streamprovider, or Stateprovider. So we will need a special Provider to help us do that.

It's called the StateNotifierProvider and it will be the focus of our next lesson.

So many providers in RiverPod 😱😱 Which one should I use?

danielAsaboro — Sat, 21 Oct 2023 06:04:52 +0000

I hardly pay attention in my English class back in High School.

I thought I wouldn't need it.

After all, I would be majoring in Engineering. "Just focus on your Science-based subject", which I did, and thankfully, I got admitted to the most competitive school in my home country.

However, my time at the university taught me that I was wrong about my view of the English Language, so I struggled when writing Lab Reports and giving a Presentation on a Project. And it's been one of the sources of the biggest setback I've had in my career.

I've forgotten a lot of things from my time in High School, but one lesson stays stuck to date. And it is...

No two English words mean the exact same thing

It's something my English Teacher would say repeatedly when we do some fill-in-the-gap textbook exercises. In his words, "You can use some words interchangeably, but not in all situations".

I like to think of providers in Riverpod the same way.

No two providers have the exact same function

You can use them interchangeably, yes. But only in certain situations. So I will never understand people who talk about "8 types of providers doing the same work". All it screams to me is they don't understand the tool in the first place and don't want to spend time learning it.

What's worse though, is that most of these complaints originate from people who will never change to Riverpod even if you point a gun directly at their skull, partly for the dreaded fear of being a beginner again.

But you are different.

You know better. You know that the creator of Freezed, Flutter_hooks, and Provider definitely has more productive uses for their time than developing providers with overlapping functionality. And you want to learn and use it to design Functional mobile apps. So let's start the article proper!!!.

Each Provider explained

For easy understanding, I like to group all Providers into two classes:

Function Variants.
Class Variants.

In Function Variants, you define providers as functions.

These functions return the data you want to provide. You can use various types of providers, like StateProvider, FutureProvider, and StreamProvider. They are easy to set up and are great for simple use cases.

Function Variant:

Provider

StateProvider

FutureProvider

StreamProvider

So let's dive into each.

1. Provider

This is the simplest of them all.

It's what you would normally use to provide simple immutable objects( data that doesn't change) to multiple parts of your app.

Examples of this data are a Websocket connection, Database connection, or an Authenticated User Instance — basically, anything you'd want to represent as a singleton.

import 'package:flutter/material.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';

final nameProvider = Provider<String>((ref) {
  return "Daniel Asaboro";
});

class RandomPage extends StatelessWidget {
  const RandomPage({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Consumer(
          builder: (context, ref, child) {
            final name = ref.watch(nameProvider);

            return Text(name);  //Daniel Asaboro
          },
        ),
      ),
    );
  }
}

2. StateProvider

StateProvider is the next rung after the basic Provider.

It's a Provider that lets you store simple mutable objects so you can modify its state. However, it exists primarily for working with simple variables such as booleans, integers, and Strings.

import 'package:flutter/material.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';

final nameProvider = StateProvider<String>((ref) {
  return "";
});

class RandomPage extends ConsumerWidget {
  const RandomPage({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final name = ref.watch(nameProvider);
    return Scaffold(
      body: Center(
        child: Column(
          children: [
            Text(name),
            ElevatedButton(
              onPressed: () {
                // This will change the output in Text widget to "Daniel Asaboro"
                ref.read(nameProvider.notifier).state = "Daniel Asaboro";
              },
              child: Text("Change Name"),
            ),
          ],
        ),
      ),
    );
  }
}

Its use is heavily discouraged because it allows easy modification from anywhere and from any widget — don't too many cooks spoil the broth?

This is why it's only useful for maintaining local state i.e. state that doesn't need to be shared across the entire application e.g. Passing the Index of a selected item in a List to another function or Provider which we will talk about later in the series.

3. FutureProvider

FutureProvider is your guy when you need to supply values that are resolved asynchronously, such as API network calls or database queries. FutureProvider makes working with futures and async operations a work in the park.

import 'package:flutter/material.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';
import 'package:http/http.dart as http;
import 'dart:convert';

final nameProvider = FutureProvider<Map<String, dynamic>>((ref) async {
  final response =
      await http.get(Uri.parse('https://jsonplaceholder.typicode.com/users/5'));
  if (response.statusCode == 200) {
    return json.decode(response.body);
  } else {
    throw Exception('Failed to load data');
  }
});

class RandomPage extends ConsumerWidget {
  const RandomPage({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return ref.watch(nameProvider).when(
          data: (data) {
            return Scaffold(
              body: Center(
                child: Text(data["name"]), //"Chelsey Dietrich"
              ),
            );
          },
          error: ((error, stackTrace) {
            return Text("${error.toString()}, $stackTrace");
          }),
          loading: () => CircularProgressIndicator(),
        );
  }
}

4. StreamProvider

StreamProvider is used for providing values that come from a continuous stream of data like real-time stock market updates, football match live scores, or WebSocket events.

A common use-case for StreamProvider is providing stream data from a real-time database like Firestore. Some use it in chat applications, and some in Video-calls.

import 'dart:async';
import 'package:flutter/material.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';
import 'package:socket_io_client/socket_io_client.dart' as IO;

class SocketService {
  final String serverUrl = "http://your.socket.io.server.url";
  IO.Socket socket;

  // Stream controller for broadcasting live weather data
  StreamController<String> _weatherDataController = StreamController<String>();

  SocketService() {
    // Initialize the Socket.IO connection
    socket = IO.io(serverUrl, <String, dynamic>{
      'transports': ['websocket'],
      'autoConnect': true,
    });

    // Define an event to receive live weather data from the server
    socket.on('weatherData', (data) {
      // Add the data to the stream
      _weatherDataController.add(data);
    });
  }

  Stream<String> getLiveWeatherData() {
    return _weatherDataController.stream;
  }

  void dispose() {
    _weatherDataController.close();
    socket.disconnect();
  }
}

final socketProvider = Provider<SocketService>((ref) {
  return SocketService();
});

final socketStreamProvider = StreamProvider((ref) async* {
  final streamData = ref.watch(socketProvider).getLiveWeatherData();
  await for (final eachLiveData in streamData) {
    yield eachLiveData;
  }
});

class RandomPage extends ConsumerWidget {
  const RandomPage({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return ref.watch(socketStreamProvider).when(
          data: (data) {
            return Scaffold(
              body: Center(
                child: Text(data), //some string;
              ),
            );
          },
          error: ((error, stackTrace) {
            return Text("${error.toString()}, $stackTrace");
          }),
          loading: () => const CircularProgressIndicator(),
        );
  }
}

As you can see, it's quite similar to FutureProvider as they both deal with asynchronous data. And Riverpod gives us an easy way to handle all its possible states from Loading, to when it gets Data or Errors out;

We've come a long way

We've spoke about the four fundamental providers in Flutter: Provider, StateProvider, FutureProvider, and StreamProvider. While they've all proven to be invaluable tools in managing data, state, and asynchronous operations in your app easily, they do have certain limitations.

Most are read-only and only focus on data distribution.

What if you need more than that?

Say you need to retrieve a User biodata from the server, edit and update it, and then send it back to the server, that's a lot of operations — none of the Providers we've talked about can do that.

This is the gap Class variant Providers fill.

As its name implies, it lets you group related methods for working on a particular data together. It will be the focus of the next episode in this series. We will take a deep dive, and talk about why they are useful, when to use them, and how.

Till then...bye.

Explaining RiverPod like I'm 5 — From someone who finally got it!

danielAsaboro — Tue, 17 Oct 2023 04:26:34 +0000

The First Communication Satellite (Telstar 1) was launched in July 1962.

Thirteen days later, the first live broadcast of a television show between the United States and Europe took place. That evening, Telstar 1 also relayed the first satellite telephone call, between U.S. vice-president Lyndon Johnson and the chairman of AT&T, Frederick Kappel.

From then on, information that would normally take months to transmit took minutes. Insane jump in productivity, but it didn't happen overnight.

How Satellite Communication works

It works by relaying signals through orbiting satellites in low Earth orbit. It begins with a ground-based transmitter sending data or voice signals to a satellite dish pointed at the specific satellite in orbit.

The satellite then captures these signals, manipulates them, and then retransmits them back to a ground station in another location. This process allows for long-distance communication and is vital for services like television broadcasts, internet access, and even global navigation systems like GPS.

What has that to do with State Management? Or Riverpod? You ask

State Management Tools operate much like Satellites

They wrap around your app like orbiting satellites wrap around the Earth, and ensure that data flow is smooth, predictable, and efficient.

Riverpod is not in any way different.

This is why the number one prerequisite for using it in your app is wrapping the whole thing with the ProviderScope widget. Else, nothing would work.

JSYK, I failed at my short stint as a Graphic designer back in 2019. Saying that before you attack my skills 🙈☹️

Interestingly, that's also how the MaterialApp Widget works!

Once you wrap your app with the MaterialApp Widget, you will be able to access core features like Theming, Navigation, and most importantly, the BuildContext (a crucial object that provides a reference to a widget location within the widget tree, allowing them access information and resources from their surrounding environment and the overall app).

Else, nothing for you 💀

I remember the first time I picked up Flutter and forgot to wrap my text in a scaffold, see how bad it was...

Now imagine how bad it can get when you don't wrap MaterialApp...💀

In the same way that the MaterialApp has BuildContext, Riverpod ProviderScope also gives us a reference called WidgetRef.

The way I like to put it is MaterialApp provides the UI-related code while Riverpod provides the App's Logic-related code.

But there's a small tiny-bitty problem ☹️

While you can access BuildContext by simply wrapping your app in the MaterialApp Widget, you can't access the WidgetRef that easily. All you will get is red squiggly lines.

☹️

(Error: WidgetRef isn't a valid override of StatelessWidget Build)

While we could access the buildContext, the same can't be said for the WidgetRef even after importing Riverpod. Thankfully, the solution is easy. So let's dive into it.

Three ways to Access RiverPod WidgetRef

1. Using the Consumer Widget

Most people think this is the simplest way to use Riverpod WidgetRef in your app, but I don't. However, I think it's the most straightforward way apart from the boilerplate code, as it's what you are already used to.

Simply wrap a Consumer Widget around the widget that needs to react to state changes or some external dependencies.

And the code isn't that complicated.

Let's break it down:

The Consumer widget has a required field called the builder which is responsible for rebuilding the widget whenever the provider value changes.

It's very similar to the FutureBuilder, StreamBuilder, or the AnimationBuilder if you are familiar with it and it's a callback function that accepts 3 parameters:

context (type: BuildContext)
ref (type: WidgetRef)
child (type: Widget?) which means optional

The context is only passing the context from Material App to the builder much like you would do in a dialogue or Alert widget.

The only new parameter is the WidgetRef which gives the widget — you already guessed it — a reference for subsequent operations.

We will talk about the child parameter when we get to optimization. I work for startups and trust me, there are better things to do than spending 5 hours making an app 5 milliseconds faster. No wonder it's optional!

2. Extending the ConsumerWidget

Textbook definition says "The ConsumerWidget class is a subclass of StatelessWidget that provides built-in Riverpod integration".

Said simply, the ConsumerWidget inherits behaviour from a Stateless Widget, so it gets the BuildContext automatically, after which it adds the WidgetRef — thereby getting built-in Riverpod integration.

The added advantage is accessing your WidgetRef directly from the build method without needing to wrap the widget in a Consumer as shown earlier.

Note: This code has the same outcome as the example given in method one (wrapping with Consumer).

3. Extending the ConsumerStateful Widget

This is the Stateful version of the ConsumerWidget.

If you find yourself in a situation where you need to perform one-time actions such as fetching setup data or getting the user's location before rendering your page as you would normally do in an initState method, then this is the right approach for you.

As always, all three code have the same Output

Which one should I use?

Each has its use cases ranging from Readability, Performance, Verbosity etc And like everything in software development, a lot of Experts have their opinions about each. Not an expert, I just build. So I will leave finding out to you.

The general rule though, is to stick with ConsumerWidget until it's not enough. And that brings us to the end of this lesson. In the next, we will dive deep into the different types of Providers available in Riverpod, how and when to use them.

Bye.

Riverpod easily explained for those who don't get it

danielAsaboro — Mon, 16 Oct 2023 06:08:36 +0000

It takes only a few weeks of intense Fluttering before you quickly realize using callbacks to manage state and data flow across your app is a big pain in the ass.

Before you know it, your callbacks are 4 to 5 levels deep, changes reflect at a snail's pace, and you start struggling to recognize your codebase should you take any break. Oh, and heaven forbid you forget to call 'SetState' – that's when the real chaos begins.

I know — because I've been there. It's something you wouldn't wish upon your worst enemy. So I knew it was time to take that big leap in my Flutter learning journey once I saw the signs.

Picking a StateManagement tool

Thankfully, the choice was easy.

Unlike most people, I didn't get stuck deciding what to go with when considering the plethora of choices out there. I simply picked one and stuck with it since then.

But this couldn't be possible without people like Kiishi, Jide Guru, and Precious. They couldn't stop raving about Riverpod, and I'm immensely grateful that they didn't.

It wasn't an easy journey either

I started learning Flutter precisely on July 12.

I can never forget that day as it was a turning point in my life.

A friend who was meant to handle the mobile part of a project we both ideated on while I dealt with the backend suddenly ghosted after we had a few clashes.

We had applied for a Startup Grant I was very interested in and I couldn't pull out. I either make it work or die trying. And so my Flutter journey began.

I had a 3-month hard stop!

For the grant, you're given a choice: either have your MVP up and running within three months, or you won't receive any support. Given my tight schedule and limited time, I couldn't afford to waste a single moment; my sole focus was simple: Building — which I did.

Fast Forward to today, we already have a working MVP and we have two weeks left to squash bugs. And Riverpod has been quite helpful along the way. It was a breath of fresh air.

Sadly, many people find Riverpod so hard and complicated

They say it has so many options to choose from.

Even worse — "these options basically do the same thing", one said. The jargon can be overwhelming, from hooks to Freeze, generators, annotations, and whatever new buzzword pops up tomorrow.

And they are right.

But what they forget is that you don't need to use everything a package gives you to make a standard Mobile app. As someone rightly told me a time ago "you can get by using a relatively small subset of the features to cover the cases you’ll need".

That's precisely what I did.

So in the upcoming series of articles, I'm going to share my approach with you.

Don't worry; if I, someone who barely started learning how to write web programs just on April 14th, can grasp these concepts, I'm confident you can too.

I'll provide code examples, and snippets, and be completely transparent about the mistakes I made along the way. There will be no holding back, and we'll tackle Riverpod together.

No holdbacks. Promised!

Flutter

danielAsaboro — Sun, 13 Aug 2023 21:52:03 +0000

Flutter, Flutter, Flutter.

That's the post

From Novice to Ninja: How I moved from getting scared of Errors to throwing and handling them gracefully

danielAsaboro — Sun, 30 Jul 2023 13:47:02 +0000

Early on in my journey as a developer, I dreaded encountering bugs.

I thought I was alone. It's only now that I'm beginning to realize it's a common phase everyone goes through. Bug seem like obstacles that stood in the way of a perfectly functioning program.

Like intruders lurking in the darkest corners, they appear unexpectedly and wreak havoc on your well designed programming flow.

At first, I resented their existence.

The only thing I calculate after solving a bug is calculating how much of the time and effort I used in tracking them could have been converted into something productive like opening more PRs and adding more features to the product.

However, as I gained experience, my perspective began to shift.

But my perspective began to change one fateful day

A seemingly simple project I was working on began to throw inexplicable errors. No matter how much I tried to ignore them, they persisted, mocking my skills. Frustration boiled inside me, threatening to consume my enthusiasm for programming but I was broke and can't quit for how far i've come.

With no other choice, I decided to confront the bugs head-on.

Instead of dwelling on the problem's complexity, I focused on the process of debugging itself. It was then that I realized the true beauty of debugging – it forces us to scrutinize our code, line by line, examining every tiny detail.

In the process, I learned how to look at my code from different angles, identify potential pitfalls, and gained a profound understanding of the system's inner workings.

** One particular experience that stands out was an elusive bug that surfaced only during specific conditions. It haunted me for days, lurking in the shadows of my project. I felt an almost personal vendetta against this bug, and I couldn't rest until I uncovered its source. The countless hours invested in debugging eventually led me to a Eureka moment. Not only did I fix the problem, but I discovered an aspect of the system that I had previously overlooked. The satisfaction I derived from that breakthrough was unparalleled – it was akin to solving a complex puzzle or uncovering a hidden treasure.

***I recall a particularly perplexing bug that haunted me for days. It involved a seemingly innocent line of code that caused erratic behavior in a critical module. The more I dug into the issue, the deeper the rabbit hole seemed to go. Frustration mounted, and doubts crept in. But it was during this trial that I discovered the true beauty of bugs—they forced me to question my assumptions and delve into the intricacies of the system.

Before I hate errors, now I create and throw them.

Bugs give invaluable insights into the system, allowing us to understand its intricacies and grow as developers.

Embracing them has not only expanded my technical knowledge but also honed my problem-solving skills. Each bug comes with a unique set of challenges, pushing me to think creatively and consider alternative approaches.

It's like engaging in a sparring match with the system, where I learn from its maneuvers, and becoming a better developer with every encounter.

Moreover, resolving bugs has made me more empathetic towards fellow developers. We all share this rollercoaster of emotions – from the initial frustration to the exhilaration of triumph when a bug is squashed. It has created a sense of camaraderie within the development community, where we openly share our bug war stories and learn from one another's triumphs and defeats.

In a world that often emphasizes perfection and the pursuit of flawlessness, I urge fellow developers to embrace the bugs.

The journey of resolving a bug is akin to solving a challenging puzzle. Each piece of the puzzle brings us closer to unraveling the mystery, and with each solved bug, a profound sense of accomplishment washes over us. The euphoria that accompanies the successful eradication of a bug is unmatched—it fuels our passion and rejuvenates our spirit as developers. The satisfaction is not merely derived from making the system work flawlessly but also from the knowledge that we have honed our skills and grown as problem solvers.

Bugs, in their essence, are our greatest teachers. They expose the flaws in our logic, challenge our assumptions, and force us to think critically.

As we navigate the treacherous terrain of debugging, we acquire invaluable lessons that extend far beyond the realm of coding. Perseverance, resilience, attention to detail, and the ability to embrace failure as a stepping stone to success—all these qualities are nurtured through our encounters with bugs.

To comprehend the inner workings of a software system, one must embrace the bugs within it. Like detectives on a mission, we analyze stack traces, scrutinize log files, and reproduce the elusive errors in controlled environments.

As we chase after these tiny creatures, we uncover the complex interactions between different components, gaining a deeper understanding of the system's intricacies.

Instead of seeing them as merely annoyances or roadblocks, we should see them invaluable opportunities for growth and learning, catalysts for self-education, propelling us to become more proficient and knowledgeable developers.

Ever wonder how your favourite youtubers become so good? they spent so much time than you can fathom dealing with bugs. That's what you should start doing. So also am I.

I'm beginning to see Bugs as Friends instead Foes

As a software developer, I have learned to embrace bugs as companions on my journey, rather than adversaries to be feared
They have become an integral part of my growth and understanding of complex systems.

So, the next time you encounter a bug, instead of succumbing to frustration, try viewing it as an invitation to explore, to learn, and to experience the unparalleled satisfaction that comes from unraveling the intricacies of the system. Embrace the bugs and let them guide you toward becoming a more accomplished and fulfilled developer.

Bugs can be frustrating and feel like wasted time, but we shouldn't overlook the profound learning opportunities they present.

I'm not saying you should dive into them with enthusiasm, instead, i'm asking you to embrace them because they are the key to unlocking a deeper understanding of the system.

They are not signs of failure, but rather opportunities for growth.Bugs remind us that the pursuit of perfection is a never-ending journey, and the joy lies not in achieving it, but in the pursuit itself.

Bugs are how we gain understanding of the system. Embrace them!

I took a BIG Leap, but Backwards. Here's why and how it's panning out

danielAsaboro — Sun, 23 Jul 2023 06:15:26 +0000

Just before June ended, I got a message from my old-time friend.

The content was plain and small, but it was big enough to make me revisit the thousands of micro-decisions that compounded down to where I am today, what I'm doing, and for whom.

While I promised to revert, sadly, since then, I've not. This is my attempt to keep up to my word.

But first, a quick clarification

It's easy to connect the dots looking backwards, particularly if you are making progress, but the same can't be said in the reverse. So please note that it was a series of tough decisions down here, but I'm glad I made them.

I made my debut a long time ago

I got introduced to Programming my last year in High school — Think when Adobeflash and Actionscript were still a thing. Like most beginners, I wasn't fully immersed as I was doing it alongside other things.

This continued till my first year in the University.

Then I got introduced to MicroControllers and even competed at various competitions. There, I had to use C++ and learnt it to solve most of the difficulties I faced.

Simultaneously, I was also learning Html, CSS, Js, PHP, and MYSQL (the languages of the web then).

This was in 2017/18. Jquery was the trending library at that time. And suddenly, I stopped coding: C++, Microcontrollers, Web development — basically everything.

Then covid came out of nowhere!

By this time, it was like a year's break from everything programming. And funny enough, I'd dipped my hand in the Graphics world. You know the usual suspect: Photoshop, Illustrator, and a little bit of Lightroom.

But I got bored, and quickly.

For one, I could replicate most designs I saw since I knew the tools, where to find them, and what they could do — but I couldn't create a satisfactory design from scratch no matter how hard I tried.

Yes, I studied colour theory.

The wheel. The Psychology. I knew what analogous colours are, what complementary is, and what it means for a set of colours to be Triadic. But I couldn't compose them into something meaningful. Something beautiful. Or, thumb scrolling.

No matter how much I studied and tried, I just couldn't.

Perhaps, I'm not good with colours. In some way, it reflects in my clothing style to date. You'd hardly see me deviate from the Neutrals: white, black, brown and other shades in between.

Perhaps, I wasn't creative.

But I couldn't stay Idle, so I jumped into 3D.

At first, It felt exciting.

All I wanted to do then was translate everything around me into a 3D digital representation. But I slowly dropped out, albeit painfully (My PC couldn't handle the workload).

Then, for some reason, I dabbled into Marketing.

First, it was copywriting.

I studied the greats: Gary Halbert, Claude Hopkins, David Ogilvy, and Joe Sugarman. I read books like Tested Advertising Methods, Scientific Advertising, and Great Leads — not once, not twice, but over, and over again.

I picked interest in B2B saas (that was where the money was).

As a result, I learnt Content Marketing because I realized that relationships are everything in B2B. You have to "nurture" people with "value" so they are comfortable buying from you.

I did this actively for two years.

And in that period, I learnt about SEO, ABM, Customer Research and all that kind of Marketing Jazz. Overall, I improved my writing skills (I'd wrongly assumed I didn't need to be good at writing since I would be an Engineer).

Coincidentally, that was when I started realizing a few, fundamental, but painful truths about life. I will go over them briefly:

Don't do hard things

Down to the course I'm currently studying at the University, all my choices in the past were predicated on doing hard things.

I didn't need to like them. I just get satisfaction from completing them. But life is too short to spend time playing unnecessary games, you will only end up with unnecessary prices.

I learnt this lesson, painfully.

As you grow old, you will realize that society doesn't reward you for doing hard things. Instead, it rewards you for doing things it values but thinks are hard to get.

It's a subtle distinction but with profound implications

It reminds me of Naval's quote about society paying you for things it needs but didn't know how to get. It's what made Henry Ford, Rockefeller, and Elon Musk who they are in society.

They gave society what she needed and got paid for it. In my experience, solving problems at scale with software is one of them, but Marketing isn't.

I think Marketing is tougher than software development. The space of possible solutions to a problem was unlimited and nondeterministic unlike software, yet people value it widely less (the salaries show it)

Two, I was naturally a computer guy

There are several things I know without trying about computer systems that most people have to actively invest time, energy, and resources before they can.

It might feel like a brag, but it's the truth.

I was spoofing wifi since I was 13. Did your files got deleted from your USB disk? I could recover it in a few minutes. I was already using cmd to shut down a pc, get a wifi password, or **

Did your laptop start showing a blue screen error and wouldn't boot up properly? I could diagnose and fix the issue without resorting to professional help or spending unnecessary money on repairs and on and on.

When I talked at a young age about PCs then, people listened.

So you can imagine my shock getting into marketing, and two years down the line finding myself in a back-and-forth argument with people who don't have the slightest idea about marketing yet always want to give advice on it — it's uncommon in the software world.

I was getting dissatisfied internally as a result. So, I started looking into jumping ship. The opportunity came in February this year.

I volunteered for a small Political Party

It's February. My country was holding a presidential election. So I decided to volunteer for a small Political Party with a vision to restore hope, combat corruption, and bring positive change.

That short month was intensive for me, it set the foundation for my switching back to computer programming. For one, I got to see firsthand, how useful tech is, and the big impact it can make.

And two, one of the directors there saw my friend and me using our knowledge to help others, unblock them, and move our cause for being there- forward.

So along the line, he pitched an idea he was working on and asked if I would like to be a part of the developers on it. After a few deliberations, I jumped on that opportunity, the rest, they say? is history ...but that's the not the whole story...

I've been struggling to pickup software development since 2019

Year in, Year out, after a month or two, I'd always drop it. This time was different. I've stuck with it for over 3 months and counting. It's getting interesting with each day passing and I don't see myself stopping anytime soon.

How I did this is story for another day.

Id or UUID: Which one should you use as the primary key in your DB?

danielAsaboro — Fri, 14 Jul 2023 13:35:47 +0000

Carrying a successful attack on a highly-valued asset like the United States of America's President is pretty easy (and that's a big call) — but only if:

You know the exact place, time, and speed of the president's convoy
which of The Beast the President would be sitting in, and what he will be doing at that time.
the president's itinerary for the day, the security protocols in place, and his security team's usual habits etc

Okay, that's enough masterclass in terrorism 💀

What do all these shenanigans got to do with Web development and API Security, you ask? Well, it's pretty simple: A predictable system is inherently insecure.

This is why you are advised not to encrypt your user's password and instead asked to not just hash them, but also salt them.

So it wasn't a thing of surprise when I saw that using UUID instead of plain old sequential Ids was one of the things on Treblle API security Hackathon.

Just as a predictable system can be easily exploited in an attack on a public figure, a predictable system in the digital realm can be targeted by malicious actors — exposing sensitive information and jeopardizing the integrity of the entire system.

But there's a problem...

Implementing robust security measures to enhance the resilience of systems and reduces the risk of unauthorized access or exploitation doesn't come all rosy.

Let's take the use of UUID instead of plain sequential Id (ObjectId in MongoDb), for example. Yes, they have:

Universal Uniqueness.
Independence from central coordination.
Reduced risk of ID collision.
Flexibility and interoperability.
Future-proofing, scalability, and all the good stuff...

But at what cost?...

Is it their Sheer length?

They can be so long that they take up half of my database column or API payload. I'm just trying to store or transmit a simple identifier, but no, I have to deal with this monstrous string that seems to go on forever. It's not only inconvenient but also wastes valuable storage and network bandwidth.

Let's talk about Debugging

When an issue arises, and I need to dive into my database or logs to find the problematic record, I'm used to quickly identifying it based on its ID. But with UUIDs, I need to copy-paste that monstrosity and hope I don't make any mistakes. Good luck finding that needle in a haystack of cryptic strings.

On Performance

Generating a UUID takes significantly more computational resources compared to simply incrementing a sequential ID. So if I'm dealing with a high-throughput system or a massive number of records, the overhead of UUID generation starts to become a real bottleneck.

Oh, and don't even get me started on sorting or indexing UUIDs.

With sequential IDs, it's a breeze.

I can simply order them by their values, and voila!

But with UUIDs, it's like trying to solve a complex puzzle. I have to resort to weird sorting algorithms, convert them to binary representations, or split them into multiple columns just to make them somewhat sortable.

It's a nightmare for anyone who values simplicity and efficiency.

UUID have their benefits, but the tradeoffs are real.

But don't get me wrong!

Although predictability is an open invitation for attacks and the element of surprise can transform into stronghold — Not all scenarios require or benefit from complete unpredictability.

Remember, when it comes to human-facing interfaces, intuitive and memorable IDs are crucial for a good user experience.

Users should be able to easily identify and remember entities or items based on their IDs. This is especially important in applications where users need to reference or communicate about specific items frequently.

And most applications like E-commerce Platforms, CMS (Content Management Systems), and Data Analytics platforms have specific sorting and indexing needs.

There's no one-size-fits-all solution.

Your choice should be driven your application requirements, specific needs, and the trade-offs you are willing to take on.

Evaluate them.
Consider the benefits.
And Weigh the Limitations.

That's the only way to make an informed decision. And this is the goal of this article.

⚠️⚠️ A big Note ⚠️⚠️

Throughout history, attacks on public figures, including heads of state, have unfortunately occurred. It is important to note that discussing these incidents should not be seen as endorsing or promoting violence.