Safe | Intuitive | Integrated AI stack - Accelerate your GenAI adoption journey with RejoAI

We have developed around 50+ blockchain projects and helped companies to raise funds.
You can connect directly to our Near Protocol developers using any of the above links.

Talk to Near Developer

How to Build DApps on Near Blockchain

What is a NEAR protocol?

NEAR is a Layer-1 Blockchain that is infinitely scalable, extremely safe, and easy to use. The NEAR Blockchain can record and validate transactions comparable to other networks due to a ground-breaking innovation called Nightshade.

Sharding Technology is a method used to make NEAR extremely quick. Without leaving the Ethereum network, Ethereum developers can benefit from NEAR protocol development. While this happens, anybody can create their application-specific Blockchain on the Octopus network and migrate it to NEAR protocol for performance, stability, and integrity.

Users love NEAR because anyone can get started using it quickly due to NEAR’s straightforward wallet. It is a simple wallet without a little hassle, pop-ups, network switching, or crypto jargon. The plain and straightforward exterior reveals a wealth of functionalities that enable developers to design a smooth user experience whenever they engage with the NEAR protocol development.

Dependencies for NEAR Development

The NEAR blockchain has several applications and services intended to be used independently and without authorization.

NEAR Wallet

The NEAR wallet has a feature that makes it easy for users to participate in the staking and governance activities on the NEAR platform. The NEAR blockchain makes it easier for programmers and business users to keep digital content. The NEAR wallet is accessible for handling payments and transactions on the network.

NEAR Gitpod

NEAR uses Gitpod technology to provide developers with a quick onboarding process. This innovation provides a digital “Integrated Development Environment” (IDE). Developers may simply create, analyze, and execute smart contracts from the internet by using the IDE. For experienced and novice developers, NEAR offers other layouts installed with a single tap.

NEAR SDKs

The languages used to create smart contracts NEAR are JavaScript, Rust, and AssemblyScript. NEAR includes a full SDK with industry-standard data formats and debugging facilities for AssemblyScript and Rust.

Command Line Tools

Developers can build, verify and launch programs from their surrounding ecosystems using NEAR’s command-line tools.

NEAR Explorer

NEAR Explorer offers all the genuine network statistics in a readily accessible web-based manner to aid users in comprehending the effectiveness of the NEAR infrastructure and speeding up contract troubleshooting.

Building DApp on Near Using WASM, Rust, Parcel, and React

The Fundamentals

You need previous development expertise using dev tools like Truffle, Hardhat, Anchor, or Foundry, as well as on Ethereum, an EVM, a layer-2 chain, Solana, or something like. You get Rust installed for Visual Studio Code on either Linux or macOS. NPM should be at least version 8.3.0+, and Node.js must be installed between 14.19.0 and 17.1.0. Smart contract deployment, gas costs, wallet accounts, transaction explorers, etc., are all terms you become familiar with. Furthermore, understanding this example and how everything works don't require expert knowledge.

Setting Up Your Wallet

We’ll start by setting up a wallet and profile on the NEAR and obtaining some experimental Near coins to send out on the platform.
The fact that Near account entries are shown as human-readable text (e.g., “myaccount.testnet” for validation or “myaccount.near" for network) is an unusual variation that potentially makes it more user-friendly. With these profile names, you can be extremely creative if your chosen name is not already used. Furthermore, you already have this capacity within the box with Near, and your existing contracts may be transferred straight to your selected names. Thus you don't have to register a different ENS-like name (.ETH).SOL, like on Solana.
As standard practice when executing smart contracts on the network, we will be using sub-account entries like the ones below that include the contract names:
contract.myaccount.testnet (for experimenting)
contract.myaccount.near (for network)
A smart contract must be executed once per sub-address in Near. This seems so structured and allows for upgrades. After setting up our Near account, we should now have a testing amount of Near experimental tokens to work with for the next stage.

Preparing the Environment

Installing the Near CLI through NPM as follows is the ideal method to begin structuring our framework.
npm install near-cli
If you have that made properly, you must be capable of seeing the version number in your terminal as:
near --version
After that, we'll join the Near Test network using Near CLI by doing as follows:
near login
Once we execute this, a browser window will appear suggesting an access request at “rpc.testnet.near.org,” asking you to authorize the login procedure if you initiated your near account properly.
After your login access is accepted, you will see a popup telling you that you may now dismiss the window and go back to the VSCode terminal and that your login has been authorized. You can see in the terminal that you are signed into Near CLI with the specified .testnet address:
After logging onto the Near testnet with our Near wallet account (myaccount.testnet) and installing the CLI, we now have everything we need to begin a new project in VSCode that will house our project files. So let's begin by creating a new directory in your VSCode console as seen below:
mkdir near-starter-dapp
cd near-starter-dapp
Let’s create a subdirectory called “contract” in this main directory to house our Rust script and building files as follows:
mkdir contract
cd contract
We must create a new Rust project using Cargo inside of this “contract” directory, as well as create a few helpful scripts for generating and testing our Rust code before compiling it to WASM:
cargo init --lib
As you can see, this generates a blank Rust project and gives us all the directories we need to begin creating our smart contract. While “cargo.toml” will list some prerequisites and variables for our project, the “src” folder houses the Rust files.
We must add the WASM destination for execution to our Rust setup before moving further with our Rust code to ensure that our contracts are correctly compiled. The following should be typed into the terminal:
rustup target add wasm32-
unknown-unknown
After completing this step and preparing our directory for Rust, let’s write some straightforward commands that will be used to carry out basic development and testing terminal activities inside this “contract” directory. The subsequent scripts will be written:

Build.sh
#!/bin/bush
set -e
RUSTFLAGS='-C link-arg=_s' cargo build --target
wasm32-unknown --release
cp target/wasm32-unknown-unknown/release/*.wasm
./res/

Build.bat
cargo build --target wasm32-unknown-unknown --release
copy target\wasm32-unknown-unknown\release\*.wasm
res

Test.sh
#!/bin/bash
set -e
cargo test -- --nocapture
When these scripts are finished, our "contract" directory ought to appear as follows:
For the time being, we won’t bother about the cargo.lock file, but we will need to make the following changes to the cargo.toml file:
Now that we’ve established these directories, let’s add one more directory to the “contracts” folder:
mkdir res
We now have the following "contract" directory structure:

We have prepared our Rust ecosystem and are ready to develop our Near-specific smart contract!

Scale your Near Protocol projects with us

Creating a NEAR Smart Contract

Let’s look at our main “contracts” folder’s “source” directory. There is a basic Rust file included called “lib.rs”; open it in VSCode and have a glance at it:
This currently just executes a straightforward test function. Still, if we execute our “test.sh” code from the base of the “contract” folder, the file is rapidly generated and checked, with the following output displayed in the terminal:
running 1 test
test tests::it_works ...ok
The next step is to replace the "lib.rs” file with the code below.

What Are Event Contracts?

In a nutshell, our smart contract builds a straightforward app for organizing potential events with Title, Description, and a specified Budget. Any of us logged into the app can initiate these events using our Near wallet, and anyone logged in to the app could even vote on the scheduled events mentioned.

Now, we must add two additional Rust files to our project to complete it with the values and patterns required to complete our main application file.

The first thing we’ll do is make a file called “utils.rs” and save it with the code below:
Then, we save the following information in a file called “models.rs":

Our primary "lib.rs" file imports several crucial structs from our "models.rs" file, primarily the "Event" struct and its execution block. Depending on additional items we might wish to include in our total contract, they can be added eventually.

Some essential elements, values, and functions for converting between different units are included in the “utils.rs” file. This file, like “models.rs,” can be modified over time as new features are added. Only two generic functions for Promise and encoding are currently in this file.

As soon as these three files are complete, they are all placed in the “src” directory and prepared for a test “build” to see whether our project complies and is prepared for verification and validation.

Creating the Cargo Smart Contracts and Checking That it Works

Execute the "build.sh" script as follows in the path of "contract" (this method varies between Mac and Linux; on Linux, the terminal command doesn't require "bash," but on Mac, you move ahead as follows):
bash ./build.sh
We ought to have some new items in our “contract” directory after a short waiting period as Cargo downloads the necessary crates, sets up the necessary Rust requirements, compiles, and assembles all this.
First, you’ll see a brand-new “target” folder. The Cargo package management comes with the usual Rust build folder, which makes organizing output files straightforward. Initial versions (binaries) of our Rust program are located in this "target" folder, one of which is in a distinct "wasm32-unknown-unknown" subdirectory.
We can ignore these files in “target” for the time being because the WASM file we expressly moved to our other build directory, “res,” using our “build.bat” code, is just what we need for the Near Blockchain.
We can see one file called “near starter dapp.wasm" inside of "res," which is the resource we will gradually need to launch on Near. For simplicity, we cloned this from "target" so that we wouldn't have to search through our target build folders at great depths each time we made a change and recompiled.

Writing Unit Tests in Rust

Let’s begin by looking more closely at our “Event” contract to determine which functions our Rust unit tests should be testing against. If we reopen “lib.rs” in our “src” folder, we find the same information as before:
We can choose a few methods to test with our unit tests immediately because this contract must enable users logged in with their Near wallet to build an event and individuals to vote on the listed events.
To implement this in Rust, it is simplest to first recognize the two main functions that start contract variation:
1. Add_event()
2. Add_vote()
We'll first look at "add event" and the utilities accompanying it.
The main feature of our contract is the "add event" function, which creates a project with a Title, Description, and proposed Budget in the events listing. We can start a new event on the Near Blockchain by calling the "event" datatype with "Event::new" and then referencing it in our front end so that it can be shown on Dapp’s home page. We started the "event" data frame in our “models.rs” file.
Additionally, two other assistance operations first show the list of events to confirm that an event was created on-chain.
//lines 57-61 (in "lib.rs" above)
pub fn list_events()
...
And remember details of all the events and initiatives covered by our contract.
//lines 63-65 (in "lib.rs" above)
pub fn event_count()
...
To ensure that this entire function meets the requirements, we must create a unit test. To that end, let’s add the following code to the bottom of the “lib.rs” file:

Important Points in Testing this Code

It is clear how legible and intelligible this system is when contrasted to what may be a lot more "verbose" testing environment in JavaScript when looking at the unit test we initiated, which validates against the "add event" function.
Consequently, for the “add event” function that our contract calls: contract.add_event()
To simulate a circumstance where "Alice" reflects a Near account, connects with a brand-new contract example ("Contract::new"), and then initiates a new event in our "create project" unit test, we build up a test simulation platform, also known as a "context" in our Near SDK.
This comprehensive test also calls the following associated Contract function, which is allocated to the “result” variable as shown in:
let result = contract.event_count()
This serves to validate our “add event()” result by confirming that a new event was just in case produced during our test and that the number of events overall is “1”:
assert_eq!(result, 1);
Run the test script in your terminal from the "contract" folder to verify that we succeed:
bash ./test.sh
Similar to how it did during our methods to cope with the build, Cargo will put together our crates and constraints, analyze our code, generate the “context” framework from Near SDK, and play our unit test with a brand-new Contract example just as it would be done when it was positioned on a blockchain. You ought to see the following in your VSCode interface after this procedure is finished:

Our first Rust unit test worked great because it showed that a new event was produced in the experimental “context” environment.
The “add vote()” function is the next one for which we will create a unit test. This is shown in our primary contract script here:

The process of adding this data to the event defined by event ID (“id: usize”) is carried out by this procedure, which gets an event and ends up making it “mutable” so that it can be amended with “votes.” Anyone who has signed in to the Dapp using their Near wallet and has immediate access to this feature is referred to as a “voter” in this context.
In addition, there is a “helper” method named “get_total_votes()” near the side of the final contract (following add_vote) that aids in verifying whether a vote was added and which we will also use for our unit test:
The following code will be added as a second test block inside the "mod tests" brackets at the bottom of "lib.rs," after our unit tests.
The process of creating a “context” and initializing accounts for “Alice” and “Contract::new” is the same as it was for the prior test. But in this instance, we introduced the code here:
contract.add_vote(0)
in which the event ID is "0," and after that
let result =
contract.get_total_votes(0)
assert_eq!(result, 1)

Let's build together on Near Protocol

Concluding Unit Tests in Cargo

We will only use these two Rust unit tests in the meantime, and if all goes according to plan, our "lib.rs" file will be fully functional and ready to execute both tests:
Now let us run our "test.sh" script once more in the "contract" folder of our VSCode terminal:
bash ./test.sh
As usual, after a quick development phase, both of the unit tests must now succeed on the console, as shown below:

Our Rust unit tests have been successful, and we are now prepared to create our contract one last time for WASM before deploying it to the Near Testnet.

Setting Up WASM Before Deployment and Preparing a Near Testnet Subcontract

Sign in to your account first, then approve the pop-up transaction (steps defined above). Then, before uploading our smart contract deployment on Near, we must assign a sub-account as a temporary holding location. Inputting the following requires more attention to the code for Near CLI:
near create-account near-starter-
dapp.myaccount.testnet --masterAccount
myaccount.testnet
You should then get the following indication that your sub-account was formed in the terminal as a result:
Saving key to '/Users//.near-
credentials/testnet/near-starter-
dapp.myaccount.testnet.json'

Account near-starter-dapp.myaccount.testnet for
network "testnet" was created.
We will now execute “build.sh” one final time while still in the “contract” folder of our project:
bash ./build.sh
's execute the following code as our deployment script now, which will initiate the installation to our sub-account:
near deploy --accountId near-starter-
dapp.myaccount.testnet --wasmFile
res/near_starter_dapp.wasm
Your Near testnet smart contract should now be installed, and if everything works well, you should receive the following validation in the console:

A Bit of Background Before We Start Using React and Javascript

Before we move on with our front end, a few "loose ends" with our contract implementation need to be wrapped up. One of them is how we can "update" our smart contract on Near if the Rust code is changed maybe something doesn't function as planned.

Deleting this sub-account is a necessary initial step in updating the smart contract because the contract can then be changed after it has been removed from the Near Testnet. Do the following in the VSCode terminal:

near delete near-starter-dapp.myaccount.testnet
myaccount.testnet

In contrast to when creating sub-accounts, you do not need to specify “masterAccount" here. You can delete any sub-addresses while still logged into Near with the primary account.

Upgrade and Replacement of Smart Contract on Near

Now, using the same procedure, we must create a similar sub-account once more.
near create-account near-starter-
dapp.myaccount.testnet --masterAccount
myaccount.testnet
Before re-compiling it with our build process after making changes to the Rust code, we must DELETE the WASM file in the "res" folder. Following your Rust changes, remove the “near_starter_dapp.wasm” from the "res" directory: Let’s use the build script we’ve been using throughout our course to recreate our updated Rust code:
bash ./build.sh
You ought to have a fresh WASM file in "res" once the assembling process is complete. After that, we can issue the same deploy command again:
near deploy --accountId near-starter-
dapp.myaccount.testnet --wasmFile
res/near_starter_dapp.wasm
YIf everything goes according to plan, your terminal should display the installation confirmation screen as it did previously:
Recall that we built the following sub-account so that we could execute a contract on Near:
near-starter-dapp.myaccount.testnet
There are no complex hex strings to remember here; this is the real address we will put into our React application to invoke our functions. As long as it was accessible, it would also be the same accessible contract address on Near Mainnet. It might look something like this:
near-starter.myaccount.near
We are now prepared to migrate to React/JavaScript to interact with a straightforward front-end framework now that we have understood how to "update" a smart contract on the Near Testnet and are more knowledgeable about how contract addresses function.

Setting Up Directory Configuration Files For Front-end Integration

To access our root directory, we must now climb up one level in our folder system out of the "contract" folder (which houses the project's Rust/WASM component).
cd ../

near-starter-app $
Now let us build a “package.json” file with the following components after changing into this root folder (near-starter-dapp) as shown below:
Our JS dependency installation in Yarn needs to be run right away:
near-starter-app $

yarn
Next, make an "src” folder in the root folder (near the starter-dapp):
near-starter-dapp $

mkdir src

cd src
Inside our new “src” folder, foremost of which should be the following for our Near configuration files. We’ll call it “config.js”:
An API configuration file will be the next one we make in the "src" folder. The wallet, active account ID, and smart contract are all initialized. Additionally, it specifies the procedures that our Dapp will execute. This file will be called "utils.js," as shown below.

Launching the DApp

Let’s first confirm that we are in the root directory now:
near-starter-app
After this, “npm start” or “yarn start,” as shown:
npm start
The VSCode Terminal must therefore display the following:
The "Sign-in" screen for our Dapp will appear if we authenticate in the browser on localhost:123:
Just sign in as normal using the Near Wallet:
The “Events” screen is next: click “Add An Event” to complete the drop-down menu React form:
Hit “Submit” after filling out the event form with the title, estimated budget, and description as indicated:
You might need to reload the browser to see the refreshed Events list on the webpage after we submit an event because there is a brief "reset" time (delay as explained above) when we submit an event:
You can click the "Vote" button to add a "vote" to a project. Then, after refreshing the page once more, the project's revised vote total will be displayed.

Conclusion

Building a DApp on the Near blockchain can be arduous, and many developers find it hard to master the Rust programming language and technical stack needed to build on NEAR. As the foundation continues to incentivize blockchain development focused on creating solutions on Near, your DApp can benefit from the growing ecosystem of upcoming decentralized applications. Our blockchain development experts can help you build whatever you imagine creating on Near.

We have therefore concluded. We start by defining the NEAR protocol development, outlining its prerequisites, and providing a tutorial for creating a DApp. As a result, we have created a simple end-to-end approach to get the Near Protocol development up and running. We hope that you had a wonderful read.

Research

Workshop

Why us

Other Related Services From Rejolut

Hire NFT
Developer

Solana Is A Webscale Blockchain That Provides Fast, Secure, Scalable Decentralized Apps And Marketplaces

Hire Solana
Developer

olana is growing fast as SOL becoming the blockchain of choice for smart contract

Hire Blockchain
Developer

There are several reasons why people develop blockchain projects, at least if these projects are not shitcoins

Why Rejolut?

1 Reduce Cost

RCW™ is the number one way to reduce superficial and bloated development costs.

We’ll work with you to develop a true ‘MVP’ (Minimum Viable Product). We will “cut the fat” and design a lean product that has only the critical features.

2 Define Product Strategy

Designing a successful product is a science and we help implement the same Product Design frameworks used by the most successful products in the world (Facebook, Instagram, Uber etc.)

3 Speed

In an industry where being first to market is critical, speed is essential. RCW™ is the fastest, most effective way to take an idea to development. RCW™ is choreographed to ensure we gather an in-depth understanding of your idea in the shortest time possible.

4 Limit Your Risk

Appsters RCW™ helps you identify problem areas in your concept and business model. We will identify your weaknesses so you can make an informed business decision about the best path for your product.

Our Clients

We as a blockchain development company take your success personally as we strongly believe in a philosophy that "Your success is our success and as you grow, we grow." We go the extra mile to deliver you the best product.

BlockApps

CoinDCX

Tata Communications

Malaysian airline

Hedera HashGraph

Houm

Xeniapp

Jazeera airline

EarthId

Hbar Price

EarthTile

MentorBox

TaskBar

Siki

The Purpose Company

Hashing Systems

TraxSmart

DispalyRide

Infilect

Verified Network

What Our Clients Say

Don't just take our words for it

Rejolut is staying at the forefront of technology. From participating in (and winning) hackathons to showcasing their ability to implement almost any piece of code and contributing in open source software for anyone in the world to benefit from the increased functionality. They’ve shown they can do it all.

Pablo Peillard

Founder, Hashing Systems

Enjoyed working with the Rejolut team; professional and with a sound understanding of smart contracts and blockchain; easy to work with and I highly recommend the team for future projects. Kudos!

Zhang

Founder, 200eth

They have great problem-solving skills. The best part is they very well understand the business fundamentals and at the same time are apt with domain knowledge.