Moralis Nitro Upgrade
We have quite a big update to Moralis.
This update will improve the performance and reliability of Moralis infrastructure.
It also has a few new features.
How to test
Go to https://beta.moralis.io
Login with your normal moralis account
Create new beta server with branch that has public core services in the name
Wait for the server to startâŚ
Read the To Test sections in this post and follow them.
Report your feedback as comments in this thread.
What to test
Performance improvements
Most of the changes are behind the scenes improvements that have to do with how smart contract events and user transactions are synced.
To test: sync smart contract events and user addresses and ensure all data syncs
Token Balances and NFT Owners removed
We noticed that most developers are using Moralis.Web3API to get token balances and nft owners. Therefore these tables will be removed from the database as itâs a heavy job for the server to track token balances and nft owners. Instead API should be used to fetch this data.
You could for example fetch user nft balances and token balances each time they login or do a Job that does it regularly and puts the data into the User row in the database.
Better default settings (not yet implementedâŚ)
Before Moralis Nitro we synced all user transactions into the database when a user signs in.
This created some issues with many new users logged in at the same time and user historic sync was enabled. If 1000 users sign up with 100 tx each - server needs to handle 100k transactions all at once. While we always had a setting in the dashboard to turn this off weâve noticed that some dapps missed to set that setting resulting in downtime when many users signed up all at once and in most cases the developer didnât even need full user history.
Now with Moralis Nitro only 50 user tx for each category (native, token, nft) and chain are synced.
And this can be adjusted in the admin settings for the particular server.
To test: Sign in a user - only 50tx for each category for each chain should be synced. Try to adjust this in server settings to some other number.
Smart contract event filters
beforeConsume function is now deprecated and removed.
Instead when you setup a smart contract event sync you can specify logical conditions that will give you only events that comply with the conditions.
For example the filter below will only sync event instances where the variable price is equal to 80000000000000000:
{"eq": ["price", "80000000000000000"]}
Below are some more filter examples. You can set conditions for any variable in the event.
If sender = 0x0 AND receiver = 0x0
{
"and": [
{ "eq": ["sender", "0x0"] },
{ "eq": ["receiver", "0x0"] }
]
}
If sender = 0x0 OR receiver = 0x0
{
"or": [
{ "eq": ["sender", "0x0"] },
{ "eq": ["receiver", "0x0"] }
]
}
If (sender = 0x0 AND amount = 1000 ) OR (receiver = 0x0 AND amount = 100 )
{
"or": [
{
"and": [
{ "eq": ["sender", "0x0"] },
{ "eq": ["amount", "1000"]}
]
},
{
"and": [
{ "eq": ["receiver", "0x0"] },
{ "eq": ["amount", "1000"]}
]
}
]
}
If an event has wei denominated values you can use <name>_decimals fields to run comparisons (like gt/lt):
{
"and": [
{ "eq": ["sender", "0x0"] },
{ "gt": ["amount_decimals", "1000"]}
]
}
To test: try to sync a smart contract event with filters
Wei numbers are stored as numbers (not only strings)
When syncing transactions and smart contract events - all onchain numbers are represented as wei 256 numbers which donât fit in traditional databases which meant that before Moralis Nitro update all such number were stored as strings in Moralis DB. This made it impossible to sort, sum, aggregate or run other queries such as LT or GT.
With Moralis Nitro - all events and transactions have a decimal column for each wei number where the actual decimal number is stored representing the wei value.
So for example if 10 ETH was transfered in a transaction Moralis would previously only show the wei value as a string. While now we also include â10â as a sortable and queryable number.
Example below:
To test: either sync smart contract events that have wei values or user transactions and see that decimals are represented correctly.
Note: the decimal value can only hold 128 bits - meaning that everything above 34 characters long will lose precision. For exact 256 bit precision - use the string values.
For example:
256 original wei string: â12345678901234567890123456789012334567890â
128 decimal number: 12345678901234567890123456789000000000000
As you can see the decimal value will lose precision - but for most use-cases that include sorting/aggregation/LT and GT queries still would do the job
The beta servers may get removed at any time during the beta.
Donât get surprised if your server disappears.
We need to remove them in case we have a breaking change or see some fatal errors.
