Updating typos and best-practices section (graphql#1005)

src/content/faq/BestPractices.md

@@ -65,12 +65,40 @@ One concern people have with this architecture is that the GraphQL gateway looks
 
 ### How can I do error handling?
 
-GraphQL servers are able to handle errors by default, both for syntax and validations errors. You've probably already seen this when using GraphiQL or any other playground to explore GraphQL APIs. But often the default way is not sufficient for more complex situations or to sophistically handle the errors from a frontend application.
+GraphQL servers are able to handle errors by default, both for syntax and validation errors. You've probably already seen this when using GraphiQL or any other playground to explore GraphQL APIs. But often the default way is not sufficient for more complex situations or to sophistically handle the errors from a frontend application.
 
-**GraphQL Error Object** : Error handling is described in the GraphQL specification and is part of the default structure of any GraphQL response. This response consists of 3 fields, The `data` field containing the result of the operation, The `errors` field containing all the errors that occurred during the execution of the operation and an optional `extensions` field that contains meta data about the operation
+**GraphQL Error Object** : Error handling is described in the GraphQL specification and is part of the default structure of any GraphQL response. This response consists of 3 fields, a `data` field containing the result of the operation, an `errors` field containing all the errors that occurred during the execution of the operation, and an optional `extensions` field that contains meta data about the operation.
 
 ### Schema-first or code-first?
 
-**Schema-first** indicates that we first define the schema for the GraphQL service and then we implement the code by matching the definitions in the schema. To code the schema, we use the [Schema Definition Language (SDL)]('https://www.howtographql.com/basics/2-core-concepts/), a syntax created to represent the GraphQL data model. Because of this, this approach may also be called SDL-first. It resembles doing test-driven development (TDD) because developers must consider the different use cases. It follows the dependency inversion principle (DIP), which makes the solution more abstract and less tied to dependencies.
+GraphQL schema is a set of rules describing the functionality available to the client, including specification of operations (queries and mutations) that can be executed to execute against your data source. If you ever decide to build a GraphQL service at some point you would need to chose which approach you want to go with. In either case, we will end up with a fully functional GraphQL service, but this choice will influence your project in terms of the amount of work you will need to put to achieve certain things like scaling your project etc.
+
+**Schema-first** indicates that we first define the schema for the GraphQL service and then we implement the code by matching the definitions in the schema. To code the schema, we use the [Schema Definition Language (SDL)]('https://www.howtographql.com/basics/2-core-concepts/), a syntax created to represent the GraphQL data model. Because of this, this approach may also be called SDL-first.
+
+**PROS**
+
+It resembles doing test-driven development (TDD) because developers must consider the different use cases.
+
+It follows the dependency inversion principle (DIP), which makes the solution more abstract and less tied to dependencies.
+
+It reduces development time by allowing frontend and backend teams to work simultaneously.
+
+**CONS**
+
+Reusing SDL definitions may involve a lot of boilerplate and repeated code.
+
+Ensuring that the schema definition is in sync with the resolvers at all times.
+
+Composing a number of existing (and distributed) schemas into a single schema.
 
 **Code-first**, indicates that we start by coding the resolvers, and then, from code as a single source of truth, we have the schema generated as an artifact. Thus, we still have a schema, but instead of being manually created, it is created through running a script. This approach may also be called resolver-first.
+
+**PROS**
+
+It can work as a single source of truth as it keeps stored both the schema definitions as well as resolvers.
+
+It offers better manageability if you expect your schema to grow in complexity or size.
+
+**CONS**
+
+Having both the definitions and resolves might be less readable.

src/content/faq/General.md

@@ -59,4 +59,4 @@ You can find out more by visiting [foundation.graphql.org](https://foundation.gr
 
 ### Does GraphQL only work with graph-like structures or data sources that are graph-based?
 
-No, The "graph" in GraphQL is only used to represent the graph-like structure of data. It's a misconception that you need to rewrite your database to adopt GraphQL. There is no limitation in the GraphQL ecosystem that enforces that the data source should be a graph. GraphQL can be a wrapper around any data source. GraphQL is a query language for your API which means it is a syntax of how to ask for data.
+No, the "graph" in GraphQL is only used to represent the graph-like structure of data. It's a misconception that you need to rewrite your database to adopt GraphQL. There is no limitation in the GraphQL ecosystem that enforces that the data source should be a graph. GraphQL can be a wrapper around any data source. GraphQL is a query language for your API which means it is a syntax of how to ask for data.

src/content/faq/GettingStarted.md

@@ -59,11 +59,11 @@ For more information on graphql2chartjs, check out their [documentation](https:/
 
 Although GraphQL has negligible downsides over its upsides, here are some downsides of GraphQL.
 
-**GraphQL Caching** : It is complicated to implement a simplified cache with GraphQL than implementing it in REST. In REST API, we access resources with URLs, so we can cache on a resource level. On the other hand, In GraphQL, it is very complex because each query can be different, even though it operates on the same entity. But most of the libraries built on top of GraphQL offer an efficient caching mechanism.
+**GraphQL Caching** : It is complicated to implement a simplified cache with GraphQL than implementing it in REST. In a REST API, we access resources with URLs, so we can cache on a resource level. On the other hand, in GraphQL, it is very complex because each query can be different, even though it operates on the same entity. But most of the libraries built on top of GraphQL offer an efficient caching mechanism.
 
 For more information on caching using GraphQL, check out our [documentation](/learn/caching/).
 
-**File uploading** : Since GraphQL doesn’t understand files, a file uploading feature is not included in its specification. You won’t have to deal with this limitation in case of REST, as there you can POST or PUT whatever content you want to. To allow file uploads in your GraphQL web app, there are several options, using Base64 encoding, making a separate API endpoint just for this purpose, using a library like Apollo for implementing the GraphQL multipart request specification.
+**File uploading** : Since GraphQL doesn’t understand files, a file uploading feature is not included in its specification. You won’t have to deal with this limitation in case of REST, as there you can POST or PUT whatever content you want to. To allow file uploads in your GraphQL web app, there are several options: using Base64 encoding, making a separate API endpoint just for this purpose, or using a library like [Apollo](https://github.com/apollographql/apollo-server) for implementing the GraphQL multipart request specification.
 
 **GraphQL Query Complexity** : Don't mistake GraphQL as a replacement for server-side databases. It is just a query language. When we have to access multiple fields in one query whether it is in a RESTful architecture or GraphQL, the varied resources and fields still have to be retrieved from a data source, so it also shows the same problems when a client requests too many nested fields data at a time. Mechanisms like maximum query depths, query complexity weighting, avoiding recursion, or persisted queries help to stop inefficient requests from the client-side.