Question regarding Moralis dApp design (e.g. Marketplace Example)

Moralis General
#1

Hello. I have a couple questions regarding the architecture of using Moralis with dApps. The marketplace boilerplate is a good example to use for the questions.

In that example, the Moralis DB is syncing the “MarketItemCreated” event, which makes sense. The part I’m struggling with is when someone purchases a marketplace item, it appears that the dApp itself attempts to update the database by setting that object “MarketItemCreated” to sold. Is this really a robust strategy? What if the client crashes or closes right after the transaction is started? What if someone does a direct contract interaction to purchase an item? Won’t the dApp be out of date then?

It seems like a better strategy would be to process “MarketItemSold” event from the server side directly from the blockchain and update the database accordingly. That way it doesn’t depend on the dApp to update anything.

Am I totally off base here, or maybe missing something? If not, is there a way to design Moralis backend as stated above (use another event to update database)?

Thanks!

#2

I am not sure how this exact project is built exactly, but it would be good practice here to update the table based off another event listener (for when an item is sold), not from frontend

#3

Yes it would be better to do that. It looks like if an NFT is sold according to MarketItemSold, it isn’t used anywhere else in the app to reflect the new status, so it’s dependent on the app handling a separate out of sync update of the listing.

A solution is to watch these events from your server and then when they are added (using webhooks), update the data in another unified table/Class accordingly to represent the current, true state of each listing.

#4

Thanks for the responses. Yeah, I guess I’m just wondering if there is a robust strategy for this that Moralis recommends. Webhooks is an option, or using cloud functions, but neither of those seem like they would be ideal for a high volume of events.

I like a lot of the stuff Moralis has done, and many things are made very simple, but tbh this is the primary reason I haven’t used Moralis for projects. I just can’t see how it would work efficiently if any of the projects started to see large volume. Nearly every project I’ve worked on has needed to get “state” information, not just events, and relying on cloud functions to process every event doesn’t seem very practical long term. I know Moralis on the backend can do this because they do it for NFT and ERC20 ownership, but unfortunately it doesn’t appear like there’s any way to implement it natively with custom information (like marketplace listings).

Anyway, thanks for any input.

#5

To be fair, this complication is only within the context of this boilerplate in terms of getting on-chain data and how it is set up in the app.

“state” information

What do you mean by state info?

relying on cloud functions to process every event doesn’t seem very practical long term

You can certainly use your own backend for listening to events. Why would you say it doesn’t seem practical? Using events outside of contract calls is an easy way to get and interpret on-chain data.

I know Moralis on the backend can do this because they do it for NFT and ERC20 ownership, but unfortunately it doesn’t appear like there’s any way to implement it natively with custom information (like marketplace listings).

I’m not sure what you mean here. All custom events i.e. not common standard ones like Transfer need to be handled differently or manually.