Written by 
Web2 and Web3 developers don’t always have the kindest view of one another. They think Web3 is all scams and we think Web2 is stuck in the stone age with a technology that doesn’t take advantage of the distributed technology landscape. Both of these are unfair: any hype cycle draws unethical opportunists and technology isn’t better just because it’s newer.
But it’s time to call a truce and explore the real differences, the pros and cons. Much of the divide comes from a misunderstanding of the underlying technology and a focus on the negative headlines that ignore the meaningful businesses being built at scale. That’s why we’ve created the XRP Ledger Learning Portal, which helps Web2 developers transition to Web3. Explore the Web2-to-Web3 course to bridge the gap and start applying blockchain concepts to your projects. Discover how these worlds complement each other!
This article will explore where the two technologies share similarities, how Web2 devs can bridge that knowledge gap, and where blockchain technologies can benefit Web2 projects.
Your average Web2 developer looks at their stack and sees, roughly, frontend code, backend services, APIs, and databases. They control the location and maintenance of many of these pieces, but there are plenty of them that they don’t—APIs, cloud storage, database services, etc. You may have authentication where you store login and access information, but just as frequently you’ll useOAuth2 or something similar, meaning you rely at least in part on a third-party.
Web3 applications have many of these same features. The blockchain is essentially just a database, albeit distributed across peers. Transactions to the blockchain store data, which can then be searched via familiar API calls. The data there belongs to anyone who uses the ledger, but it can’t be tampered with (unless you somehow modify every copy of the data stored on all servers connected to that chain).
While many Web2 devs are used to standard CRUD apps—create, read, update, and delete—blockchains are append only. Once you send something to the ledger, it’s there forever, no take-backsies. Everyone who uses a given chain can store data on that same chain, and all data is visible to everyone else (unless the data is hashed or otherwise encrypted). Security through obscurity is an anti-pattern in software engineering, why isn’t it in financial services?
The way you interact with the blockchain (and any smart contracts therein) are through APIs. Anyone who has built modern web apps knows that much of the backend occurs through APIs, whether those are in-house or third-party. But the request/response dynamic of APIs works the same when the API is connected to a blockchain. In the end, it’s just a POST request.
With standard APIs and cloud-based services, you’d have to authenticate and pass access tokens with your requests. With a Web3 app, the wallet handles the auth process. Instead of tokens, you’ll need to sign every transaction with your wallet. Signing into your wallet can use other auth methods including OAuth2, but your wallet controls access to the ledger.
The reason that all auth runs through the wallet is that transactions on the ledger cost currency to execute—less than credit card transactions, but not nothing. Most hosted databases have some sort of fee for data transfer, but those databases don’t specialize in executing and storing transactions. Financial transactions usually go through some sort of API that takes a percentage of the total value. XRP Ledger (XRPL) transactions cost a fraction of those fees—compared to both traditional financial APIs and other Web3 options—and are not controlled by a single entity, as the ledger is open-source and decentralized.
While there are a lot of analogs that make it easy to understand how to map Web3 to Web2 tech, there are a few aspects that may make traditional web developers a little nervous. Most Web2 devs are used to having full control over their tech stack, while the blockchain is decentralized. Whether it runs locally or in their cloud instances, their code and data lives in places that they own.
You don’t necessarily give up full control of your data. In addition to running a node server, which connects to a blockchain and stores the data for easy access, you can also run your own validator server. Validators verify and commit transactions, so you will be able to determine what is considered valid on the blockchain. As a side benefit, this also helps the network continue to thrive.
On top of the decentralization, Web2 devs may look at the combination of append-only transactions and transparency by default with sweaty palms. We’ve all read stories of folks finding secrets like API keys in public repos—a secret sent to a blockchain is essentially there forever. This is where running on a testnet is crucial. You can test everything on a local testnet before sending it to the livenet. Heck, you can spin up your own testnet if full control is that important to you.
Having discussed some of the differences, I think it’s time we switched to what these two worlds have in common. There’s plenty for a Web2 dev to find familiar in a Web3 paradigm with a few new concepts to grasp. But in the next section, I want to zoom in on one feature particular to XRPL that will help Web2 jump into Web3 programming faster.
So what if you need to do more with your transaction than just store it on the blockchain? You may have heard about smart contracts, which will trigger some sort of action when they are called. But you essentially have to write your own API and code for that contract, which can be a lot of work and requires testing to get right, same as you would if you were writing your own API endpoints.
For many blockchains, you can write smart contracts that self-execute when certain conditions are fulfilled. You have to write all the code, set the parameters, test, and audit everything about it, then deploy it to your blockchain of choice. Sample code can help you get started, but errors in a contract can happen. You may only find the error after a contract executes, which can be costly.
On the XRP Ledger blockchain, there are existing building blocks, which are like premade API functions that operate on the ledger. You don’t need to write any code. All you need to do is know the parameters—read the docs for the function that you want to use and you are ready to go. These functions are native to the blockchain and require no additional work.
While a smart contract needs additional testing and auditing, these building blocks go through rigorous testing and are written by core ledger developers so all edge cases are automatically handled. They package common features like tokens, non-fungible tokens (NFTs), automated market makers (AMMs), etc. so that you don’t need to write your own implementation of those features—this guarantees they’re all interoperable with each other.
For devs used to APIs, you may have to contend with a little more latency than you’re used to due to the validation of every transaction. On the XRPL, a transaction usually takes between four and eight seconds to be validated; other blockchains could be longer (for example, Bitcoin typically takes about an hour for a transaction to be considered validated). If there are any delays in validating the transaction, APIs may respond with an acknowledgement at first, then follow with a full response payload later. Most libraries offer async functions that will wait for transactions to be considered fully validated, so you could build async interfaces if you expect to interact with contracts or fixed functions that will take a while to respond.
So far, we’ve talked about the Web3 tech that maps to Web2 concepts. Next, let’s explore the new abilities that adding blockchain capabilities to your repertoire will unlock.
While a blockchain ledger is analogous to a database, that’s not the use case where a Web2 developer is going to find the best results. A blockchain shines in financial use cases. You get near-instantaneous value transfer around the world with a blockchain as opposed to the days that banks take to settle any transaction. This is what’s referred to as the Internet of Value, which is all about moving funds and value around the world with the same ease of sending an email.
Typically, a Web2 developer would add financial capabilities through a credit card processor or other financial services provider. Those services take a not insignificant portion of the payment as their due—up to three percent on some credit card processors. Credit card companies recently settled a lawsuit over these fees, which can be one of the largest expenses that small businesses face. There’s still a cost on blockchain transactions, but it’s much lower—typically a fraction of a US cent.
As the lawsuit mentioned above shows, having one or two massive entities control the payment process for almost every transaction isn’t always the best for customers. The blockchain eliminates middlemen. Instead of trusting a single entity a lot, you’re trusting a lot of entities a little. It eradicates intermediaries, verifying payments in a way that is transparent and decentralized.
Remember at the beginning when I said that Web2 devs side-eye Web3 apps as all scams? The truth is that a transparent, peer-validated blockchain actually prevents a lot of payment scams. Some individual sellers and small merchants have been subject to online refund scams and request and refund scams. Transactions can’t be rolled back by sneaky buyers; refunds have to be initiated as a transaction from seller to buyer.
Sometimes you run into an API that doesn’t quite meet your needs—almost, but not quite. Imagine if you could add a little customization to the API itself, instead of needing to rewrite the whole thing from scratch. Additional programmability for fixed functions is coming, which will allow you to do just that. You’ll be able to add your own customizations to existing fixed functions so that whatever specific business logic you have is reflected and incorporated in these blockchain-native functions.
There’s a lot of common concepts between Web2 and Web3 development. Much of the tech involved actually crosses between paradigms—you still need a frontend and a backend. A blockchain is really just a distributed database that multiple peers maintain and validate. You’ll have to get used to the total transparency, distributed control, and append-only nature of it, but you’ll be better off once you do.
For the financial use cases at which XRPL and other blockchains excel, these are benefits, not negatives. Transactions that are visible to all, immutable, and under no one’s full control provide a trustworthy payment method without having to trust individual payment processors.
If you’re ready to take the next step in understanding blockchain and integrating these tools into your projects, check out our Web2 to Web3 XRPL Learning Portal course. It’s designed specifically for Web2 developers to get hands-on experience with blockchain technology, helping you bridge the gap and build confidently in this new paradigm.