How to use GraphQL API in GraphQL backend server?

Users GraphQL
1

Currently dgraph has been advertised as a native GraphQL database.

Judging from the current information, the GraphQL API seems to be for the client rather than the server.

I did not find a use case for using GraphQL API on the server side.

Ignore the backend and let the client directly operate the dgraph database. I don’t know the good reason for this. I have a few questions about this.

1, A mature application cannot do without a server. In addition to processing client requests and database reads and writes, the server also undertakes a lot of other tasks, such as message queues, redis caching, log processing, and other platforms (such as big data, etc.) Interaction and so on.

All in all, you cannot use dgraph to completely replace the server. This is unrealistic. This approach is only suitable for limited small applications.

2, Fully expose the dgraph database to the client, even if it has a verification program, I think this is insecure.

3, As a database, dgraph should serve the server, not the client.

I hope team can provide some use cases for applying GraphQL API on the server side, instead of promoting how to use GraphQL API on the client side.

I have difficulty using GraphQL API on the server side.

My server is a GraphQL server built on rust. I don’t know how to use dgraph’s GraphQL API in my GraphQL server. There are several difficulties in this.

Compared with restful, calling the API of another graphql server in one graphql server seems to be a complicated matter. How to deal with it?

1，I need to convert the graphql request from the client into a dgraph graphql request. I don’t know how to achieve this conversion. This involves complex work such as parsing resolveInfo.

There are some other issues that I haven’t sorted out yet. Hope team can provide some practical use cases.

1 Like
2

Hi @pandaslive I think there is a bit of miscommunication about Dgraph and GraphQL here. I shall attempt to clarify. Apologies in advanced if I may sound patronizing. It’s often better to be simple and clear rather than complicated and obscure.

  1. API - an API is a way to talk to a program. If you use the functions, data structures and macros defined by a library, you are using the library’s API. Sometimes your program is on another machine over the internet. To communicate with that program you need a remote API. One such example of a program is your database. Other programs might be a webserver, and you communicate with it via a Web API.
  2. Web API - a API to a program that is accessible over the web, usually by means of HTTP. A common way to talk to a program is via REST APIs. With REST, you specify the resources that you want from the server using a URI, and the server responds accordingly.
  3. GraphQL API - another way to talk to a program on a server somewhere. This time, you specify what you want in GraphQL over HTTP, instead of using a URI. Usual GraphQL APIs are all about getting specific resources from a program somewhere on the internet.
  4. Database - a database is where you store your data. You can put your data in the database or get data out from a database by using a query language. Common examples include SQL, GraphQL and DQL (formerly called GraphQL±). The main uses in databases are to perform CRUD (Create, Read, Update, Delete) operations.
  5. Backend, Frontend - these are all relative terms. Given a simplified architecture as such: image
    It really depends on how you are viewing things. From one point of view, the program is the frontend for the database.
    image …
    From another point of view, the program is the backend for the program running in the web browser:
    image.
    As such, I would prefer not to use these terms as they are highly confusing.

Now, having defined all the terms, let’s examine the confusion that I suspect exists:

  1. Dgraph provides something called a “GraphQL API”. What this means is you can query data and put data into the database using GraphQL instead of DQL, which is the usual way.
    By analogy, let’s look at Postgresql for comparison:
    • the usual way to communicate with Postgresql is using SQL over the Postgresql protocol. You send Postgresql your query (in SQL) via its protocol, and Postgres returns results in its format via the same protocol. We may call that a “SQL API”.
    • Dgraph allows you to communicate with it via HTTP. You send Dgraph your query (in either GraphQL via HTTP or DQL over gRPC), and Dgraph will return the results in JSON format via HTTP/gRPC. Given the similarity to how most GraphQL APIs are implemented, I think we are justified in calling it “native GraphQL database”.
  2. Dgraph also provides a hosted GraphQL API service called Slash Graphql.

These two facts tend to make things rather confused.

Now, recall that the main uses of databases are to perform CRUD operations. You want to store data, update data, or delete data from databases.

Consider an application such as a blog. We can once again come back to the simplified architecure. Assume that the DB is Postgresql:

image

Now let’s focus on the yellow box and see what it’s doing. It’s acting as a frontend for the DB. What it does is to take a query from the web browser (may be in URI, may be in GraphQL), and translates it into SQL, then uses the Postgresql protocol to communicate with the DB.

Of course you can use Dgraph in such a manner as well! You take the request from the web browser, translate it into GraphQL or DQL, then communicate with Dgraph via HTTP.

But if all you are going to do is CRUD operations, with no additional processing, why require the middleman?

Get rid of it! YAGNI!

And now, we can answer some of your questions:

A mature application cannot do without a server. In addition to processing client requests and database reads and writes, the server also undertakes a lot of other tasks, such as message queues, redis caching, log processing, and other platforms (such as big data, etc.) Interaction and so on.

Not true. The rise of “serverless” applications (AWS lambda, etc) shows that you don’t need a always-on server.

As for other tasks, that requires an inversion of thinking. Instead of a “backend” to push a datum to a message queue or cache, perhaps the queue or cache should have a subscription to the database, such that when a change happens in the database, the queue or cache will be updated as well. Here are the subscription documentation. It requires you to turn your understanding of how things flow upside down, and it’s definitely mind expanding.

Fully expose the dgraph database to the client, even if it has a verification program, I think this is insecure.

I understand the apprehension. Like I said, you don’t have to - you can put a program in between as a gatekeeper if you wish.

As a database, dgraph should serve the server, not the client.

Who is the server and who is the client is like I mentioned, dependent upon your point of view. Your intermediary program is a frontend/client to the database. It is the backend to the web requests that come through the web browser. You will find this notion in all databases - for example, Postgresql refers to the program as a “client”.

I need to convert the graphql request from the client into a dgraph graphql request. I don’t know how to achieve this conversion. This involves complex work such as parsing resolveInfo.

Well, that’s par for the course if you want to have something as the middleman. If you could share some specifics, I could definitely help you out.

3 Likes
3

@chewxy

The backend server is not just a simple CRUD, it is more like a CPU, as a processing center to coordinate various services, CRUD is just its tool.

Perhaps it is unnecessary for small applications and can be implemented using serverless, but it is essential for large applications. At least I haven’t heard of any large applications without back-end servers.

I understand what you said, this may represent a certain trend in the future. But it is still out of reach for me. It cannot replace all scenarios, especially large applications. I still need the back-end server as the processing center for coordinating various services.

I’m building a complex e-commerce application. I don’t have the infrastructure like serverless, and serverless can’t solve the problems we want to deal with either. I still need backend server. And for us, completely exposing the database and back-end logic to the insecure web or app is unacceptable.

Yeah. I am using juniper to build a graphql backend server.
But I encountered some difficulties. I don’t know how to convert graphql request from client to dgraph graphql request.

If it is neo4j, it provides a client library to deal with this problem, but dgraph does not have such a tool.

Below is an example of neo4j:

import { neo4jgraphql } from 'neo4j-graphql-js';

const resolvers = {
  Query: {
    Movie(object, params, ctx, resolveInfo) {
      // Convert the graphql request from the client to the graphql request of neo4j.
      return neo4jgraphql(object, params, ctx, resolveInfo);
    }
  }
};

If dgraph can also provide such a tool, then the problem becomes very simple, so that it will be easy to use dgraph’s graphql API on the graphql server.

4

What are you receiving from your frontend? GraphQL?

Additionally, what are the objects you have defined in juniper, and how are they defined in Dgraph?

If they are adequately specified, you could just pass the client GraphQL directly to Dgraph

1 Like
5

If you are familiar with graphql, you should know that a graphql request contains three parameters: query, operation_name and variables. The graphql backend will automatically process these three parameters and pass them to the corresponding graphql interface (just like the Movie above). It will be transformed into the above four parameters: object, params, ctx, resolveInfo. I need to parse out the parameters that meet the dgraph graphql api request from these parameters, and then initiate a CRUD request to the dgraph graphql server.

6

That’s false. That’s only true if you are requesting GraphQL via JSON.

You can just extract the "query" field of the JSON and send that to Dgraph.

1 Like
7

This is a general situation, but what if I need to change the query and variables? Some parameters cannot be passed on the client side. They need to be calculated on the backend and then passed to the request.

8

I’m trying to understand the flows involved here - it’s either:

  1. Client (Webbrowser) sends GraphQL to Juniper backend. Juniper backend does preprocessing of query, then sends query to Dgraph.
  2. Dgraph sends data to Juniper backend (in JSON format). Juniper does preprocessing of response and sends to Client (web browser)

If it’s 2:
I fail to see how “some parameters cannot be passed on to the client side” - the response from Dgraph is a JSON, and it should be fairly easy in Rust to inspect a JSON.

If it’s 1:
Well you need some library in rust that deals with GraphQL as an object itself - not sure if there is one

9

7 posts were split to a new topic: Library for Parsing GraphQL

14

In addition, I would like to know whether the graphql api of dgraph reads and writes to the disk directly or through the DQL server?

It is:

client --> backend server  --> GraphQL API server  -->  disk

or ?:

client -->  backend server  --> GraphQL  API server-->  DQL server --> disk
15

it’s a database, where the way you talk to it is via HTTP and GraphQL, so it’s:

client --> backend server  --> dgraph  -->  disk

This feature is built into dgraph the database itself. So unlike Postgres where you might require something like Postgraphile as a service in front of the database, it just is built in.

The GraphQL API server is a hosted service called slash graphql, which is a combination of dgraph (the database), and a bunch of operational stuff like load balancers which form the “server”.

16

Thanks, i see