How to monitor factory contract instances using Streams?

Moralis General
#1

Hey guys,

How can we monitor new instances of our implementation contract using Moralis streams? I assume this would involves adding a new stream for the factory instance in the cloud code using afteSave, however I’m not entirely sure about the workflow and would love some clarification.

All the new instances would have the same abi, in case that would make it easier to monitor.

In the Moralis Hosted servers, I used the core_addEventSync function which worked like magic. I’m hoping there’s something similar I can use for Streams.

Thanks!

#2

with streams there is the option to listen to all addresses that can be used, but that option is available only to business and enterprise plans

with that option you specify the abi and the topic and you will receive webhook for any address

you can also use a normal stream and add the contract address to the stream after it was deployed

#3

you can find the documentation here

you can do all programmatically for streams api, to create a stream, to add an address to a stream

you can also use the swagger directly: https://api.moralis-streams.com/api-docs/

#4

Awesome. When creating programmatically, how to specify you want to listen to all addresses for a particular ABI?

#5

Also, when setting up the stream (which listens to all events for the contract), what is the best workflow to go with? Should I create multiple streams (one per event) and separate webhook for each event, and accordingly process the data or would you recommend another way?

I want to have a good understanding of the workflow before getting the business plan.

#6

it is better to create a single stream, you can add set multiple topics for the same stream, and also add multiple addresses to that stream

listening to all addresses is only a parameter for when you create the stream

#7

I need to update different tables based on the event. How will that work if all events stream to the same webhook?

#8

You would need to process the event data coming in and update each table accordingly.

1 Like
#9

I’m getting the data streamed successfully, but I’m not sure how to process it according to each event. I can’t find one individual identifier(unique to event emitted) in the data which will allow me to update different tables based on event emitted.

#10

@alex

The only unique identifier is topic0, which means I would have to first manually emit each event, note down the topic0 for each, and then process data using ‘if’ statements, which seems kind of clunky.

#11

the address that emits the event will not be different?

#12

No, all events are from the same address. I need a different table for each event.

#13

usually when you have a factory contract, you want to get the events from the deployed contracts, it is different here?

#14

Yes, I want to get events from deployed contracts. However, i want the info from each event from the deployed contracts to be put into different tables. I’d like to segregate my data based on events of the deployed contracts, not the addresses. core_addEventSync did exactly this.

#15

I assume in this case the best way to go about it would be different webhooks for each event, right?

#16

It may be a confusion somewhere, core_addEventSync uses only a table for every event sync that is added

An event from a different contract will have a different address (the address from were the event is emitted)

#17

@cryptokid

I got it to work. I don’t think I did a good job at explaining what I wanted clearly. I didn’t really care about which contract the event was coming from. What I wanted to do was have individual tables for every single event of my implementation contract.

That way, every time the particular event is emitted from a cloned contract (regardless of address), the particular table (based on the event) is updated in the database.

I did this by creating different webhooks and streams for every topic, and by creating a different updateDatabase() function for each webhook. That way, I now can update every table with parameters specific to the event, by processing data based on the event and accordingly updating it in the specific table.

Hope this is not more confusing :slight_smile:

#18

you have the topic in this case that you can use to differentiate

1 Like
#19

Yep. Going to try that approach out. Will make things more streamlined.