• taylodl 16 hours ago |
    Poor schema design?

    Here's my take: anytime a client requires knowledge of your DB schema is a #fail. That's an extremely brittle architecture that's destined to provide years of problems.

    This is why CQRS exists. Copy the contents of your database to another database that's optimized for query and retrieval. It has the added benefit of a deluge of queries won't impact operations utilizing the source database. Also, the source system can modify the schema all they want without impacting tens, hundreds, or thousands of clients. You can distribute it, shard it, do whatever you need to do to make it fast and efficient - all without affecting the source database.

    That is how you solve this problem. Once you've done that, GraphQL just becomes one of many ways that a client can use to access the data, depending on the data management toolset you're using.

    • jdauriemma 15 hours ago |
      I think you might be operating under some incorrect assumptions.

      > anytime a client requires knowledge of your DB schema

      GraphQL is very explicitly _not_ a representation of your database schema. The “schema” being referred to here is the GraphQL schema, not the SQL schema. I might be missing some nuance in your comment, but I do think this is a very important point to drive home.

      • taylodl 14 hours ago |
        All too often the GraphQL schema reflects the underlying database schema. After all, the database schema works, right? Of course, this isn't recommended practice, it's just what ends up happening.
  • pestatije 13 hours ago |
    well if thats the case, theres your problem: GraphQL schema design is broken
    • jdauriemma 10 hours ago |
      I think API design in general is hard to do well, GraphQL isn’t going to help or hurt that.