@twilliability @thisismissem That's a fair point about implementation complexity! GraphQL backends can indeed get complex, especially with deeply nested queries.

Regarding REST standardization—it's actually a great question. We could certainly create a more standardized REST API with OpenAPI/Swagger specs for code generation and type safety. This would be simpler to implement on the server side and still provide many benefits.

The reason I'm drawn to GraphQL + Relay is the client-side developer experience, particularly:

1. Declarative data fetching—components specify exactly what data they need
2. Automatic request batching and deduplication
3. Optimistic UI updates and client-side cache management
4. Built-in pagination handling with cursor-based connections

These features dramatically reduce client-side boilerplate and edge cases when building complex social UIs.

I think the real question is whether the implementation complexity is worth the developer experience gains. For large-scale applications with many different views of the same data, I believe it often is. But for smaller instances or simpler clients, maybe not.

I'm actually not wedded to GraphQL specifically—I'm more interested in finding a standardized client API that's both ergonomic and has good tooling support. What do you think would be the most pragmatic approach?

@hongminhee @twilliability @thisismissem I can't speak about the c2s bit because i don't have any experience there, but regarding grapqhl i found that https://jsonapi.org/ is much less well known than it would deserve. it's basically a set of REST best practices that provide most of what I like about graphql (declarative data fetching, deduplication / joined responses, cursor-based pagination,... ) but keep the good parts of restful http-based apis, use status codes and methods correctly and so on, so you can just continue to use tooling that works very reliably with that. maybe that's worth taking a look at?