I’ve been developing for over a decade. I’ve architected quite a few RDBS and last year started diving heavily into Hasura. I have a new client project and I feel like dgraph would be an excellent fit for what is looking to be a highly relational model. I feel pretty comfortable with graphql, and the concept of graph databases and see their value. Where I’m struggling is getting clear answers on the the why behind certain modeling approaches. I’d love some help getting answers to a few high level questions:
DGraph/Graphql specific questions:
- When using the graphql schema option, does dgraph automatically index for aggregates?
- Does dgraph create index automatically for anything besides predicates tagged with @search?
- Impact of mutations on queries. In an RDBS, too many mutations against a large table can drastically impact query time. Is this a concern in dgraph?
- Performance impacts of deeply nested where clauses?
- Say I have a User type that has private fields, and a UserProfile that has publicly queryable fields. There are multiple types of Users with some overlap and slight differences. How would you model this when thinking about adding @auth to ensure only the UserProfile information is exposed?
General Graph database questions:
- What are the benefits of using Unions?
- When to denormalize? IE - Likes on a youtube video.
2b) Denormalizing photos. Assuming a very high traffic site would there be a benefit to denormalizing the image names into an array onto their associated item? Or is that overkill and just leave the photos separate and link them?
- How find grained to break your schema down? Do you benefit more from a lot of smaller nodes composed into a larger one? Or less by having more relationships you have to traverse?
IE - Let’s say I’m building a real-estate app and I want users to be able to search by number of bathrooms. What would be the pros and cons of making a BathroomCount type that is referenced by homes vs just having an Integer on the Home type itself?
IE2 - The real estate app would search heavily by address, and parts of addresses. Do you break down each address part into its own pieces?
- Pros and cons of more predicates vs more relationships. IE -
User has Messages.
Messages can be read.
You could model this as Message has isRead.
or by changing User to be
User has unread: [Messages]
User has read: [Messages]
Comparisons to traditional RDBS options appreciated, but not necessary.
Thanks in advance to anyone that weighs in.