SDK generation#

An application working with invoices should be able to use the concepts its dataset defines. The query for unresolved invoices and the mutation that flags them for review already express agreed business behavior. Recreating those definitions in application code introduces another version of the agreement. A purpose-built SDK gives the application types and operations drawn from your dataset.

Your dataset#

The SDK represents the particular schemas, queries, mutations, and calculations your project has defined. An invoice project gets an interface to its invoice model and operations. Another project, with different definitions, gets a different SDK. Its purpose is to make your dataset's vocabulary available directly in the language of the application using it.

An object-relational mapping layer bridges differences between an application's object model and its database model. Keeping both models in agreement adds work when either changes. Separate teams can also develop different interpretations of the same records. The mapping can keep applications working while leaving that disagreement about meaning unresolved.

A purpose-built SDK starts with the definitions the dataset already owns. The application's types and callable operations can reflect those definitions instead of becoming another separately authored model. A call to flag invoices for review refers to the shared mutation and its selection rules. Application code can use that operation without recreating the conditions that make an invoice eligible.

Across teams#

Different teams can use different languages while working with the same dataset. Each needs an interface that fits its language, with the same meaning for the underlying concepts and operations. Purpose-built SDKs connect those language-specific interfaces to the definitions the teams share. The customer portal and accounting application can then use the same definition of an invoice balance through their own SDKs.