GraphQL Support

[LarsKoelpin]

Hey,
As we have discussed a lot in the past weeks I'd like to know what the strategic goal of this library would look like?

It's kinda one of

1. Be complete
   or
2. Be efficient, minimalistic, conservative in adding new features/attributes...

I know this project is called "cs-demo-minifier" and therefore implies some kind of minifications.
But I often feel like there is a lot of data missing.

Personally I'm using it more for the transformation abilities (Actally I'd just want to have a "full" demo in JSON Format not caring about size and performance).
So, I'm asking myself, if this library is even the right tool for me.

As our discussion have shown, we may have different views on the value, the library should provide.

These are my interpretations:
Your View: be as efficient as possible. add new "attributes" with caution. Do not duplicate Attributes.
My View: Be as complete as possible. Add new "attributes" for completeness. I'm more about: I need all Data from the .dem File as JSON in a practical way. If e.g. events and snapshots contain the same data (e.g. as TeamEvent and Team proprty in snapshots) does not matter, as the user may needs one of these data-views. We keep both.

So how about that solution: Let the user decide. We add attributes (not like crazy, but maybe all possible attributes from golangparser + some convinience attributes)
We specify a complete JSON structure containing all data existing (add every attribute from demoinfo-csgo)

{
  snapshots: [
  {
   {
     id: number,
     name: string
     team: number
     isDefusing: boolean
     isPlanting: boolen
     isReloading: boolean
     // .... all possibile Attributes comming from common.player
   }
  }]
  events: [
    {
      name: string
      // NOTICE: SWAP_TEAM events can get serialized, althugh a team attribute exists in the snapshots
      // ...
      }
  ]
}

We then change the CLI API to accept an graphql query. This query accepts all attributes the user wants to "see"

query(freq = 0.5) {
  snapshots: {
    id
    name
    position {
      x
    }
  }
}

e.g. the user would see all snapshots only containing id, name and the x-Coordinate of the player.

But he could also query

query(freq = 0.5) {
  snapshots: {
    id
    name
    position {
      x
    }
  }
  events(type = ["SWAP_TEAM", "FIRE"]) {
    name
    attrs {
      numVal
    }
  }
}

to get also all events of type SWAP_TEAM and FIRE.
I guess this would include some structural changes in the data model.

The API of the CLI would then change to the following:

csgominify --query my-data.graphql --demo mydem.dem --out hello.json

So here is my question:
Should this be a separate project, or would this align with your strategic goal of this library? **

I know there is also protobuf support which would likely not benefit from such API (or could it?), I don't know, as I'm not that of a protobuf user.

I'm working on a Proof on concept here: https://github.com/LarsKoelpin/csgo-demo-graphql

Greetings

[markus-wa]

I really like this idea tbh, great thoughts!

I actually ran some numbers with the data we expose in demoinfocs-golang and it seems like it wouldn't even be the worst thing to serialise all of it (though I certainly wouldn't want that as the default!).

side note: Only when we'd try to serialise all data from the DataTables we should have an issue. then we'd be looking at a 50 Gigabyte JSON or so if everything was enabled with a 0.5 frequency (that number is based on a real calculation, not out of thin air). But nobody is interested in most of what's in there I guess. (even if it doesn't make sense to enable all of it, someone would do it someday and would break their machine with it 😄)

so I think we should be fine.

I know there is also protobuf support which would likely not benefit from such API (or could it?), I don't know, as I'm not that of a protobuf user.

should be alright, we should implement this in the data-collection rather than in the encoding so it will work there as well.

so let's do it 😄

[markus-wa]

and by let's do it I mean I probably won't find time for doing much for a while but I'm always here to support 😅