😍A GraphQL Sqlite, sequelize Full (ok)
https://sequelize.org/docs/v7/category/querying/

Example 1 (https://github.com/gitlucaslima/zaros-crud)
— Step 1 getUsers
package.json
.env
src\server.ts
src\app.ts
src\routes\userRoutes.ts
src\controllers\userController.ts
src\controllers\Filters\UserFilters.ts
src\controllers\Interfaces\getUserInterface.ts
src\controllers\Interfaces\UserQueryParams.ts
src\mappers\mapper.ts
src\mappers\userMapper.ts
src\models\user.ts
src\config\database.ts

— Step 2 getUserById
src\routes\userRoutes.ts
src\controllers\userController.ts
— Step 3 createUser
src\controllers\userController.ts
src\routes\userRoutes.ts
— Step 4 updateUser
src\routes\userRoutes.ts
src\controllers\userController.ts
— Step 5 deleteUser
src\routes\userRoutes.ts
src\controllers\userController.ts
Practice 1
package.json
src\server.ts
src\app.ts
src\routes\userRoutes.ts
src\models\userModel.ts
src\controllers\userController.ts
src\config\database.ts
Example 2
Giống với Laravel cũng có những thuật ngữ phải nhớ
package.json
Operation.sql
index.js
rest\routes\user.routes.js
rest\routes\task.routes.js
rest\routes\project.routes.js
rest\routes\index.js
rest\controllers\project.controller.js
rest\controllers\task.controller.js
rest\controllers\user.controller.js
models\user.model.js
models\task.model.js
models\seed.js
models\project.model.js
models\index.js
graphql\typeDefs.js
graphql\resolvers.js
C:\Users\Administrator\Desktop\graphql-example\db\db.sqlite


graphql-example
GraphQL Example project for Toptal blog article: https://www.toptal.com/api-development/graphql-vs-rest-tutorial#utilize-unreal-developers-today
Getting Started
You should be able to see the app running at http://localhost:3000.
Information
The
modelsfolder contains the three models: User, Project and Task. They are created using thesequelizeORM.The
restfolder contains the logic to create the associated/api/users,/api/projectsand/api/tasksendpoints.The
graphqlfolder contains the schema and resolvers for GraphQL.db.sqlitecontains the database.index.jsstarts the Express server.
Demo
This example project is hosted on Heroku.
The rest endpoints can be viewed here
The GraphQL endpoint is http://graphql-example.herokuapp.com/graphql, and a GraphiQL interface is mounted here.
You might have heard about the new kid around the block: GraphQL. If not, GraphQL is, in a word, a new way to fetch APIs, an alternative to REST. It started as an internal project at Facebook, and since it was open sourced, it has gained a lot of traction.
The aim of this article is to help you make an easy transition from REST to GraphQL, whether you’ve already made your mind for GraphQL or you’re just willing to give it a try. No prior knowledge of GraphQL is needed, but some familiarity with REST APIs is required to understand the article.

The first part of the article will start by giving three reasons why I personally think GraphQL is superior to REST. The second part is a tutorial on how to add a GraphQL endpoint on your back-end.
GraphQL vs. REST: Why Drop REST?
If you are still hesitating on whether or not GraphQL is suited for your needs, a quite extensive and objective overview of “REST vs. GraphQL” is given here. However, for my top three reasons to use GraphQL, read on.
Reason 1: Network Performance
Say you have a user resource on the back-end with first name, last name, email, and 10 other fields. On the client, you generally only need a couple of those.
Making a REST call on the /users endpoint gives you back all the fields of the user, and the client only uses the ones it needs. There is clearly some data transfer waste, which might be a consideration on mobile clients.
GraphQL by default fetches the smallest data possible. If you only need first and last names of your users, you specify that in your query.
The interface below is called GraphiQL, which is like an API explorer for GraphQL. I created a small project for the purpose of this article. The code is hosted on GitHub, and we’ll dive into it in the second part.
On the left pane of the interface is the query. Here, we are fetching all the users—we would do GET /users with REST—and only getting their first and last names.
Query
Result
If we wanted to get the emails as well, adding an “email” line below “lastname” would do the trick.
Some REST back-ends do offer options like /users?fields=firstname,lastname to return partial resources. For what it’s worth, Google recommends it. However, it is not implemented by default, and it makes the request barely readable, especially when you toss in other query parameters:
&status=activeto filter active users&sort=createdAatto sort the users by their creation date&sortDirection=descbecause you obviously need it&include=projectsto include the users’ projects
These query parameters are patches added to the REST API to imitate a query language. GraphQL is above all a query language, which makes requests concise and precise from the beginning.
Reason 2: The “Include vs. Endpoint” Design Choice
Let’s imagine we want to build a simple project management tool. We have three resources: users, projects, and tasks. We also define the following relationships between the resources:

Here are some of the endpoints we expose to the world:
GET /users
List all users
GET /users/:id
Get the single user with id :id
GET /users/:id/projects
Get all projects of one user
The endpoints are simple, easily readable, and well-organized.
Things get trickier when our requests get more complex. Let’s take the GET /users/:id/projects endpoint: Say I want to show only the projects’ titles on the home page, but projects+tasks on the dashboard, without making multiple REST calls. I would call:
GET /users/:id/projectsfor the home page.GET /users/:id/projects?include=tasks(for example) on the dashboard page so that the back-end appends all related tasks.
It’s common practice to add query parameters ?include=... to make this work, and is even recommended by the JSON API specification. Query parameters like ?include=tasks are still readable, but before long, we will end up with ?include=tasks,tasks.owner,tasks.comments,tasks.comments.author.
In this case, would be it wiser to create a /projects endpoint to do this? Something like /projects?userId=:id&include=tasks, as we would have one level of relationship less to include? Or, actually, a /tasks?userId=:id endpoint might work too. This can be a difficult design choice, even more complicated if we have a many-to-many relationship.
GraphQL uses the include approach everywhere. This makes the syntax to fetch relationships powerful and consistent.
Here’s an example of fetching all projects and tasks from the user with id 1.
Query
Result
As you can see, the query syntax is easily readable. If we wanted to go deeper and include tasks, comments, pictures, and authors, we wouldn’t think twice about how to organize our API. GraphQL makes it easy to fetch complex objects.
Reason 3: Managing Different Types of Clients
When building a back-end, we always start by trying to make the API as widely usable by all clients as possible. Yet clients always want to call less and fetch more. With deep includes, partial resources, and filtering, requests made by web and mobile clients may differ a lot one from another.
With REST, there are a couple of solutions. We can create a custom endpoint (i.e., an alias endpoint, e.g., /mobile_user), a custom representation (Content-Type: application/vnd.rest-app-example.com+v1+mobile+json), or even a client-specific API (like Netflix once did). All three of them require extra effort from the back-end development team.
GraphQL gives more power to the client. If the client needs complex requests, it will build the corresponding queries itself. Each client can consume the same API differently.
How to Start with GraphQL
In most debates about “GraphQL vs. REST” today, people think that they must choose either one of the two. This is simply not true.
Modern applications generally use several different services, which expose several APIs. We could actually think of GraphQL as a gateway or a wrapper to all these services. All clients would hit the GraphQL endpoint, and this endpoint would hit the database layer, an external service like ElasticSearch or Sendgrid, or other REST endpoints.

A second way of using both is to have a separate /graphql endpoint on your REST API. This is especially useful if you already have numerous clients hitting your REST API, but you want to try GraphQL without compromising the existing infrastructure. And this is the solution we are exploring today.
As said earlier, I will illustrate this tutorial with a small example project, available on GitHub. It is a simplified project management tool, with users, projects, and tasks.
The technologies used for this project are Node.js and Express for the web server, SQLite as the relational database, and Sequelize as an ORM. The three models—user, project, and task—are defined in the models folder. The REST endpoints /api/users*, /api/projects* and /api/tasks* are exposed to the world, and are defined in the rest folder.
* Note: After publication, Heroku stopped offering free hosting, and the demos are no longer available.
Do note that GraphQL can be installed on any type of back-end and database, using any programming language. The technologies used here are chosen for the sake of simplicity and readability.
Our goal is to create a /graphql endpoint without removing the REST endpoints. The GraphQL endpoint will hit the database ORM directly to fetch data, so that it is totally independant from the REST logic.
Types
The data model is represented in GraphQL by types, which are strongly typed. There should be a 1-to-1 mapping between your models and GraphQL types. Our User type would be:
Queries
Queries define what queries you can run on your GraphQL API. By convention, there should be a RootQuery, which contains all the existing queries. I also pointed out the REST equivalent of each query:
Mutations
If queries are GET requests, mutations can be seen as POST/PATCH/PUT/DELETE requests (although really they are synchronized versions of queries).
By convention, we put all our mutations in a RootMutation:
Note that we introduced new types here, called UserInput, ProjectInput, and TaskInput. This is a common practice with REST too, to create an input data model for creating and updating resources. Here, our UserInput type is our User type without the id and projects fields, and notice the keyword input instead of type:
Schema
With types, queries and mutations, we define the GraphQL schema, which is what the GraphQL endpoint exposes to the world:
This schema is strongly typed and is what allowed us to have those handy autocompletes in GraphiQL*.
* Note: After publication, Heroku stopped offering free hosting, and the demos for this article are no longer available.
Resolvers
Now that we have the public schema, it is time to tell GraphQL what to do when each of these queries/mutations is requested. Resolvers do the hard work; they can, for example:
Hit an internal REST endpoint
Call a microservice
Hit the database layer to do CRUD operations
We are choosing the third option in our example app. Let’s have a look at our resolvers file:
This means, if the user(id: ID!) query is requested on GraphQL, then we return User.findById(), which is a Sequelize ORM function, from the database.
What about joining other models in the request? Well, we need to define more resolvers:
So when we request the projects field in a User type in GraphQL, this join will be appended to the database query.
And finally, resolvers for mutations:
You can play around with this here. For the sake of keeping the data on the server clean, I disabled the resolvers for mutations, which means that the mutations will not do any create, update or delete operations in the database (and thus return null on the interface).
Query
Result
It may take some time to rewrite all types, queries, and resolvers for your existing app. However, a lot of tools exist to help you. For instance, there are tools that translate a SQL schema to a GraphQL schema, including resolvers!
Putting Everything Together
With a well-defined schema and resolvers on what to do on each query of the schema, we can mount a /graphql endpoint on our back-end:
And we can have a nice-looking GraphiQL interface* on our back-end. To make a request without GraphiQL, simply copy the URL of the request (i.e., https://host/graphql?query=query%20%7B%0A%20%20user(id%3A%202)%20%7B%0A%20%20%20%20firstname%0A%20%20%20%20lastname%0A%20%20%20%20projects%20%7B%0A%20%20%20%20%20%20name%0A%20%20%20%20%20%20tasks%20%7B%0A%20%20%20%20%20%20%20%20description%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D*), and run it with cURL, AJAX, or directly in the browser. Of course, there are some GraphQL clients to help you build these queries. See below for some examples.
* Note: After publication, Heroku stopped offering free hosting, and the demos are no longer available.
What’s Next?
This article’s aim is to give you a taste of what GraphQL looks like and show you that it’s definitely possible to try GraphQL without throwing away your REST infrastructure. The best way to know if GraphQL suits your needs is to try it yourself. I hope that this article will make you take the dive.
There are a lot of features we haven’t discussed about in this article, such as real-time updates, server-side batching, authentication, authorization, client-side caching, file uploading, etc. An excellent resource to learn about these features is How to GraphQL.
Below are some other useful resources:
The reference implementation of GraphQL. You can use it with express-graphql to create a server.
An all-in-one GraphQL server created by the Apollo team.
Ruby, PHP, etc.
A framework for connecting React with GraphQL.
A GraphQL client with bindings for React, Angular 2, and other front-end frameworks.
In conclusion, I believe that GraphQL is more than hype. It won’t replace REST tomorrow just yet, but it does offer a performant solution to a genuine problem. It is relatively new, and best practices are still developing, but it is definitely a technology that we will hear about in the next couple of years.
Last updated