From Backend to Blockchain: A Developer’s Journey

From Backend to Blockchain: A Developer’s Journey

When Sngular was recently tasked with building our first Web3 prototype, it quickly became clear that understanding blockchain isn’t just a matter of learning a new programming language. It requires rethinking fundamental assumptions about data, identity, and trust.

To complete the project, a mix of skills and perspectives were brought together. In particular, our two primary developers came from opposite ends of the decentralized web spectrum. Our lead developer Gonzalo Fernández, who has years of Java back-end experience, joined forces with Joseph Noott, who has extensive experience with blockchain code but not traditional APIs.

In this post, we’ll walk through the mental shifts and key concepts that can help bridge the gap from traditional backend development to building on a decentralized network. If you’re a fellow developer curious about Web3 but unsure where to start, this is for you.

What Exactly Is the Blockchain?

As backend developers, we’re used to databases being tucked away on servers, hidden behind APIs, and carefully guarded from the outside world. Blockchain flips that model upside down. At its core, a blockchain is a shared, append-only ledger that anyone (on a public chain) can read from.

• Every action is recorded publicly

Think of every transaction or update as a permanent entry in a giant logbook. On public blockchains, anyone can see the entire history. No private SELECT * queries hidden behind auth layers.

• Data is immutable

Once a piece of data has been accepted into the chain, it’s locked in. No “UPDATE” or “DELETE” statement. Ever. It’s like your INSERT was written in stone.

• But state is mutable

That doesn’t mean smart contracts can’t keep track of changing values. For example, a wallet balance can increase or decrease over time. What’s really happening is that new immutable records are being added and together they represent the current state.

• Consensus ensures integrity

In Web2, you trust the database administrator for consistency. In Web3, integrity comes from consensus. Miners (Proof of Work) or validators (Proof of Stake) collectively agree on which transactions are valid and in what order, ensuring no single actor can rewrite history.

 Analogy: Imagine if every INSERT into your SQL database had to be broadcast to a global network, validated by thousands of strangers, and then permanently logged before your app could use it. That’s the mental shift: your “database” is no longer yours alone. It’s a public, verifiable record.

Wallets: Your Identity in Web3

In Web2, we’re used to creating accounts with usernames, passwords, and maybe a 2FA code to prove who we are. In Web3, that whole model is replaced by wallets.

• Identity and Access

A wallet is both your identity and your access key. No more accounts to register, no password resets. It all comes down to cryptographic keys.

• Forget usernames and passwords

Instead of credentials stored in a database, your identity is represented by a public address derived from your cryptographic key pair.

• Cryptographic keys
  Think of a wallet like an SSH key pair you've probably used to access servers. You have:

  • A public key → which is transformed into your wallet's address. This is your identity, and it can be safely shared.
  • A private key → which you never share. It’s what gives you permission to act from that address.

• Signing transactions

When you interact with the blockchain, you don’t “log in.” Instead, you sign a transaction with your private key. The network verifies that the signature matches your public address, proving it really came from you.

Analogy: Your wallet is like an SSH key pair, but instead of logging into servers, you’re signing off on actions in a global, public ledger. Your public address = identity, your private key = permission. Lose your private key, and it’s like throwing away the only copy of your SSH private key. No admin can reset it for you.

Smart Contracts: Code as the Backend

If wallets are how you identify yourself on the blockchain, smart contracts are how you interact with it. Think of them as programs that live directly on the chain, waiting to execute when triggered.

• Deterministic

Smart contracts always run the same way given the same inputs. No hidden side effects, no random external calls. This ensures every node in the network reaches the same result when validating transactions.

• Written in languages like Solidity

Just like you’d write backend code in Java, Python, or Go, smart contracts are written in specialized languages designed for blockchains. On Ethereum, the most common one is Solidity.

• Deployed to a blockchain

Once written and tested, the contract gets deployed to a network such as Ethereum. At that point, it has a fixed address and becomes part of the chain itself.

• Immutable business logic

The code you deploy is permanent. You can’t patch it or push a hotfix the way you would with a Web2 service. That immutability is what gives users confidence but it also means you have to be extra careful before hitting “deploy.”

• Users interact with them using wallets

Instead of making API calls, users send transactions from their wallets to the smart contract’s address. The contract executes its code, updates state, and writes the results onto the chain.

Analogy: A smart contract is like an API endpoint frozen in time. Once it’s deployed, the business logic can’t be changed, and clients (wallets) can only interact with it through predefined methods.

Data on the Blockchain

When you come from a backend background, you’re used to thinking in terms of databases you control: schemas, tables, indexes, queries. Blockchain data doesn’t quite work that way.

• Immutability

Once a transaction is written to the chain, it’s permanent. You can’t change or delete rows like in SQL. Instead, every new transaction appends to the ledger, and the “current state” is reconstructed from that history.

• What does it look like?

Raw blockchain data is essentially a chain of blocks, each containing a batch of transactions. On Ethereum, this includes things such as sender and recipient addresses, amounts transferred, and smart contract calls with their input data.

• How do you read it? 

You don’t connect with a simple SQL client. Instead, you interact with a blockchain node (yours or a third-party provider like Alchemy or Infura) through JSON-RPC APIs. For richer queries, developers often rely on indexing services like The Graph, which extract and organize blockchain data into a queryable form.

• Main differences with traditional development
  • No direct UPDATE/DELETE, only appends.
  • Data is globally visible, not private to your app.
  • Reading is free, but writing (transactions) costs gas.
  • Access patterns are slower and more constrained compared to a relational database.

Analogy: Imagine your database was an ever-growing append-only log, publicly visible to everyone, where queries aren’t as simple as SELECT *. You’d need either to scan the log yourself or rely on an external indexer to make sense of it. That’s blockchain data in practice.

Consensus: Who Decides What’s True?

In Web2, truth in your system comes from your database. If your Postgres or Mongo cluster says a record exists, that’s the source of truth. In Web3, there’s no central database admin. Instead, thousands of independent nodes need to agree on what the current state is. That agreement process is called consensus.

• Why it matters

Without consensus, anyone could rewrite history: double-spend coins, alter balances, or push fake transactions. Consensus ensures that once a transaction is accepted, everyone in the network agrees it really happened.

• Proof of Work (PoW)

The original model, used by Bitcoin, relies on miners solving computational puzzles. It’s energy-intensive but battle-tested. Miners compete to add the next block, and the longest valid chain is considered the truth.

• Proof of Stake (PoS)

Ethereum and many modern blockchains use validators instead of miners. Validators “stake” tokens as collateral to earn the right to propose and validate blocks. If they act dishonestly, they risk losing their stake.

• The end result

Whether through work or stake, consensus ensures that all honest participants converge on the same history of transactions, and that history can’t be tampered with after the fact.

Analogy: In Web2, you might trust a single database master node as the final authority. In Web3, it’s like every transaction needs a group of strangers around the world to look at it, check it, and collectively nod before it gets recorded permanently.

Ownership: Who Really Holds the Data and Assets?

In Web2, “ownership” usually means your app controls a record in a database. If you buy a digital item in a game, what you really own is an entry in the company’s servers. Something they could revoke, alter, or delete at any time. In Web3, ownership takes on a very different meaning.

• Self-custody

Assets like tokens or NFTs live directly on the blockchain, tied to your wallet’s public address. If you hold the private key, you hold the asset. There’s no central admin who can freeze your account or roll back a purchase.

• Verifiable by anyone

Because blockchain data is public, anyone can independently check that your wallet owns a given asset. No need to trust a company’s internal records.

• Transfer without intermediaries

Sending an asset doesn’t involve a bank, payment processor, or platform. It’s a direct transaction between wallets, validated by the network.

• Code-enforced rules

Ownership often extends beyond just holding an item. Smart contracts can enforce royalties, permissions, or other rules automatically, without relying on a company’s backend logic.

Analogy: In Web2, “ownership” of digital items is like renting space in someone else’s database. They can evict you at any time. In Web3, ownership is more like holding the keys to a physical safe: as long as you have the key (private key), the contents are undeniably yours.

Visibility: Everything Happens in the Open

One of the most striking differences between Web2 and Web3 is how visible everything is. In traditional backend systems, most of your application logic and data stay behind closed doors. You expose only what you choose through APIs. On a public blockchain, much of that information is out in the open by default.

• Transactions are public

Every transfer of tokens, every interaction with a smart contract, every state change is recorded on the chain. Anyone can look it up with a block explorer (like Etherscan).

• Code is visible

Once deployed, smart contracts live at a public address. Many projects even verify and publish the source code, so anyone can audit exactly how the logic works.

• Balances and ownership are transparent

Wallet addresses and their holdings are public. You may not know who owns an address, but you can always see what it owns and what it has done.

• Main contrast with Web2
  • Web2: Data is private unless explicitly shared.
  • Web3: Data is public unless built on a private or permissioned chain.

Analogy: In Web2, your database is like a locked vault where only your app has the keys. In Web3, it’s more like an open museum: everyone can walk in and look around, but only the rightful keyholder (private key) can move or change what’s on display.

The Journey of a Request: Web2 vs Web3

For backend developers, one of the clearest ways to see the difference between Web2 and Web3 is to trace what happens when a user takes an action. The flows may look similar on the surface, but the mechanics under the hood are very different.

• Web2: A typical request.

  1. A user clicks a button in your frontend.
  2. The client sends a request to your server (usually REST or GraphQL).
  3. Your backend applies business logic, reads or updates a database, and returns a response.
  4. The entire flow is controlled by your infrastructure. Users trust you to keep data safe and available.

• Web3: A typical transaction.

  1. A user clicks a button in your dApp (Decentralized Application).
  2. Instead of sending a password or token, their wallet prompts them to sign a transaction with their private key.
  3. That transaction is broadcasted to the blockchain network.
  4. Validators or miners run consensus to decide if it’s valid and include it in a block.
  5. Once confirmed, the new state (like a token transfer or smart contract update) becomes visible to everyone.
  6. The dApp frontend often listens for confirmations and updates the UI once the transaction is finalized.

• Main differences.

  • Web2 requests are fast, private, and centralized. You control the servers and databases.
  • Web3 transactions are slower, public, and decentralized. The network as a whole validates and stores the result.
  • In Web2, you can roll back, patch, or fix errors in your backend. In Web3, once a transaction is confirmed, it’s immutable.

Analogy: A Web2 request is like submitting a form directly to a company’s help desk. You rely on them to process it. A Web3 transaction is like mailing a letter to a global council: everyone must agree the letter is authentic before it’s filed permanently into public records.

Pulling It All Together: Key Mental Shifts

Transitioning from backend development to blockchain development isn’t just about learning new tools. It’s about thinking differently. Here’s a summary of the major shifts to keep in mind:

• From centralized to decentralized. In Web2, you control the database. In Web3, truth comes from the network via consensus.

• From mutable to immutable. Data can’t be changed once written to the blockchain. State changes by appending new transactions, not overwriting old ones.

• From usernames/passwords to wallets. Identity and permission are tied to cryptographic keys, not credentials stored in a database.

• From opaque to transparent. Most actions and data are publicly visible, and anyone can verify ownership, balances, and contract code.

• From free to cost-aware. Every transaction consumes gas, so efficiency and optimization become financial as well as technical concerns.

• From soft enforcement to code-enforced rules. Smart contracts encode business logic immutably, and the network ensures it executes exactly as written.

• From request-response to signed transactions. Interactions are cryptographically signed and validated by the network rather than a centralized backend.

These shifts can feel daunting at first, but once you internalize them, building on the blockchain becomes less about rewriting your backend skills and more about adapting them to a global, decentralized environment.