Feb 25, 2025

Alright, let’s get talk about the elephant in the room: Blockchain and specifically the stigma surrounding it. Why on earth would anyone want to bother learning about it? It’s a technology with no practicall use, filled with scams, and a lot of hype. But is that enough to stop you from learning? Let’s find out.

Why Learn About Solana?

First off, Solana is built by a team of really talented developers and it shows right now Solana is the fastest blockchainn network in the market with throughput of 65,000+ transactions per second. While Ethereum has a throughput of 15-30 transactions per second and that’s a really huge diffrence. Sll of that with no compromises in speed, security, or fees that’s a great technology in my book. and definitely worth learning.

But here’s the kicker: Solana uses Rust, so it’s a great execuse to use Rust for something serious for a change. If you’ve never touched Rust, don’t panic. In this blog post we will be using Anchor which simplifies stuff a lot. we don’t need to worry about the scary parts of Rust, and we’ll be able to focus on the cool kids do.

Solana Fundamentals: Web Dev Edition

Before we start building a todo app, let’s break down the core concepts of Solana in terms that’ll make sense to web developers. Think of this as your Rosetta Stone for translating web dev knowledge to blockchain.

Programs vs. Servers

In traditional web development, you have a server running somewhere that processes requests. On Solana, we have “programs” - immutable pieces of code deployed on the blockchain.

Think of a program like a serverless function that anyone can call, but no one (not even you) can change once it’s deployed. Each program has a unique address, kind of like a URL, but it looks more like this: Fg6HuIoDXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS.

Here’s what a simple Solana program structure looks like:

#[program]
pub mod my_program {
    use super::*;
    
    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        Ok(())
    }
    
    pub fn update_something(ctx: Context<UpdateSomething>, data: String) -> Result<()> {
        Ok(())
    }
}

Each function acts like an API endpoint, but we call them “instructions” in Solana-speak.

Accounts vs. Databases

Here’s where things get weird for web devs. In Solana, there’s no central database. Instead, we have “accounts” - chunks (buffers) of data stored on the blockchain that programs can read and write to.

An account:

  • Has an owner (a program that can modify it)
  • Has a fixed size (you pay for storage upfront)
  • Costs rent (yes, you pay for storage over time)

Instead of tables and collections, you define structures:

#[account]
pub struct TodoList {
    pub owner: Pubkey,     
    pub todo_count: u8,    
}

#[account]
pub struct TodoItem {
    pub completed: bool,
    pub content: String,
}

Transactions vs. API Calls

When you want to interact with your program, you don’t make API calls - you submit transactions to the Solana network. A transaction:

  • Can contain multiple instructions
  • Must be signed by the relevant parties
  • Is atomically processed (all succeed or all fail)
  • Costs a tiny fee (but really tiny - like $0.000001)

Program Derived Addresses (PDAs): Simplified

PDAs are like deterministic “database” records that your Solana program can control without needing a private key. Let me explain why they’re so powerful:

The HashMap Analogy

Think of PDAs like a global HashMap where:

  • The keys are cryptographically generated addresses
  • The values are your on-chain data
const todoStorage = {
  "user_xxx_todolist": { count: 5, owner: "xxx" },
  "user_xxx_todo_0": { content: "Buy milk", completed: false },
  "user_xxx_todo_1": { content: "Learn Solana", completed: true }
};

Why They’re Deterministic

PDAs are deterministic because:

  1. You provide consistent “seeds” (like a user ID + some label)
  2. Solana hashes these with your program ID
  3. It adds a small “bump” to ensure it’s a valid address
  4. Given the same inputs, you always get the same address
let [todo_list_pda, _] = Pubkey::find_program_address(
  &[b"todos", user_pubkey.as_ref()], 
  program_id
);

Why This Matters

  1. No Private Keys Needed: Your program can update data without managing private keys
  2. Predictable Addressing: Anyone can derive the same address with the same inputs
  3. Works Like Database Relationships: You can model one-to-many and many-to-many relationships
  4. Client-Program Alignment: Frontend and blockchain code derive the same addresses

PDAs are the key to organizing data on Solana - they’re how you create structured, queryable data in a blockchain environment that has no built-in database or indexing capabilities.

Building a Todo App: The Key Concepts

Let’s see how these concepts translate when building a todo app:

1. Defining Our Data Model

Instead of creating a MongoDB schema or SQL tables, we define account structures:

#[account]
pub struct TodoAccount {
    pub owner: Pubkey,      // the user who owns this list
    pub todo_count: u8,
}

#[account]
pub struct TodoItem {
    pub completed: bool,
    pub content: String,
    pub created_at: i64,
}

2. Creating Instructions (API Endpoints)

Instead of REST endpoints, we define program instructions:

pub fn create_todo_list(ctx: Context<CreateTodoList>) -> Result<()> {
    let todo_account = &mut ctx.accounts.todo_account;
    todo_account.owner = *ctx.accounts.user.key;
    todo_account.todo_count = 0;
    Ok(())
}

pub fn add_todo(ctx: Context<AddTodo>, content: String) -> Result<()> {
    let todo_account = &mut ctx.accounts.todo_account;
    let todo_item = &mut ctx.accounts.todo_item;
    
    todo_item.completed = false;
    todo_item.content = content;
    todo_item.created_at = Clock::get()?.unix_timestamp;
    
    todo_account.todo_count += 1;
    Ok(())
}

3. Context and Security

Instead of auth middleware, Solana uses a context pattern to specify required accounts and signers:

#[derive(Accounts)]
pub struct AddTodo<'info> {
    #[account(mut, has_one = owner)]
    pub todo_account: Account<'info, TodoAccount>,
    
    #[account(
        init,
        payer = user,
        space = 8 + 1 + 4 + 200 + 8, // discriminator + bool + string len + content + timestamp
        seeds = [b"todo", todo_account.key().as_ref(), &[todo_account.todo_count]],
        bump
    )]
    pub todo_item: Account<'info, TodoItem>,
    
    pub owner: Signer<'info>,
    
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

This is declaring:

  • Who can modify what (access control)
  • How much space to allocate (storage)
  • Who pays for it (billing)
  • How to find this account later (addressing)

All in one declarative structure! Think of it as combining auth, data validation, and database operations into one.

4. Client-Side Interaction

On the frontend, instead of fetch requests, we use Solana’s web3.js library:

const [todoAccountPDA] = await PublicKey.findProgramAddress(
  [Buffer.from("todo-list"), wallet.publicKey.toBuffer()],
  program.programId
);

const [todoItemPDA] = await PublicKey.findProgramAddress(
  [Buffer.from("todo"), todoAccountPDA.toBuffer(), Buffer.from([todoCount])],
  program.programId
);

await program.rpc.addTodo("Learn Solana", {
  accounts: {
    todoAccount: todoAccountPDA,
    todoItem: todoItemPDA,
    owner: wallet.publicKey,
    user: wallet.publicKey,
    systemProgram: SystemProgram.programId,
  }
});

5. User Authentication

There’s no username/password system. Instead, users authenticate with cryptographic wallets:

const connectWallet = async () => {
  if (window.solana) {
    const response = await window.solana.connect();
    const publicKey = response.publicKey.toString();
    console.log(`Connected: ${publicKey}`);
  }
};

The Mental Model Shift

The biggest challenge for web developers learning Solana isn’t the syntax - it’s the mental model:

  1. State is expensive: Unlike traditional databases where storage is cheap, on Solana you pay for every byte upfront.

  2. Everything is public: There’s no private data. Design with this in mind.

  3. Think in terms of accounts: Instead of collections of similar objects, think of each piece of data as its own account with an address.

  4. Account ownership is key: Programs own accounts, and only the owner can modify an account’s data.

  5. Wallets replace users: Identity is tied to cryptographic keys, not usernames and passwords.

Practical Development Tips

Now that you understand the fundamentals, here are some practical tips for building your todo app:

  1. Use the Anchor framework: It abstracts away much of the low-level Solana development. Think of it like Express or Django for Solana.

  2. Test locally first: Use Solana’s local validator for development instead of testnet or mainnet.

  3. Handle PDA derivation carefully: Your frontend needs to derive PDAs in exactly the same way as your program.

  4. Be aware of account sizes: You can’t resize accounts after creation, so plan accordingly.

  5. Optimize for composability: The power of Solana is that your program can interact with other programs easily.

Conclusion

So there you have it - a web developer’s guide to Solana fundamentals. Is it weird? Absolutely. Is it powerful? Definitely.

The learning curve is steep, but as a web developer, you already understand the core concepts of clients, servers, and databases. Solana just reshuffles these pieces into a decentralized architecture.

In our next post, we’ll actually build the todo app and show you the full code. But now you should have enough context to understand what’s happening under the hood, rather than just copy-pasting code you don’t understand.

Keep coding!