PS. This is too much offtopic talking. You can skip. Dgraph still doesn’t address what was questioned. But it will in the near future.
When I said “client” I was referring to the end customer. No application will have a customer consuming that much data per second directly from a DB. But that level of data can be surpassed if your user base is massive. But that’s another context, not data dumping.
Database => BS-Logic/middleware/client => API => Application => customer
Understand. Exists:
Backend
0 - Level of database. He takes care of the storage-level writing and his job is to make sure the data is safe. Nothing more than this. Anything else that comes in the package is profit, gladly welcome.
1 - Business Logic(your product should rely on this, not in your DB - IMHO). This is the client(py, js, go, rust) level. The thick part of the job has to be done here. Not in the DB.
1.1 - Some mining data(big data activities). Python mining and others goes here. This can serve at frontend optionally or just dump mined data to use in PowerBI and other types of plotting data to present in research or marketing maybe. Such activities it is impossible for a DB to specialize.
Frontend
2 - State
3 - application logic. (Some synonyms used: “Client, customer, end consumer” - The frontend is reflection of your business logic)
You won’t be doing any mining or heavy activity on frontend. Just minor validations and state managing. Much of the work has to be on the backend because that’s where you know there are more resources. You’re not going to ask a $100 smartphone to do data analysis. Neither your DB and risk it going OOM. You have to balance the Job. Be in control of your ship, captain!
I really don’t understand what you mean.
I really don’t think DBs should be Low-Code/No-Code platforms. But you can build such a platform on top of that. Not fundamentally part of a DB’s core.
It’s not because they’ve added something to a DB that you should really rely your whole bussines on it. Too much abstraction, too much outsourcing can be something very serious in your final product. As I said before, you create too much dependency in a single thing. A man of strategy doesn’t think that way. Think about time. Time is alll you have in life. You will save a lot of time even with a DB doing everything for you. But at what price? in terms of time wasted in case something happens.
I’m all in if you wanna give your soul to Dgraph’s product. I will love having you around forever. ![:stuck_out_tongue: :stuck_out_tongue:](http://discuss.dgraph.io/images/emoji/twitter/stuck_out_tongue.png?v=12)
Really, maybe we have a really passionate community indeed.
This is something that the CTO has also already agreed to in conversations. Let’s consolidate this idea.
I do not agree. We have GraphQL because the community has been relentlessly asking for it. It wasn’t to solve anything. It was just to have a different language supported in my opinion. Read the GraphQL related issues. I participated in it myself. Today I see that I was partly wrong with what I wanted. At the time I was just a user studying GraphQL and excited about it. I wanted everyone supporting GraphQL. Fool. GraphQL is awesome, but it’s not for everyone.
What engineers have done with GraphQL in Dgraph is really impressive. But nothing can be set on stone. Everything is changeable in life. Every river changes its course over the years. And something that is inflexible begins to show signs of fatigue. Almost screaming for middleware.
Question. What algorithms you can do with GraphQL? if it is not running with your own custom resolver?
Yes. Let’s be an Eagle, not a Duck.
Just to remind, I’m not against GraphQL. I love that piece of technology. I just think it is not as flexible as we’d like it to be. DQL will grow a lot. You can bet.
Cheers!