Varun Srinivasan
@v
Farcaster Dev Call starting in 5 minutes! https://events.xyz/48b4e0
5 replies
5 recasts
26 reactions
Jorge Pablo Franetovic 🎩
@jpfraneto.eth
question: im creating a client, and i only want to display through this client the casts that have been written to it. im thinking on adding a database layer that acts as a wrapper of the farcaster data, but im wondering if there is a more efficient way to do it or maybe some sort of compartimentalization of data that can be helpful in the future (thinking of channels that will have their own apps and probably won't care too much about the protocol as a whole) wdyt? cc @horsefacts.eth @deodad
2 replies
0 recast
5 reactions
Tony D’Addeo
@deodad
yea most clients will replicate data from hubs into a database there's an open source package called shuttle that can help with this https://github.com/farcasterxyz/hub-monorepo/tree/main/packages/shuttle it doesn't support indexing a subset of data so you could either modify it to support this or replicate all data into the database and then index the subset you want for powering your client
1 reply
0 recast
1 reaction
Harris
@harris-
If you were fetching the casts eg for only your fid and knew the fid in question you could in theory store all of the casts as very simple serialization to the protobuf bytes. Maybe even throw on some kind of timestamp index to know what to fetch from the next time you sync? You could store all user info objects in an LRU cache or something that polls every now and then for users it's missing when it encounters them maybe. Lazily fetch the casts that are responses to specific casts when you navigate to their detailed view or something. Idk at what level of recursion you stop storing information though probably up to you and how light you want the client to be. In theory with a hub connection you might not even need to store any info to disk just cache what you need 👀
1 reply
0 recast
0 reaction
