Skip to main content

Determining your integration model

📝In this article, we cover:
  • Interacting with Immutable zkEVM
  • Client-side vs server-side architecture

Interacting with Immutable zkEVM

There are three ways to interact with Immutable zkEVM:

  • JSON-RPC
  • REST API
  • SDK

JSON-RPC​

JSON-RPC APIs enables applications to interact directly with Ethereum node providers. See here for a list of supported calls on Immutable zkEVM. While developers can communicate directly with Ethereum nodes, it is often easier to abstract these interactions and build on existing tooling (eg libraries like web3.js), or our Immutable APIs and SDKs.

REST API​

Immutable offers platform APIs to abstract contract level interactions and provide developers with REST APIs to trigger actions on Immutable zkEVM.

SDK​

The Immutable SDK is the simplest to use and provides abstracted, purpose built interfaces for interacting with the Immutable platform.

Here’s a comparison table

 IntegrationBenefitsConsiderations
JSON-RPC
  • Most developers will use tooling that abstracts these interactions
API
  • Built-in HTTP features make integrating with existing web infrastructure easier
  • Familiar development using REST APIs
  • Standard mechanics (reading blockchain data)
  • Functionality determined by available endpoints
SDK (Recommended for most developers)
  • Easiest to integrate
  • Includes common workflows (eg trading) that abstract API and smart contract interactions
  • Functionality determined by available languages

Client-side vs. Server-side architecture​

The type of application you are integrating will determine the type of technical architecture that is needed. While there is no one-size-fits-all approach to determining the optimal architecture for your application, a few common client-side vs. server-side responsibilities are listed below to help illustrate the advantages and disadvantages of both approaches.

Client-side applications​

For simple applications or games, an application that’s entirely on the client-side can be sufficient as the blockchain component can serve as the ‘backend’. However, while this is the most simple application to create, there are limitations on how complex or performant this application can be as blockchain usage is expensive.

Examples of the most common client-side features would be:

  • Self-custodial wallet integrations (e.g. Passport, Metamask) - in these cases, the private key remains on the client-side and is not sent to the server. These wallets sign transactions on the client-side and then relay them to the blockchain for execution.
  • Simple zkEVM contract interactions - e.g. sending transfer transactions directly from the client to the smart contract. Note: while it’s possible to encapsulate complicated blockchain transactions in smart contract functions, performing unnecessary computation in smart contracts often leads to higher gas costs and thus a poor user experience for players or users.

Server-side responsibilities​

For most games, a server to process game logic and more complicated interactions is often necessary as this is significantly cheaper than performing these operations on the blockchain. Some common examples for server-specific responsibilities are below

  • Account management (e.g. game-specific accounts - often linked to a wallet address - that include players' credentials, in-game transactions, achievements)
  • Storing large blobs of data and keeping a hash of it on-chain
  • Usage of third-party software / off-chain applications (e.g. CoinGecko APIs for trading pair information, sending emails based on blockchain events)
  • Indexing engine for smart contract events - while you could entirely use blockchain services for this, utilising a server for search capabilities and then validating the data on-chain would lead to greater performance