Determining your integration model
- 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
Integration | Benefits | Considerations |
---|---|---|
JSON-RPC |
|
|
API |
|
|
SDK (Recommended for most developers) |
|
|
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