What does a "SDK" entail in this context?

[tbdk]

Hi Jan,
Really interesting project you've got going here! Love the idea that it's about programming and that it's language agnostic! It's the perfect excuse and opportunity for me to learn Go, which I'll have to use on my job soon 🙂 A question:

In the context of this project, what is understood by SDK?

Disclaimer: I've never done something like this before.

Quite naturally, when I started programming a Go solution for this project, I didn't wanna have to deal with the intricacies of how the gRPC generated functions works, all the time - so I started hiding the calls behind my own functions. Is that it? Or is there more to it 🙂 If it's as simple as hiding away the gRPC stuff, to give a more easy to understand interface, do you have any good theoretical ideas about how to best do it? Should an SDK provide almost all the same functionality as the gRPC functions, only just hiding away the more complex stuff (unpacking the responses, preparing the requests, giving dial options, etc.) or can the SDK really be everything required to arrive at a solution? Also, is solving the problem of landing the planes, also part of an SDK? Or should the SDK only just give people the functions to come up with their own solutions?

In short: What does a SDK have in it? 🙂

Thanks in advance 🙂

[jdno]

Hi Tobias,

Thanks for your interest in the project. 🙂

As you've experienced first hand, dealing with gRPC can be a bit difficult. Especially when you're either new to programming or new to gRPC. Getting protoc installed with the right plugins can be challenging, as can be figuring out how to actually use the generated code.

That's that the SDKs are supposed to solve: They package the generated code and distribute it through the different package managers. For example, if a player wants to use Ruby to play the game, they can simple install the Ruby gem and interact with the game through the Ruby API without having to run protoc. But this also means that the SDKs are only thin wrappers around the gRPC API. They do not implement any functionality on top of the game's API.

For the "official" SDKs that are part of this repository and distributed to the various different package managers, I want to keep it this way. This has three reasons:

1. Players should be free to choose their own adventure. The SDKs provide a basic set of tools, but have no opinion about the code the player writes. Functional, object oriented, one long method, it's all possible. This was important to me then starting the project.
2. It is possible to auto-generate the API bindings, reducing the maintenance burden of the project. There are already five SDKs, one for Python is being worked on, and I'd love to have even more. This is only possible, because most of the maintenance can be automated with GitHub Actions.
3. I am not an expert in the different languages. If someone contributes a path finding feature to the Java package, it will be hard for me to fix any bugs that might be found in the algorithm. But as the owner of the repository, I take on responsibility for any code that is merged into main.

That's why the SDKs are small in scope, and only package and distribute the generated gRPC bindings.

Now, if you want to create a Go library that has more features, absolutely go for it! I'd love to see an ecosystem of more advanced packages and libraries around the project, each using their language's unique paradigms and patterns. We can link to it from the documentation and the README so that people can find it. 🙂