Whats the role of a backend service when using dgraph

Users Dgraph
1

Hi, I am wondering what the purpose is of having a backend service between dgraph and lets say the browser.
Isn’t the GraphQL API designed such that the user from their browser could authenticate and query / mutate data?
Would a backend typically accept GraphQL queries and simply proxy the requests?

3 Likes
2

Hi @Nico_Braun
Interesting question.
I had this question too and we are migrating from Java/MySQL to Dgraph and we taught that we need a Backend to handle all business logic in some complex cases(other than CRUD) but when I made my hands dirty I realized that there are some set of tools to help me implement all my business logic. One of them is Custom DQL and the other one is Lambda Resolvers.

At this point we do not need a Backend. Maybe we use a simple wrapper to change some queries before execution but not a backend.

Good luck :slight_smile:

4 Likes
3

I had the same question.

The problem is: anti ddos, security vulnerabilities in your DB, slow/expensive lamba functions, expensive bandwidth.

I solve that with Cloudflare Workers: https://workers.cloudflare.com/ (it"s an awesome competitor to google cloud functions and AWS lambda (edge))
Only my Workers can access the DB. nobody else
They are basically my proxy. Why? here we go:

  • anti ddos and so on is handled by cloudflare
  • you can integrate more easily other SaaS like Firebase Authentification and Twilio
  • bandwidth is FREE!!!
  • lambda functions run on a single server, e.g in US East Ohio. Cloudflare Workers run on cloudflares Edge, their big CDN network. If you make a http call from tokyo, you call amazingly fast with no cold starts, a cloud function (called worker) in tokyo. not in the US. this increases amazingly latency.
  • out of the box FREE caching with the cache API. so if users make frequently the same calls to your dgraph db like “show me the top10 videos of today” or “weather today in tokyo” you don’t have to basically ddos your dgraph DB with one and the same request. instead it is served FOR FREE from cloudflares cache.
  • Cloudflare Workers are CHEAPER than lambda edge, they are FASTER, NO cold starts, and more customizable (you can keep functions with the unbound pricing for hours alive through WebSockets, e.g if you build an online game (clash of clans is online so that you cant hack 999 diamonds), or a real time chat app, real time collaboration app like figma)
  • you cant keep lambda functions alive, they are designed to be only for some seconds active, else they bill you big money
  • bandwidth is FREE, client → near cloudflare worker in his region → AWS/GCP. you pay for that $0 in bandwidth. if you use lamba instead of cf workers (client → dgraph with lambda handler) you pay $$$ for bandwidth
  • AMAZING features like the key value storage (yep, it’s an out of the box world wide sharded redis solution)
  • Cloudflare Durable Objects are a killer. you can coordinate with that an online gaming multiplayer server, or live cloud coding collaboration with a friend
  • it can intercept calls to CDN resources and do auth
  • many more awesome features
    off topic but still important ( * cloudflare just announced its product ‘R2 storage’, to kill google storage and AWS S3. then you don’t need signed URLs anymore, which expires after time. you just intercept requests to a picture, and do authentication. )

i dont work at cloudflare but i am a big fanboy (i even bought one cloudflare stonk some weeks ago) because they offer for us noob solo beginner developers SO MUCH support, extremely free and cheap pricing, nicu support, and much more

you just need to use lambda functions as a dgraph interceptor if you dont want to manage that with workers. e.g someone creates a document. then a lambda function gets invoked and does some work like cleaning old copies or stuff like that idk whatever you need

for me Cloudflare CDN + CF Workers + CF DOs + CF KV + dgraph as the main DB + CF R2 is a game-changing killer that enables kid developers like me to build massive applications without having to think much about the backend, spending more time working on the front end for better UX

1 Like
4

This is cool - it would be a good to see a talk on this. :slight_smile: