Odtnhj

Context

Hi! I made something like graphql but with just Sequelize. I mean, Sequelize query options are JSON objects so, the client could send the options directly (with correct sanitization).

What I have done

Just for curiosity, I built that, and it works just fine. Now my doubt is: how bad is that?

this is an example of the client using this API

 const res = await http.post(APIs.FINDER, 
 model: 'User',
 options: 
 where: 
 id: someId
 ,
 attributes: ['name', 'active']
 ,
 include: [
 
 as: 'zone',
 attributes: ['name']
 
 ],
 order: [['createdAt', 'DESC']]
 );

nice right?

Sanitization/Constraints

About sanitization, I have to:

• check that the includes have a known limit, eg.: no more than 10 nested includes


• check that the params are not SQL strings or other hacks (Sequelize take care about that)


• don't allow Sequelize functions, just simple queries

Questions

with that in mind, I think this could be used in production.

• Have I missed something that could reject this idea from production usage? (security/usage/etc)


• Have graphql some specific feature that makes me prefer it against this custom solution?


• Would you use it in a production environment? I can't imagine why not

My thought to the questions:

1. I don't recommend this style of API. It will expose your backend implementation to the public which make you have difficulty dealing with every security conditions, not to mention the business logic and authorization. Also, it would be hard to improve your performance because the behavior is tightly coupled with the sequelize package.




2. You can consider this post: GraphQL Mutation Design: Anemic Mutations. A good GraphQL API should be driven by domain and requirement instead of be driven by data.




3. NO! I've experienced a hard time dealing with this api style.

Actually, this is not a good idea. If you are organizing an one-man full-stack project, it may seem fast in the first place, but the cost of development would skyrocket until you cannot move on. If you are working as a group, you can notice that the client side is tightly coupled with the server side, which is very bad for developing.

In the client side, it only need a finite set of apis instead of apis with infinite possibilities.

In the server side, you can do nothing but hand the data over to sequelize, which make it hard to improve your performance, to add logic layer and to introduce another database system like elastic search into your codebase.

When it comes to designing an API, you can consider Domain Driven Design which known as DDD. It's preferred to use GET Friends?limit=10 api than to use GET type: 'User", where: ..., include: ..., order: ..., limit: 10

By the way, GraphQL is not just a query language, it is a thin API layer in essence (ref). So don't use it as a JSON database but treat it as an API which focuses on the business need.

For example, here is a User model:

 "User": 
 "id": 1,
 "name": "Mary",
 "age": 20,
 "friendIds": [2, 3, 4] 
 

But in GraphQL, based on what you need, it may become :

type User 
 id: ID
 name: String
 friends: [User]
 friendCount: Int
 friendsOverAge18: [User]

You can read this great article about how to design a GraphQL API: Shopify/graphql-design-tutorial