Do I still need a backend server for a full stack application to be used with dgraph?

Users GraphQL
,
#1

If I wanted to use dgraph as a primary storage for data persistence, do I still need to create a backend server? Or my frontend (React for example) would just need to connect to the dgraph backend on the cloud? I was hoping to use dgraph with Nestjs

2 Likes
#2

You can do both. But right now I would recommend that you build your own backend.

3 Likes
#3

Oh okay, what’s the current pro of building my own for now out of curiosity?

Also, are there any docs out there on how to implement this with Nestjs/Node?

I’m coming from MongoDB and PostreSQL so my initial response is usually to find an ORM. Though, I’m guessing there isn’t any for dgraph at the moment?

1 Like
#4

You gonna learn a new nice thing. And learn a lot in the process. I’m not sure how things are in the cloud service. So I recommend to avoid it for now. Or at your own risk do it. Cuz it is a good service.

No and No. There are some repos out there with those frameworks. Also here in the discourse you gonna find several users who have done something with it.

From Dgraph, no. But there is a ORM from a user that I don’t record who. Not sure if are two or one ORM projects. But they exist.

2 Likes
#5

You just need to run a fetch within your nestjs endpoint. If you do like graphql, you could just fetch the graphql endpoint on the client. There are several ways to skin the cat.

J

1 Like
#6

I think the best way is use nextjs like cloud platform. write cloud functions for the business logic.
do not leave the business code at the database layer.

#7

i recommend cloudflare workers + dgraph

#8

Hey, guys just saw this thread several months later and I wanted to know if there were any changes with DGraph Cloud that would convince you that it is a viable solution to use with Next.JS as primary storage.
I got a cloud instance up and running, developed my schema to the way I need it, and have been doing graphql queries and mutations in the explorer successfully.
I’m starting to get a Next.js frontend designed and want to know if, at this point in time, DGraph Cloud is worth moving forward with.

Any info would be greatly appreciated. :pray:t5:

#9

Rest assured the Dgraph is back on the plaza. We have new investments and people being hired and new plans. I believe that without support you won’t be.

BTW, if your project is simple and focused on GraphQL. You are safe for many years to come. Just don’t add too much complexity.

KISS (Keep it Simple, Stupid) principle.

2 Likes
#10

Having a backend access Dgraph is the more secure way, as typically you don’t want to expose the database to the wilds of the public Internet. This way you can lock down Dgraph to only accept traffic from the client application.

If you want to plug Dgraph to the public Internet, at least take precautions to secure it, such as using ACL feature, and putting WAF and DDOS protection on the endpoint if it is used in a production setting.

1 Like
#11

Thanks, @MichelDiz that is reassuring. Honestly, our project, put simply, is a Search Bar that is querying Data from the DGraph backend. So far, the most complicated part is capturing the data about how our different nodes are interacting. I would love to learn more about what data we can collect there. Moving forward I will definitely keep KISS in mind :+1:t5: !!!

@joaquin I would like to know more about this. Are you saying we should have some middleware or client like Apollo to connect to DGraph? As opposed to just fetching the GraphQL endpoint directly?

If you want to plug Dgraph to the public Internet, at least take precautions to secure it, such as using ACL feature, and putting WAF and DDOS protection on the endpoint if it is used in a production setting.

Could you explain this a little more? I just want to understand clearly so that I can relay this to my team (which also has non-devs). I understand ACL helps control access to the database and is available in DGraph Cloud. Is this comparable to setting up your own client or middleware to control and authorize access to the database?

Thank you for your time. This is very helpful!

#12

You can expose the GraphQL endpoint if you have the GraphQL Auth enabled.

ACL with GraphQL won’t protect you, cuz you need to expose the graphQL endpoint anyway. You will need to do a reverse proxy passing the ACL token, so you won’t gain any protection anyway. The ACL is a protection at DQL level. You will need a common(shared, and limited) user to expose the GraphQL. If you wanna use ACL.

I’m NOT 100% sure, but I think we have some DDOS protection in our cloud infra. So, you are good if use the Cloud services. And you can add cloudflare too if you wish. Or something similar.

I see what you are saing, but that would be a new Apollo Server as middleware. Cuz you can use Apollo Client or whatever other GraphQL Client with Dgraph. You meant create a kind of proxying, right? You could do, maybe using Apollo Federation. But I’m not sure what Joaquin means with that. Maybe he was talking about the DQL layer. Feels like his recommendation is about self-running cluster. I mean, your infrastructure.

In general, when you are not going to use GraphQL in your project. We recommend isolating Dgraph completely and that you create your own API(that will perform DQL/RDF against Dgraph) to interact with your products. So Dgraph should never be exposed, only if you use ACL you can.

#13

There are known security flaws to bypass auth rules. Specifically when it comes down to creating/updating nodes. The @auth rules are missing vital aspects such as a rule that looks at the state after the update and not just before.

An example of this would be if you have Posts and Authors, and you create rules that you can only edit the post that you authored, and you can only publish (create) your own posts. This works well, until you realize you have no way to prevent someone from editing their own post and reassigning it to someone else (migrating control) and there is no way to stop that with an @auth rule.

This ^ would be my recommendation minus the “when you are not going to use GraphQL” part.

Either disable/block all mutations in the GraphQL API or allow for these problems like above. Maybe this use case is acceptable for your GraphQL project.

2 Likes
#14

Pretty much the major cloud providers like Azure, Google, and AWS offer some from of WAF or DDOS.

Amazon has ALB that offers such features, and there’s some integration with EKS:

For general purpose (any cloud), NGINX has App Protect solution, and they have an ingress solution for that for Kubernetes that can use the NGINX + AppProtect solution.

Obviously these solutions are not free for such features. CloudFlare also has solutions, where you can use it as a reverse-proxy front end to a service. You configure the DNS to point to CloudFlare, then configure CloudFlare to point to your endpoint (such as an ingress).

#15

@amaster507 thank you for your insight. I am starting to understand what you are saying a little more, but I am still unsure if I need to create my own API or if I am good to use the dgraph cloud solution. We are not collecting or sharing sensitive data but need it to be secure.

The idea was to have user data available for people to search, but only users who have created accounts can edit their data from the client side. I currently have an Apollo client hitting our dgraph endpoint ( using ENV vars). I was going to set up ApolloLink to send auth headers with the request and create some custom auth so that users who have logged in can edit only their data.

However, based on what you’re saying, If I want the backend to be secure, I should build out a custom API that hits the Dgraph endpoint, and then the frontend will request data from the API. With that method, the API that I build will have to handle authentication, data management, queries, etc. Am I getting that correct? Sorry if I am not connecting the dots. Just trying to get a better understanding of how to work with Dgraph effectively.