@MichelDiz 
I donât think this design will bring much benefit, on the contrary it is very bad, it violates the usual database design principles.
Compared with its saved performance, it brings more confusion and insecurity to users.
In actual development, there are usually many queries that depend on id. When id does not exist, it means that the data does not exist. But dgraph has violated this principle and will cause many problems.
1, For applications with type checking, it will crash directly. Because it only returned the id that shouldnât exist, and lost other required fields.
2, I cannot check whether the data exists based on the id, and if I do so, I will get an incorrect result.
If the node does not have other unique fields, I will not be able to check whether the data exists.
3ïŒIn actual business, queries based on id are common, such as /post/{id}, /user/{id}, /user/{id}/{status_id}, etc. Once the correct data cannot be queried based on id, it will result in 404 or other serious errors.
This will cause the application to crash, bring a very bad experience to the user, and even create messy and wrong data.
The above are some of the problems I encountered.
I know @cascade and expand, but these characteristic are not designed to solve this problem.
I am very confused about this solution, but I still try to use it, and the bad thing is that it does not work.
Suppose I have the user data as follows:
{
"uid": "0x4",
"name": "jack",
"age": 22,
"description": null,
"birthday": null
}
1, When I execute the following query, it works normally:
{
data(func: uid(0x4)) @cascade {
uid
name
}
}
Get the result:
"data": [
{
"uid": "0x4",
"name": "jack"
}
]
2, If a field with a value of null is queried, it will return empty:
{
data(func: uid(0x4))@cascade {
uid
name
description
}
}
Get the result:
"data": []
This is not the wrong result I want.
3, When I combine it with expand, it also got the wrong result:
{
data(func: uid(0x4))@cascade {
uid
expand(User)
}
}
Get the result:
"data": []
4, When I specify other fields, it will throw an exception:
{
data(func: uid(0x4))@cascade {
uid
name
expand(User)
}
}
"errors": [
{
"message": ": Repeated subgraph: [name] while using expand()",
"extensions": {
"code": "ErrorInvalidRequest"
}
}
]
The above is the result of my test in ratel.
Obviously @cascade and expand cannot solve this problem. Even if they can, this is still a very bad solution.
In short, I think it is necessary to check whether the id actually exists. Almost all databases are designed this way, but dgraph is an exception, which is very bad.
Performance is important, but practicality and safety are even more important.
I hope team can solve this problem as soon as possible, otherwise my project will not be able to go online, or give up dgraph and use other databases. 
