How to use GraphQL for enterprise applications

A short introduction before my question:

I am currently in the planning stage of developing an enterprise application where there are many services each with a huge amount of business logic.

I was recently introduced to and asked to incorporate GraphQL

I frankly don't see the point. It seems like a wrapper over a database. If we write what data we want in a declarative way, GraphQL gives us the data in a neat JSON format. To me it makes no difference to a proper NoSQL query.
JavaScript heavy applications are less secure due to business logic presented to client browser where it can be tweaked to change the behavior. GraphQL tends to rely on such applications where the front end directly communicates with the data. Where as traditional NoSQL queries can run from a server after obtaining required information from the client.

Question:

If GraphQL directly obtains the data from the database and presents it, how can I implement GraphQL to handle middleware tasks, business logic like back-end validations, complex business checks, batch processes etc? If not, then is it just a Declarative library on top of database queries?

Solution

If GraphQL directly obtains the data from the database and presents it, how can I implement GraphQL to handle middleware tasks, business logic like back-end validations, complex business checks, batch processes etc?

GraphQL doesn’t directly obtain the data from the database. The GraphQL implementation is exposed via an endpoint that is no different than any other endpoint, meaning that you can use any middleware, authentication stacks, validation, etc. that you want. It’s also database-agnostic. So again, you can use whatever combination of database, ORM, etc you want.

If not, then is it just a Declarative library on top of database queries?

Not quite. There are two main parts of a GraphQL implementation - the schema and the resolvers. The schema simply defines the shape of your data and the resolvers do the heavy lifting. The resolvers are the layer of logic that defines how to fetch and transform the data for every field defined in the schema. More on resolvers below.

How is it different than using a NoSQL database?

The main selling point of GraphQL is that is lets the consumer define exactly the data that they need. For flat (i.e. non-nested) data, this might not be a big deal. But it becomes more and more of an advantage when you start dealing with more heavily-nested data. For example, let’s say you have a GraphQL query that looks like:

query {
  user(userId: "some_user_id") {
    ...userData
    projects {
      ...projectData
      assets {
        ...assetData
      }
    }
  }
}

We’re fetching a user, the projects for that user, and the assets for each of those projects and we can specify exactly what fields we want at each level. A user may have 15 fields, but maybe we only want two or three of them. The same may go for projects and assets. Since GraphQL resolvers are smart, we don’t have to worry about which fields are actually requested in any given query. Only the fields requested as part of the query will be returned. And if a field is resolved via an asynchronous function, that function will only be executed if that field is requested.

In the end, the client gets back JSON that matches the shape of the query, but (I hope) we would never store nested data like this in a NoSQL database. There are also tools like dataloader that make it easier to optimize queries via batching and caching.

GraphQL tends to rely on such applications where the front end directly communicates with the data.

As you can gather from above, this is not the case.