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.
- 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.
- 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.
- 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.
- 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.
- Backend, Frontend - these are all relative terms. Given a simplified architecture as such:
It really depends on how you are viewing things. From one point of view, the program is the frontend for the database.
From another point of view, the program is the backend for the program running in the web browser:
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:
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”.
- 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:
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.