@hongminhee洪 民憙 (Hong Minhee) also keep in mind that to securely do graphql it is complex, because of query complexity, persisted queries, field resolver reuse, etc (I've worked on several large graphql projects)

Another oft cited tool in the JSON-LD world is SPARQL which theoretically solves thing, but everyone I've met typically hates it or loves it, but implementation tend to be slow due to inefficiency on the network

@thisismissemEmelia 👸🏻 You're right that C2S doesn't provide efficient ways to fetch common app views like chronological feeds or pending follow requests. That's exactly why I think we need something better designed for client use cases.

Regarding GraphQL complexity—that's a valid concern. I've also worked with GraphQL in production, and security, performance, and complexity management are real challenges. However:

  1. We could define a standard schema with best practices built-in
  2. Many of these challenges have established patterns now (depth limiting, persisted queries, etc.)
  3. Server implementations could share common GraphQL middleware for security

The key advantage would be that clients wouldn't need to implement the heavy processing themselves, as the server would handle the data shaping via resolvers.

As for SPARQL—interesting alternative! It does have performance challenges as you mentioned. My thinking is that GraphQL has much wider adoption and tooling, which might make it easier for developers to work with.

What I'm really seeking is something that combines ActivityPub's federation capabilities with a more client-friendly query interface. Do you have other ideas that might achieve this balance?

0

If you have a fediverse account, you can quote this note from your own instance. Search https://hollo.social/@hongminhee/0196cd40-57f7-72bc-a7b3-4908c810e7b2 on your instance and quote it. (Note that quoting is not supported in Mastodon.)