The Blockchain will Replace your Backend
What if we could stop wasting most of our development time re-developing the same thing again and again?
The feeling I got whenever starting a new hobby project is that before getting to the meat and having fun, I had to spend a significant amount of time doing trivial stuff.
On my latest hobby project, I discovered there was an area where developers stopped wasting their time.
Usually, a new project starts like this:
- Create front and basic API
- Create a quick docker-compose for ease of development (maybe)
- Create a local DB, connect your backend to it.
- Probably you have users, so setup authentication
- Get to the meat of your project
By the time I get to (5), I lost excitement. On my last project though, it felt different.
As the title gave away, this project was in the (so-called) web 3 space.
🍔 Fast Dev
Originally I had a lot of misgivings about the area. What can you do with a blockchain that you can’t do with a database? What value does it bring?
IMO there is a 70% chance that this whole web 3 thing will be a flop. But if the other 30% comes to happen, it will be big. So it’s worth investing time to learn how it works.
So off I went on this first learning project. (Live at invisoo.com. I’ll write another blog to talk more about the project and its design decisions.)
Here is what starting this project looked like:
- Create basic front and smart contract
- Get to the meat
First shortcut: a contract can serve as both your backend and your DB (i.e. execution and storage). You don’t need to deal with authentication because web 3 users come with an identity in the form of their wallet.
🍕Piece of the Whole
Throughout my development, I got the feeling of being able to leverage of “bigger whole”. It starts with user/wallet handling but it goes on…
I felt the inter-connected of web 3 shined by how ubiquitous tokens are:
- Using Open Zeppelin you can easily customize a token implementation to your needs.
- New tokens are supported by every wallet without any need for you to do anything.
- Online transaction explorers will detect underlying token transfers.
- Using tokens make your DApp “pluggable” into an even bigger part of the ecosystem. For example, once you transfer a token to the user, he can use it with any other DApp. For example, he could go and trade it at Uniswap even though trading wasn’t in your original design.
(Tokens may not be your go-to design though. I also didn’t consider them at the beginning. I’ll expand on why I modified the design of my project to use tokens in the next blog. I found the implementation easier this way.)
To expand on the third point, I found online transaction explorers mind-blowing.
You just deploy, you don’t have to do anything and you can visualize every interaction of a user with your contract. This is the benefit of operating on a transparent data layer.
You can easily see the current state of your contract, the users and also all the historical transactions that brought us to this state.
🥦 The Less Fun
The thing I found buggy is the handling of chains. Which chain is the user connected to? The localhost chain? The test chain? The main chain (i.e. Ethereum).
Depending on the chain the user is connected to, we need to rely on a different “provider”. The provider allows our front to read and write the blockchain. It’s sad that we have to rely on a centralized intermediary, but it’s necessary in a world where users don’t run and index the blockchain locally.
Another pain I felt while developing is doing math. By default smart contracts only handle integers. In the end, you can just import some library to solve this problem but it’s still messy.
I’m still not sure what value Web 3 brings to the users, but at least I found it does bring value to developers.
The problems are small compared to the value provided by being part of a big ecosystem.
Operating on a transparent data layer like the blockchain will not fit every design though. All data has to be public.
Web 3 people would say that’s not a bug but a feature 😛