An API that provides game data as a GraphQL API.
-
Start the API using Docker:
docker run -d -p "4000:4000" micheljung/d2r-api
-
Access, or post your queries to, http://localhost:4000/graphql
Query:
{
uniqueitems {
index
itemName
}
}
Result:
{
"data": {
"uniqueitems": [
{
"index": "The Gnasher",
"itemName": "Hand Axe"
},
...
{
"index": "Hellfire Torch",
"itemName": "charm"
}
]
}
}
Query:
{
runes(query: [{field:"complete", query: 1}]) {
runeName
runesUsed
}
}
Result:
{
"data": {
"runes": [
{
"runeName": "Ancients' Pledge",
"runesUsed": "RalOrtTal"
},
...
{
"runeName": "Zephyr",
"runesUsed": "OrtEth"
}
]
}
}
Currently, all queried fields are OR
. AND
will be supported soon. Combinations of the two likely won't be supported.
Using the data-extractor, a developer can extract the game's "excel" data directly from a game installation into the folder d2r. This could be improved by reading the data directly from Blizzard's CDN at build time, so no game installation is needed.
All data is extracted except sounds.txt
which is considered big and useless. Other useless data might be removed in
future, too.
Any empty or "category" lines (like "Expansion", "Armors") are removed based on heuristic. Otherwise, the data contains everything that's present in the game files, including unused items. It's up to the caller to detect and remove such unwanted entries.
To update the extracted data, execute:
.\gradlew extract
or if your installation is at a non-default location:
.\gradlew -PdataPath="G:/Diablo II Resurrected/Data" extract
Instead of creating a static GraphQL schema for each entity by hand, it's auto-generated by the following rules:
- If a field contains any empty value, it's considered nullable
- If a field contains only numbers, it's considered an
Int
- If a field contains only numbers and one of them is a float, it's considered an
Float
- If a field contains any non-number content, it's considered a
String
- If a field contains no values at all, it's considered
String
and a warning is logged
This leads to a non-perfect schema since e.g. Boolean
can't be detected reliably (and thus is never used), and the
type of empty columns is potentially likely incorrect. However, it also removes any manual work, human errors and
never needs to be updated.
If this decision turns out to be problematic, let me know so that a static schema can be added in the future.