Backend Blockchain Developer: Vital Skills and Tools


6 min read

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.

Blockchain node RPC interface, in most cases, if not all of them, won't give you the data in the format you can effectively query them. You can read the block or raw transactions, but the logic hidden inside these transactions, like balance updates or token transfers, is not queriable. You must download and index these data by yourself.

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.

The only universal programming language every blockchain protocol supports is JavaScript. Every blockchain has some client SDK library written in JavaScript or TypeScript and then, optionally, something on top of it like Rust or Go. The reasoning behind this is that every blockchain is trying to support browser-based wallets to be built for self-managing the assets and the wallet by the end users. That's the main concept of the blockchain itself - be your own bank. That's why every protocol is building the JavaScript SDK, which exposes features like wallet generation and transaction signing in an easy-to-integrate way. The cryptographic complexity hidden inside is huge, and average non-blockchain developers struggle with this a lot if they should do the whole logic by themselves.

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 featureBlockchain operation
AuthorizationWallet generation / Wallet balance check
OverviewWallet balance
Detail pageWallet history
NotificationsScanning the whole blockchain block by block
Action itemTransaction 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.

SDKBlockchain protocolBlockchain agnostic
Tatum SDKAll supported - EVM chains, Bitcoin and UTXO chains, Solana, Tron, and many moreYes - for all chains
EthersEthereum and all EVM chainsYes (for EVM chains)
Web3.jsEthereum and all EVM chainsYes (for EVM chains)
Solana Javascript SDKSolanaNo
BitcoreBitcoin, Litecoin, Dogecoin, Bitcoin CashYes (for UTXO chains)


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.