Gadsme (literally Ads in Game) was founded in 2019 to provide an advertising platform designed for the gaming and e-sports industries. We are engaged in the serving of non-intrusive advertising embedded within scenes of video games.
Gadsme work with major video game studios and serve millions of ads every day. We keep innovating to bring new brand experiences to this area.
How Gadsme started using Cube
The Gadsme team first heard of Cube in 2019 after reading a post on Hacker News. At the time, we were focusing more on developing our cross-platform advertising SDK. When it came to building our analytics solution, Cube was the perfect tool to ease iterations around how data insights can be exposed efficiently to our clients. Now, all our dashboards (e.g., for ad requests, impression, fill rate, eCPM, etc.) and reporting API use Cube under the hood.
As an AdTech company, Gadsme collects millions of events every day. All those events are stored in BigQuery. With Cube and its built-in pre-aggregations feature, we were able to expose meaningful data with speed and maintain complete control of analytics costs.
How Cube was implemented at Gadsme and our contributions to the Cube community
Our team used pre-aggregations since day one. We were first using Postgres as an external pre-aggregations database and now we have been using Cube Store in production since July 2021. This last move to Cube Store brought a noticeable speed-up in the loading times of data and graphs for our client dashboards.
We run Cube on Kubernetes, and we spent some time improving the deployment automation of Cube using Helm Charts. As other members of the community were asking for it, we decided to make a contribution, and our Helm Charts are available for everyone in the example folder of Cube. This was the first major contribution from Gadsme to the Cube project, and contributing back if possible to open source community is a key part of our values.
We also use GraphQL to build all our APIs. We decided not to expose Cube directly and preferred building a GraphQL proxy on top of Cube's REST API (see our architecture diagram below).
- API autogeneration based on Cube definitions
- Directives support
- Compatibility with the authorization layer (e.g., JSON Web Tokens, queryRewrite, multitenancy, etc.)
We also had the opportunity to discuss our GraphQL contribution during the November community call, and we’d welcome your feedback on our contributions not only for GraphQL, but also for Helm Charts.