😍A GraphQL Sqlite, sequelize Full (ok)

https://sequelize.org/docs/v7/category/querying/

62KB
Open
64KB
Open

— Step 1 getUsers

package.json

.env

2KB
Open

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

20KB
Open

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 models folder contains the three models: User, Project and Task. They are created using the sequelize ORM.

  • The rest folder contains the logic to create the associated /api/users, /api/projects and /api/tasks endpoints.

  • The graphql folder contains the schema and resolvers for GraphQL.

  • db.sqlite contains the database.

  • index.js starts the Express server.

Demo

This example project is hosted on Heroku.

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.

GraphQL vs. REST - A GraphQL Tutorial

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=active to filter active users

  • &sort=createdAat to sort the users by their creation date

  • &sortDirection=desc because you obviously need it

  • &include=projects to 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:

Relationships between resources

Here are some of the endpoints we expose to the world:

Endpoint
Description

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/projects for 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.

Comparisons of GraphQL vs. 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:

Server-side Tool
Description

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.

Client-side Tool
Description

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