Bringing a project to life needs a clear plan. You start by thinking about the features you want and get into the nitty-gritty details. When you have a clear picture, implementing the project becomes much smoother. A big part of this involves figuring out how to handle the data – what it looks like, how it's connected, and what events it triggers. This is the basic foundation for any tech product, no matter how fancy or important.

Most of the time, the focus is on the data and its relationships, which then generates more data. The rest, like creating a great user experience, builds on top of that. Every product is essentially a game played with data, even the really complex ones.

To turn your ideas into reality, everyone involved – UI designers, UX designers, and developers – needs to understand the data and how it's connected. This understanding is especially crucial for building complex applications dealing with a lot of data. Graphs become handy tools for creating a mental map of how your data is related, leading to better user design and experiences.

GraphQL Schema is like a common language that helps everyone on the team be productive and clear right from the beginning. There's a whole ecosystem supporting your journey in modeling data. GraphQL Schema acts as this shared tool that guides the development of features from the initial idea to the final product, making sure everyone is on the same page. Let's explore the world of Schema-driven development together.

Schema:

You can start writing your schema/data model in just as fast as you would describe data structure in English language. The key aspects is to define the data by naming them with context of actually what it represents. We start by defining a node like User;

type User{
id:ID!
name:String
email:String
friends:[User]
isEighteenYearsOld:Boolean
}

and you can define relationships across entities, which actually is the business logic.

Example:

Consider a basic Expense Share Tracker app, that tracks share of expense among friends, what you would want is to track every expense, who paid for it ,how much and who were part of that transaction. So this boils down to this schema of any transaction

type Transaction{
id:ID!
description:String
amount:Number
sharedInto:[User]
paidBy:User
}

Using a codegen tooling

You can generate a graphql API, with codegen tooling, be it codegen tools by the-guild.dev or a complete backend solution like Hasura or dGraph.

You can have the API up and running very quickly that matches each and every requirement of your app, like this one.

generate API: all the basic queries and mutations

---------
getUser ( id ID! ) User
ADD QUERY
queryUser ( filter UserFilter, order UserOrder, first Int, offset Int ) [User]
ADD QUERY
aggregateUser ( filter UserFilter ) UserAggregateResult
ADD QUERY
getTransaction ( id ID! ) Transaction
ADD QUERY
queryTransaction ( filter TransactionFilter, order TransactionOrder, first Int, offset Int ) [Transaction]
ADD QUERY
aggregateTransaction ( filter TransactionFilter ) TransactionAggregateResult
----------
addUser ( input [AddUserInput!]! ) AddUserPayload
ADD QUERY
updateUser ( input UpdateUserInput! ) UpdateUserPayload
ADD QUERY
deleteUser ( filter UserFilter! ) DeleteUserPayload
ADD QUERY
addTransaction ( input [AddTransactionInput!]! ) AddTransactionPayload
ADD QUERY
updateTransaction ( input UpdateTransactionInput! ) UpdateTransactionPayload
ADD QUERY
deleteTransaction ( filter TransactionFilter! ) DeleteTransactionPayload

Iteration cycle: Design Drives Schema

Product development cycles thrive when there's a swift iteration process, translating requirements and clarity into a schema promptly.

There's a delay in frontend development, but diving deep into detailed discussions about requirements during the design iteration phase can be incredibly beneficial. This process involves translating those requirements into a schema. The payoff is worth it! Building the user interface becomes a breeze when you use a typed GraphQL schema and generate corresponding APIs. Naming variables becomes more meaningful in context, and the entire development experience becomes solidly end-to-end typed, providing a fantastic experience for developers.

Do share relevant blogs in the comments if you have some different processes followed in your product cycle. Thanks