Updating citations as requested (graphql#1005)

src/content/faq/BestPractices.md

@@ -73,4 +73,4 @@ GraphQL servers are able to handle errors by default, both for syntax and valida
 
 **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.
 
-**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. It requires less effort to use because, in contrast to the schema-first approach, it doesn’t depend on an excessive amount of tooling.
+**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.

src/content/faq/GettingStarted.md

@@ -65,8 +65,6 @@ For more information on caching using GraphQL, check out our [documentation](/le
 
 **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.
 
-**Overkill for small applications** : While GraphQL is the right solution for multiple microservices, you’d better go for REST architecture in case of a simple app. REST can be also a valuable approach for connecting resource-driven apps that don’t need the flexible queries offered by GraphQL.
-
-**GraphQL Query Complexity** : Don't mistake GraphQL as a replacement for server-side databases. It is just a simple 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 single time. So there must be a mechanism like maximum query depths, query complexity weighting, avoiding recursion, or persistent queries to stop inefficient requests from the client-side.
+**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.
 
 For more information on querying in GraphQL, check out our [documentation](/learn/queries/).