Print Friendly

Generic vs. generated SDK

The internet is full of great services which can do cool things and maybe provide exactly the missing part needed for ones perfect project. But before using these services, one has to understand the interface (API) of it first. This means lots of reading, coding and testing until everything works. To minimize this barrier of entry, most APIs provide a software development kit (SDK) in parallel. The SDK is delivered in (hopefully) the same language used for the own project and can be integrated rather fast.

Comparing Generic vs. generated SDK

As you might imagine, SDKs are not all the same, and therefore in this blog article I will write about one of the main differences in SDKs from backend as a service solutions, which also differenciates apiOmat from most if not all other competitors.
The point is: when you create your own structures and models in your backend, how will that be reflected in the SDK? There are two variants:

In a generic SDK custom structures (models or classes) are not contained. The individual modelling happens in the client code, one time for each target language (ObjectiveC, Android, Javascript,…). Most times, key-value pairs are used as shown in the following Javascript example:

BaaSObject highScore = new BaaSObject("HighScore");
highScore.put("score", 2999);
highScore.put("name", "Jordan");;

In contrast, a generated SDK contains classes for all self defined models with getters and setters for their attributes. In the following example a class named Highscore was created in backend with the attributes “name” and “score”. The generated SDK then contains a corresponding class with the necessary methods:

HighScore score = new HighScore();

The code snipets may look very similar, but they have fundamental differences and consequences. apiOmat uses generated SDKs, and I want you to show why we think we can speed up your work and increase your fun working with apiOmat:

No typos

Using generic SDKs a highScore.get("Name") call will not return any results because the “N” is uppercase. Typos like this or a forgotten refactoring after a change of attribute names leads to errors hard to find. Sure, you can use constants or wrapper classes, but this works only in one target language. Porting an Android project to ObjectiveC requires the Highscore class to be completely be programmed again, doubling the work overhead.
In a generated SDK initial creation and later changes of models are done only on one place: the backend. On each client side, no changes have to be done but re-downloading the SDK.


Beside the error-proneness time plays a major role in development. Assuming a app should be developed for Android and iOS and have a little web frontend with PHP. In a generic SDK all models have to be created three times in different languages. When an attribute is added, addition has to be also done in all three ones.
In a generated SDK all changes are only done centrally in the backend. All clients must only re-download the SDK and integrate the included files in the IDE.

More comfortable

Because the content of a generated SDK is object oriented code (same on server side), there are some more less obvious but very helpful advantages:

  • a class “looks” his attributes; by using key value pairs one has to guess which attributes are contained
  • If your target language support type safetly, your SDK will, too. It won’t be possible to send characters as “score” – errors like these would be already reported by the compiler.
  • You can use inheritance modelled in the backend. The hierarchy will also be contained in the SDK. When using complex data models, using key-value pairs here would multiply overhead another time.

I hope that we could convince you of the advantages of the generated world and are happy to hear from you!


Posted on:
Username / Email

You don't have an account yet?
Get your free test version.
Retype password

Do you already have an account?