Content
@
https://warpcast.com/~/channel/miniapps
0 reply
0 recast
0 reaction
artlu π©
@artlu
please try Seymour πͺ΄, a mini app to explore emergent sub-feeds: - user follows 5k+ accounts, but is mostly interested in casts+replies from the 37 accounts they like (liked) the most - new users get highlighted too! when someone you like interacts with a new account, shows up as a reply bump no matter how deep in the thread reply "Do Me Please" and my listener will (eventually) produce your personalized feed (if you have mutes/blocks, pls lmk. haven't automated it yet, although the backend is ready)
7 replies
8 recasts
29 reactions
artlu π©
@artlu
also hmu if you want to share war stories. this mini app uses my new custom Snapchain backend. Trying a completely new stack because my old go-to blasted through multiple providers' allocations in just a few days of testing (Neynar, Cloudflare, Turso). I've swapped or refactored everything
1 reply
0 recast
6 reactions
Kasra Rahjerdi
@jc4p
you doing direct data pull from snapchain over http/gRPC or you ingesting data and storing it in a structured db?
1 reply
0 recast
2 reactions
artlu π©
@artlu
Mostly direct -- pulling last ~500 casts from accounts of interest, caching the blobs for 7 days, plus a very thin sql layer with timestamps. Refreshes are tuned to be as snappy as possible without hitting rate limits: Chunk into 20 parallel requests; wait for all to complete before sending the next batch (rather than machine gunning it). Hitting just one rate limit slows things down a lot. I've got exponential backoff but the ones already in flight kinda keep slamming the APIs. This stops working well around 50 or 60 accounts. I have a slow refresh loop to catch these. WDYT?
1 reply
0 recast
3 reactions
Kasra Rahjerdi
@jc4p
define pulling β HTTP or gRPC?
1 reply
0 recast
1 reaction
artlu π©
@artlu
http. should I be using grpc?
1 reply
0 recast
1 reaction
Kasra Rahjerdi
@jc4p
with grpc u can pull every cast every made by every user in ~60 min if you pull from a node same machine as the snapchain server
1 reply
0 recast
2 reactions
Samuel γ
@samuellhuber.eth
sounds like something @runninyeti.eth can do well for y'all
1 reply
0 recast
2 reactions
artlu π©
@artlu
my observation only: the community hasn't found a viable funding model for Brock's level of SLA. Even better funded operations like Airstack felt the need to pivot. And let's say he donates part of the cost out of pocket. Where's everyone left when that is no longer viable? my little toy project targets a lower cost of running, with the availability + completeness tradeoffs required to slash costs. For a mini-app to run forever onchain and onhub, *my opinion only* it needs income > costs. One has to go up and the other one down. I'm pretty sure you agree, the current cost of keeping a mini app running is mostly subsidized by devs' anticipation of future scale
1 reply
0 recast
2 reactions
Brock
@runninyeti.eth
I feel all of this π As a related aside, this infra isn't going anywhere. We're ~1 solid customer from being back to cash flow neutral And FC is <1% of the overall costs -> will likely run indefinitely. As far as infra goes, FC data is a drop in the bucket compared to any other open data set What sets us apart from say an Airstack is we don't serve APIs -> meaning we don't have the databases overhead that everyone else does. By leaning into distributed compute, our costs are near negligible even at small scales
0 reply
0 recast
1 reaction
