@nickcherry what stack is the Warpcast web app using? Would love to hear about design decisions etc

cma.xyz. Founder /paragraph, ceo /mirror, previously at Google & Coinbase 

Knowing that we would want OpenGraph support and eventually SEO, we seriously considered SSR solutions like Next and Remix. Ultimately, though, we felt that they introduced a fair amount of complexity with relatively little upside – the biggest benefit being "free" server-side rendering for OG and SEO.

Ultimately, we ended up implementing a simple Next server (opting for the framework just for convenience of having out-of-the-box support for JSX) to live in parallel with the web app, which is all just client-side rendering. We configure Cloudflare to look at the incoming user agent, and route to the appropriate site

For example, a request for @dwr.eth's profile from TwitterBot will go to https://ssr.warpcast.com/dwr, which will server-side render OG meta tags and some very basic HTML for SEO. All non-bot traffic will just get served https://warpcast.com/dwr. This approach adds some maintenance burden, but the benefits are

that 1) the main web app isn't burdened with additional complexity relating to SSR, 2) almost all incoming requests just require us to serve static assets, and 3) a separation of concerns between OG/SEO logic for robots and an actual web app for humans

The web app itself is just CRA. I would have loved to use something like Vite, but I couldn't get a basic app running in the context of our monorepo with the dependencies we already have / will need. Hopefully in the future we can migrate to something faster + more modern without needing to touch any client code

A CSR solution was simpler and I would argue potentially more performant, but we still needed to solve the OG problem. We considered outsourcing the server-side rendering to someone like prerender.io, but we didn't love the idea of relying on a third-party, particularly when our product reqs weren't that demanding.