Content
@
0 reply
0 recast
0 reaction
Darryl Yeo đ ď¸
@darrylyeo
In 2024, I continued to solo-build @blockhead (/blockhead), an open-source interface for tracking onchain assets, exploring EVM chains and browsing web3 protocols! Feature highlights: ⢠15 new user-swappable data sources in Preferences ⢠NFT valuations in Portfolio ⢠EIP-6963 wallet discovery ⢠Apps and app views filterable by network ⢠experimental dynamic OpenGraph images and Farcaster Frames (v1) ⢠indexer/algorithm-agnostic @farcaster client using @airstack.eth @neynar @openrank @pinata @mod ⢠infinite scrolling ⢠icons in dropdown menus ⢠/eas schema and attestation explorer ⢠real-time block height visualizations for EVM chains in Explorer ⢠@moxie.eth auction, order and subject explorer ⢠transaction traces, input data and summaries in Explorer ⢠linked ENSIP references in @ensdomains explorer ⢠price feeds and historical price charts in Explorer / Apps ⢠most content sections retrofitted to be collapsible ⢠improved wallet connection management https://blockhead.info
3 replies
5 recasts
27 reactions
Darryl Yeo đ ď¸
@darrylyeo
The year was also not without opportunities to stretch frameworks to their limits and test new state-of-the-art tools across the JavaScript and TypeScript ecosystem! Technical highlights: ⢠1378 atomic Git commits ⢠extended SvelteKitâs server and routing functionality to handle Farcaster Frames v1 endpoints and generate OpenGraph images using `satori` and `resvg` (eventually forming the basis of skiffle.dev) ⢠adopted `gql.tada` (gql-tada.0no.co) for generating type-safe GraphQL queries in TypeScript (replacing houdinigraphql.com) ⢠adopted `dotenvx` (dotenvx.com) for secure and portable deployment-agnostic environment variables (allowing me to bypass Netlifyâs size limits) ⢠adopted `oazapfts` and then `openapi-typescript` for generating TypeScript REST API clients from OpenAPI / Swagger schemas (much leaner codegen footprint compared to `swagger-typescript-api`)
1 reply
1 recast
4 reactions
Darryl Yeo đ ď¸
@darrylyeo
It may not look like much on the outside, but I also took on some monumental refactoring and migration work behind the scenes to pave way for some new and exciting features! Codebase maintenance highlights: ⢠migrated from SvelteKit v1 â v2 ⢠migrated @viem public clients to use tree-shakable actions ⢠rewrote lots of CSS in terms of nested rules ⢠improved custom container auto-sizing and layout transitions ⢠fixed navigation issues with custom SvelteKit route parameter binding logic ⢠deprecated old components/code from previous hackathon experiments ⢠organized API clients, TypeScript types and data normalization logic into a consistent file structure ⢠migrated all queries to use TanStack Query, lazy-loaded Vite imports, pagination and client-side caching ⢠added new fields and retroactively implemented queries for each data vertical using existing APIs for maximum redundancy ⢠migrated most state management from Svelte v4 stores â v5 state https://github.com/darrylyeo/blockhead
1 reply
1 recast
4 reactions
Darryl Yeo đ ď¸
@darrylyeo
One of @blockheadâs longstanding design goals is for the frontend to work with any existing infrastructure and not be tied to any single indexer or backend. Shoutout to all the new and returning data providers, integrated permissionlessly and/or as part of hackathons over the years! ⢠@blockscout ⢠@defillama ⢠@nexandria ⢠@blockscan ⢠@covalent-hq ⢠@airstack.eth ⢠@zapper ⢠@zerion.eth ⢠Chainbase ⢠Decommas
2 replies
0 recast
4 reactions
Hector
@noctis
This is impressive, how are you solving this problem? Are you using something like an abstract class to implement a provider for Blockhead's own API ? I strongly believe that being able to use multiple providers relatively easily is the key to make an app more stable (not tied to an API). The problem I ran into doing that was that in special RPC Calls, they often use proprietary prefix to differentiate from the rest (I think the info & data structure are not mutualized too)
1 reply
0 recast
1 reaction
Darryl Yeo đ ď¸
@darrylyeo
Yes! For a given data vertical and a set of supported API endpoints (Ethereum JSON-RPC, custom JSON-RPC, REST, GraphQL or otherwise), I normalize every possible response to fit a common âshapeâ or TypeScript type. In totality you could sort of consider these to be Blockheadâs âAPIâ. The challenge Iâm anticipating next will be merging âpartialâ structures sourced from different data verticals (or even multiple API providers within the same data vertical), while preserving info about where each field originated. More research needed here, but I think what Iâm inevitably working toward is the client-side equivalent of a GraphQL server.
0 reply
0 recast
0 reaction
