In my previous post, I talked about different trajectories blockchain developers can follow. Now, I would love to go a little bit deeper with the explanation of what kind of tools and skills you need to possess if you want to be a Backend Developer.
Main concept
A backend blockchain developer is someone who hates fronted. ๐ I am joking, of course. Those guys just don't want to mess up with the UX/UI, CSS, and all that stuff and want to build the "real" applications on the backend. ๐คฃ
But let's be serious. If you want to integrate blockchain into your backend, you have a couple of options on how to do it. It all depends on the dApp you are trying to build. Based on that, the programming language and your whole stack depend.
Let's try to pitch some of the use cases - definitely not all of them - the backend developer might be building.
Data ingestion dApps
Your job is to read the data from the blockchain, block by block, transaction by transaction, and event by event. Basically, get everything out there into your system, process it, run some analysis on top of it, and store it in your database or other storage. Why would you do it? There are companies like Chainalysis, TRM Labs, or even block explorers, which must have all the data available every single second. Your job is not to download only data from one blockchain but usually from tens of them.
Backend API / GraphQL for your Frontend dApp
You are part of the team which is building the end-to-end solution. It could be a wallet, exchange, NFT Marketplace, or any other use case out there. Your task is to create a backend for your front end. You need to handle chores like sign authorization, account history, account overview, sending out transactions, or interacting with smart contracts. Your end users would also love to receive instant notifications when something important happens on the blockchain within their wallet - a new NFT arrives or the balance of their wallet drops below some threshold.
This could be done on one or multiple different blockchains. You could even build a simple API middleware for your frontend application just to cache some information there or run some small jobs in GCP Cloud Functions or AWS Lambdas.
CLI app or CI/CD stage
You have a CI/CD pipeline in place or building a simple CLI tool for reading some information from the blockchain. It could be the latest block number, and based on that, you must perform some decisions. Or, you can read the account balance of some wallet on the blockchain and fail the CI/CD pipeline if the balance is not enough to perform some E2E test which must succeed. These are all small one-off use cases where you should interact with the blockchain(s).
Tech stack and skills
As you can see above, the requirements for each of the use cases above will be slightly different. Obviously, the biggest decision you need to make is the correct choice of programming language. This is crucial in order to make your life easier.
If you need to perform operations like signing the transactions in your backend, especially on multiple different blockchains, the only simple and viable way is to leverage JavaScript / TypeScript.
If you are building a simple CI/CD or CLI app, you are usually reading the data from the blockchain. The same applies to the data indexing app - these are just small scripts that read the data from the blockchain node RPC using JSON RPC API. So any language that supports performing HTTP API calls is usable.
Backend for the fronted in details
When we focus on some robust backend API for your front end, support of more than just one chain changes the game dramatically. If you need to generate wallets or sign transactions on top of it, the use of some blockchain SDK is inevitable.
You don't want to build the framework on the backend for your own use case. You don't want to code the cryptographic algorithms just to sign some crazy binary payloads you can't even debug. You don't want to read block by block, transaction by transaction, to detect all events that happen on the blockchain and affect your customers. That's all the things that are solved by others, and you should leverage them. You are building your own app with your unique business value. You don't want to build another SDK, that's probably not your intention - or maybe yes, and it's perfectly fine to do it.
To sum it up, what things you should usually focus on in your backend code is described in this table.
Business feature | Blockchain operation |
Authorization | Wallet generation / Wallet balance check |
Overview | Wallet balance |
Detail page | Wallet history |
Notifications | Scanning the whole blockchain block by block |
Action item | Transaction signing or smart contract invocation |
I have summarized in my previous post the blockchain SDKs, which are available for the JavaScript ecosystem. I will put it here as well because I strongly believe in one thing.
Less things you need to build from scratch, more value you will deliver to your customers / users. It's them that matters, not the tech experiments you are doing.
Above doesn't mean I am telling you that you should produce ๐ฉ ๐ฉ ๐ฉ code. I just want to say that you should focus on things that matter to you and your audience and don't do stuff that matters to someone else - like doing the exceptional blockchain SDK.
SDK | Blockchain protocol | Blockchain agnostic |
Tatum SDK | All supported - EVM chains, Bitcoin and UTXO chains, Solana, Tron, and many more | Yes - for all chains |
Ethers | Ethereum and all EVM chains | Yes (for EVM chains) |
Web3.js | Ethereum and all EVM chains | Yes (for EVM chains) |
TronWeb | Tron | No |
Solana Javascript SDK | Solana | No |
Bitcore | Bitcoin, Litecoin, Dogecoin, Bitcoin Cash | Yes (for UTXO chains) |
Summary
This is just a very short and quick introduction section for you guys. There is much more to uncover here, and I will be super happy to walk you through the details of every single use case I have mentioned here, the ups and downs of different approaches. Just stay tuned for the next articles. Happy coding.