Comparing Generic vs. generated SDK

As you might imagine, SDKs are not all the same. This blog article is about one of the main difference in backend as a service solutions SDK's, which also differentiates ApiOmat from most if not all other competitors.

The point is: when you create your own classes in your backend, how will that be reflected in the SDK? There are two variants:

In a generic SDK there are no custom classes 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"); highScore.save();

In contrast, a generated SDK contains classes for all self defined classes with getters and setters for their attributes. In the following example a class named Highscore was created backend with the attributes “name” and “score”. The generated SDK then contains a corresponding class with the necessary methods:
HighScore score = new HighScore(); score.setScore(2999); score.setName("Jordan"); score.save();

The code snippets may look very similar, but they have fundamental differences and consequences. ApiOmat uses generated SDKs, and we are going to tell you how working with ApiOmat can speed up your work.

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 that are 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 classes are done only in one place: the backend. On each client side, no changes have to be done but re-downloading the SDK.

Faster

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 classes have to be created three times in different languages. When an attribute is added, this addition also has to be done in all three classes.
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” like its attributes; by using key value pairs one has to guess which attributes are contained

• If your target language supports type safely, 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 modeled in the backend. The hierarchy will also be contained in the SDK. When using complex classes, using key-value pairs here would multiply overhead another time.

We hope that we have convinced you of the advantages of the generated world and are happy to answer any questions or concerns.