Essential Skills and Tools for Frontend and Mobile Blockchain Developers

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 Frontend / Mobile Developer.

Main concept

When you want to build a blockchain-powered application or dApp, you have a couple of ways how to build it. You can connect to the blockchain directly from the browser or mobile app - let's call these a client. It means you will perform direct interactions with the blockchain node via blockchain node RPC, or you will leverage some SDK or library, which will do the heavy lifting for you.

No matter what dApp you are building, the concept is still the same. From the client side - the browser of your user or their mobile device - your application is going to perform the actions against the blockchain. Those actions might vary depending on the app you are building, but usually, you will meet with these:

1. Generate a blockchain wallet for your user (Sign up)

2. Verify that a blockchain wallet can access your system (Sign in)

3. Get the balance of the blockchain wallet (Overview)

4. Get the history of the blockchain wallet - what operations happened on the wallet (Detail)

5. Optionally - sign blockchain transactions with your blockchain wallet (Action item)

6. Optionally - subscribe to blockchain events for updates (Notification center)

I will focus in the next sections on browser-based dApps, because I have much more experience with them, but the practices and general patterns are applicable in mobile development as well.

Tech stack and a best practice for browser-based dApp

As with any browser application, the one connected to the blockchain must follow the same standards and security requirements. It should be:

1. fast with as few dependencies as possible due to loading time on the client

2. scalable

3. should not expose sensitive information

With Web 3.0, the above is even more important than with regular non-blockchain apps. You must understand that you are working with the real money of your customers.

How to achieve fast loading time

This is a very well-known topic, so I will just tell you - be reasonable! You don't need dependency for every helper function you are using. Sometimes, it's much easier to write ten lines of code instead of downloading a package with 1MB of internal dependencies just to achieve those ten lines using another three lines.

But from the blockchain perspective, you will usually download some SDK, which will help you with interactions with the blockchain node RPCs. There are multiple choices on how to proceed here. It all depends on the blockchain you want to integrate. Here is a small table of native blockchain SDKs that could help you with the development. But watch out, not all of them are browser-ready. 😈

Of course, there are many more SDKs out there for many more blockchains, but these are the most used ones. They vary on the bundle size, the blockchain network support, and browser compatibility.

You don't have to use any SDK and call the blockchain RPC nodes directly, but it comes with some struggles:

1. You must be an expert in the JSON RPC specifics of the blockchain you want to integrate. You must be able to prepare the payloads correctly and prepare the HEX data in the correct format. And, of course, once you realize you don't want to work with this blockchain anymore and want to use another one, you must rewrite the whole logic you have created from scratch. This is where SDK with blockchain agnostic architecture comes in handy - code once, run on every blockchain.

2. You must store your access credentials on the client. If you are using direct RPCs, you have to store the credentials in your code somewhere - the raw nodes usually give you only Basic Auth. Things like JWT tokens and other authorization methods are not available by default - you should use SDK for that.

3. You must handle outages of the node RPCs. If you want to integrate to 1 specific RPC URL of 1 node, there is a huge probability that once this node is down - it means your whole application will be down. You must either connect to multiple nodes at once or leverage some smart SDK feature that solves this problem out of the box.

4. You can't generate wallets or sign transactions with native node RPC calls, not in a secure way.

How to achieve scalability

Scalability is the issue. It's always an issue for every app. I will discuss specifics from the blockchain perspective only, and the rest is up to your own research 😊.

If your dApp has five active users per second, you will not have any issues. At all. But once you go up to 1000 or even more, you will have a problem. It's a nice problem to have - you have so much traction that you are a 🚀, but the access to the blockchain is slowing down. Significantly. It's because one blockchain RPC node can handle only some predefined amount of traffic. It could be thousands of calls per second, but sooner or later, you are gonna hit the limits. This is the point where you will plug in more RPC nodes to your pool, and all the load-balancing issues start to happen. You can either don't care from the start (I would do it, I would solve the problem once it arrives) or find an out-of-the-box solution that has this solved already.

You will also be forced to introduce some caching middleware on your end, so not all of the traffic will go to the nodes but will just hit the cache. There are multiple ways how to deal with this, but those are problems that are usually not gonna be solved on the browser but on the backend side of your dApp. I will discuss this topic in the following posts, so no worries, I got you covered. 😉

How to handle sensitive information

You have multiple sensitive data which should not leak to the public. It is the access credentials to your underlying blockchain node infrastructure - either your managed nodes or 3rd party providers. And, what is more important, the wallets and associated private keys of your users.

As mentioned above, the native blockchain RPC node access without using the SDK usually gives you only Basic Auth with no advanced security like JWT tokens or even IP whitelisting - which is unusable in the browser world anyway. SDKs usually give you some level of abstraction and advanced security features on top of this. Or, they are completely open source and can connect to the open source nodes running out there for everyone to leverage, so you don't have to worry about it at all - that's the case with Tatum SDK and their RPC access.

On top of it, native blockchain node RPC doesn't give you the power to generate new wallets or sign transactions locally without exposing the private key to the internet. NEVER SEND PRIVATE KEYS TO THE RPC NODE OR GENERATE PRIVATE KEYS OR WALLETS USING RPC NODE METHODS!!!!! Once you do this, the wallets are compromised by default because they were exposed to the internet. You really must use the SDK for these or leverage some browser-based extensions like MetaMask or Phantom.

Summary

I believe that should be all for a successful start. If you gonna follow this advice, you will not make any crucial mistake that could lead to the loss of assets of your customers or a fatal outage of your dApp. In the following posts, I will go even deeper into the best practices and development techniques from the front-end perspective. So, stay tuned. Thanks.