In today's world of web and mobile applications, APIs have become a fundamental building block. They enable software to interact with other software in a standardized way, making it possible to integrate disparate systems and share data. However, APIs alone do not provide a complete solution for developers looking to use them in their applications. This is where software development kits (SDKs) come into play.

An SDK is a set of software development tools that enable developers to create applications for a specific software platform or framework. In the context of APIs, an SDK typically includes libraries, code samples, and documentation that simplify the process of integrating the API into an application.

Offering your developers a good SDK will increase the adoption of your APIs and provide the necessary safeguards for how to access them.

Here are some of the reasons why adding an SDK to your API is beneficial:

: By providing an SDK, you can significantly reduce the time and effort required to integrate your API into an application. The SDK provides pre-built code libraries that developers can use to quickly and easily interact with your API, reducing the amount of time they need to spend coding and debugging. If you provide your developers only with an API, they will need to define things like auth logic, pagination, error handling, and other complex logic. This can be built-in into your SDK so developers can implement your API within one line of code. 

: When you provide an SDK, you're not just providing code libraries; you're also providing documentation and code samples that help developers understand how to use your API effectively. This makes it easier for developers to integrate your API into their applications and reduces the likelihood of errors or issues arising during development. IntelliSense and code suggestions will improve the DevEx of your API by giving your developers information about the available calls they can make. Built-in documentation guides developers on what to expect (request/response) in each API call. 

: When you make it easier for developers to use your API, you increase the likelihood that they will actually do so. This can help to drive adoption of your API and increase its overall usage. If you want to increase your API adoption, offering SDKs will help. 

: When you provide an SDK, you have more control over how developers interact with your API. This makes it easier to make changes or upgrades to your API without breaking existing applications that use it. By providing an SDK, you can ensure that developers are using your API in a consistent and supported way, which can reduce the risk of issues arising.

: An SDK can also help to improve the security of your API. By providing pre-built code libraries, you can ensure that developers are using secure coding practices when interacting with your API. This reduces the likelihood of security vulnerabilities arising due to coding errors or mistakes. You can also catch API errors in the SDK and have client-side logic to handle it. Retries are an example of how you can throttle the API access in event of errors. 

Adding an SDK to your API can provide significant benefits for both developers and API providers. It simplifies the integration process, improves the developer experience, increases adoption, makes maintenance and upgrades easier, and improves security. If you're developing an API, consider providing an SDK to help developers integrate your API more easily and effectively.

Building true idiomatic SDKs in multiple languages takes time and knowledge. Here at LibLab, we offer it as a simple, fast straightforward service. 

 and check how we can automatically build SDKs for your API in seconds, not months.

Why do I need to build an SDK

At the start of October we sent some of our code generation folks to Apollo’s GraphQL Summit in San Diego, California to talk to industry folks and better understand the trends the industry is headed, below are some of our findings and how they apply to what LibLab is going to be doing when generating GraphQL SDK’s as we near our production rollout.

Like any technology conference, there was plenty of silliness and humor to be had as companies sponsoring the event vied for your eyeballs and did anything and everything they could to get attendees to watch their product demos and presentations. 

All in all, it was all done in good spirits and we learned a few things from the event at hand that we felt we wanted to share with our readers and customers.

There were some really interesting talks that I wanted to cover before I discuss what we learned.

There’s a race to see which language might one day replace Java, and though that statement has been made multiple times across many decades and it’s still here and still strong, it was interesting to learn about how Rust doesn’t need garbage collection in the same way other languages do and why, also the number of available Cargo packages is minimal which provides a great opportunity for those looking to get their SDK’s out to users in that ecosystem.

Authorization is a bit more complicated in GraphQL

With REST you can limit administrative access, 

in order to avoid getting too complicated in your roles strategy, since GraphQL is one API path to rule them all so to speak. Auth tends to get a bit more complicated and you cannot escape providing user and access roles at the data level in order to avoid invalid access to secure information.

Reddit optimized mobile delivery in a big way

While moving away from a monolith Reddit was able to migrate into a single GraphQL service which then migrated into a Federation of services.

 means they could scale better and most importantly they were able to make their mobile application more real time by reducing updating payloads to the bare minimum necessary to reduce traffic while still supporting retries.

Since the industry is relatively new we’ve seen a large amount of new technology related adoption within the Web3 space and GraphQL is no different. The Graph Protocol which is made by The Guild and allows folks to easily convert blockchain data into valid GraphQL output impressed us a lot.

One of the most impressive of all of the talks in my opinion was the fact that Walmart completely redid their mobile apps and website as well as backend infrastructure in 14 months using GraphQL to seamlessly transition from their old legacy monolith over to a 

As we spoke with conference attendees the one question they all had for us is 

why would they want to give their customers a self branded GraphQL SDK? 

They were wondering in what ways we could top the good work done in both Apollo Client and The Guild, and how we could possibly support 

Being able to support any and everyone of your GraphQL customers in any language they already work in with a library branded to your company and the work that you are doing is crucial for any company creating a business out of their own API’s through their SDK’s. 

Branded SDK’s help control the end user experience

The GraphQL community is primarily focused on giving users a great Web and Mobile Experience which is mostly a client to server prerogative and they already do an amazing job with that. But we at LibLab believe that most companies can benefit from GraphQL by opening up access to their API to everyone including server to server communication due to the decreased payload and thus bandwidth benefits GraphQL brings to the table.

Federation and the Supergraph is how Apollo and many in the industry see this sharing of resources problem being solved in the long run, a decentralized set of API services all sharing data and resources using the Apollo Router and it’s server side magic and we don’t disagree with this approach in principle. However, there will always be customers

 who stand outside of the industry and just want something that works in their language and chosen framework.

Everyone has API customers that maybe don’t want to use or learn GraphQL themselves and it’s critical to give them options that meet them where they are at. Using a LibLab generated GraphQL SDK gives those customers an option that just works without them needing to know any GraphQL.

The need for Multiple Language Client’s Support

By supporting GraphQL client SDK’s natively in any and all languages we build, we ensure your GraphQ

L API has the furthest developer reach possible. Whether your customers use Python or Java for example, they won’t have to settle for handling request and response themselves. They can also benefit from some of the features we already support across all of our generated SDK’s including built in retry strategies and error handling. We also generate models and interfaces based on schemas that are already properly defined to work with any language.

Now that’s not to say that we won’t support 

 when it comes to the languages that already have great clients such as choosing Apollo during SDK generation with an option for both Typescript and Kotlin generated SDK’s as an example. But our goal is to generate an SDK that goes above and beyond what the industry expects so as we roll out feature changes across all of our SDK generation, our GraphQL generated SDK’s will benefit from the optimizations and improvements.

Custom Queries will help streamline onboarding

The further you dive into GraphQL the more you realize just how powerful it is for customers, yet the complexity of formulating some of larger or

 was a pain point some at the conference had experienced. When we pitched customers our idea of custom queries, they loved the simplicity of pre-writing some of their more complicated GraphQL queries in an easy to handle set of functions for their less advanced customers to use.

As we design generated GraphQL SDK’s for customers, we still want to give them methods and room to play with and experience all that their GraphQL API has to offer, yet simplifying the onboarding of customers in a way that met the customer where they were at while at the same time expanding their horizon into what’s possible was pivotal for many.

At the end of the day the industry is still new and the direction that Federation, Supergraph and eventually the Global Graph will take us is unlimited.

, we believe in helping our GraphQL API customers to meet their customers where they are already at and help usher them into that new future in the simplest and cleanest way possible. 

Help us do that by signing up for our Beta Program and providing us with a copy of your schema.  We’ll generate an SDK for you to review and all we ask is for feedback on what we are doing and how you eventually want your GraphQL SDK to look like for your customers

LibLab’s GraphQL Summit 2022 Recap

In 2016 GitHub released the first large-scale, public 

 proving to everyone that GraphQL is here to stay. Their API is robust and constantly evolving, and it provides developers the tools to “

create integrations, retrieve data, and automate your workflows”.

 — a tool to help developers do what they love most: automate things. With GitHub Actions you can automate your CI/CD and general project management using YAML files.

You can use GitHub’s GraphQL API in the GitHub Actions workflow files to create the automation of your dreams.

GraphQL was originally developed by Facebook as a way of cutting down response payload. With a 

 you get back everything that an entry has to offer. Let’s say we have a database of customers where a customer entry might look like the following:

"Customer" : {
		"id" : "101010",
		"first_name" : "Bjarne",
		"last_name" : "Stroustrup",
		"email" : "fake_bjarne@gmail.com",
		"City" : "Austin",
		"State" : "Texas",
		...
}

Now let’s say we have the customer’s id and we just want their first name so we can print “Hello, Bjarne!”. Using a REST call will return all the fields for a customer when we only need a single field. This is where GraphQL comes in. With GraphQL you create a query specifying the fields you need and only those fields are returned. 

Let’s look at a simple GraphQL query that calls on the GitHub GraphQL API:

query FindRepoID {
       repository(owner:"YOUR_ORGANIZATION_NAME", name:"REPOSITORY_NAME") {
    			id
         }
       }

The query calls on the repository query with your organization name and the repository name, and returns the id of that repository.

Here is an example of a response of this query: 

{
  "data": {
    "repository": {
      "id": "R_ktHp3iGA",
    }
  }
}

The repository object has 119 fields, but we only asked for one and therefore only received one. Had we used a REST call we would have received all 119 fields.

To create a workflow for a repository we need to create a workflow YAML file in the .github/workflows directory. If your project doesn’t have those directories, go ahead and create them.

Let’s look at a very basic workflow.yaml file:

name: My First Action ## name of our workflow
on: create ## branch or tag being created trigger
jobs: ## jobs to run when triggered
  echo-branch-name: ## name of a job
    runs-on: ubuntu-latest ## which machine the job runs on
    steps: ## steps to run
      - name: Step One ## name of a step
        run: | ## commands to run 
            echo '${{ github.event.ref }}'

A workflow is triggered by events (you can see a list of events that trigger a workflow 

). In this case our workflow is triggered 

 in the workflow’s repository. Once the workflow is triggered, our jobs start running on the type of machine we chose. In this case we simply echo the name of the branch from the ${{ github.event }} variable.

Connecting  Branches With Issues Using GitHub Actions and GitHub GraphQL API

First, let’s decide on a branch naming system. For this example we decide that for every Issue there is a branch with a name that starts with the Issue’s number

. For example, an Issue numbered #42 will have a branch with a name that starts with #42, like “#42/awesome_branch”.

We’ll start off by getting the Issue number from the branch’s name.

name: New Branch Created 

on:
  create
    
jobs:
  On-New-Branch:
    runs-on: ubuntu-latest
    steps:
      - name: Get Issue Number
        run: |
          branch_name=`echo '${{ github.event.ref }}'`
          issue_num=`echo ${branch_name#*#} | egrep -o '^[^/]+'`

        

For this example if a branch was created without an issue number at the start of its name we will ignore it and the workflow will not continue. To do so we’ll create output variables that the next job can use to determine if to execute or not.

name: New Branch Created 

on:
  create
    
jobs:
  Check-Branch-Name:
    runs-on: ubuntu-latest
    outputs:
      issue_num: ${{ steps.step1.outputs.issue_num }}
      tracked: ${{ steps.step1.outputs.tracked }}
    steps:
      - name: Get Created Issue Number
        id: step1
        run: |
          branch_name=`echo '${{ github.event.ref }}'`
          issue_num=`echo ${branch_name#*#} | egrep -o '^[^/]+'`
          re='^[0-9]+$'
          if ! [[ $issue_num =~ $re ]] ; then
            echo "::set-output name=tracked::false"
          else
            echo "::set-output name=tracked::true"
          fi
          echo "::set-output name=issue_num::$issue_num"


We check if issue_num is actually a number - if it is a number, we set an output variable named ‘tracked’ to be ‘true’, and if it is not a number we set it to be ‘false’. To use the issue number in the next steps, we also save it in an output variable named ‘issue_num’.

The next job created will need those outputs to run:

name: New Branch Created 

on:
  create
    
jobs:
  Check-Branch-Name:
    runs-on: ubuntu-latest
    outputs:
      issue_num: ${{ steps.step1.outputs.issue_num }}
      tracked: ${{ steps.step1.outputs.tracked }}
    steps:
      - name: Get Created Issue Number
        id: step1
        run: |
          branch_name=`echo '${{ github.event.ref }}'`
          issue_num=`echo ${branch_name#*#} | egrep -o '^[^/]+'`
          re='^[0-9]+$'
          if ! [[ $issue_num =~ $re ]] ; then
            echo "::set-output name=tracked::false"
          else
            echo "::set-output name=tracked::true"
          fi
          echo "::set-output name=issue_num::$issue_num"

  Add-Linked-Issue-To-Project:
    needs: Check-Branch-Name
    if: needs.Check-Branch-Name.outputs.tracked == 'true'
    env: 
        ISSUE_NUM: ${{ needs.Check-Branch-Name.outputs.issue_num}}
    runs-on: ubuntu-latest
    steps:
      - name: Get Issue ${{ env.ISSUE_NUM }} Project Item ID
        run: |


We specify the dependency on the first job with ‘needs’ and check if the job should execute using an if statement with the output variable ‘tracked’ from the previous job. We also make use of env variables here - environment variables are used to store information that you want to reference in your workflow. Env variables can be set for an entire workflow, for a specific job or for a specific step. To access the content of an env variable use ${{ env.NAME_OF_VARIABLE }}.

To make calls on the GraphQL API we need a GitHub authorization bearer token for our repository. To create one 

, copy your generated token and save it under your repository’s settings as an Actions secret (repository Settings → Secrets → Actions → New repository secret). Name it PERSONAL_TOKEN to match the example. We’re also going to need our organization name and the repository’s name set as our workflow’s environment variables:

name: New Branch Created 

on:
  create

env:
    GH_TOKEN: ${{ secrets.PERSONAL_TOKEN }}
    ORGANIZATION: your-organization-name
    REPO: the-repository-name
    
jobs:
  Check-Branch-Name:
    runs-on: ubuntu-latest
    outputs:
      issue_num: ${{ steps.step1.outputs.issue_num }}
      tracked: ${{ steps.step1.outputs.tracked }}
    steps:
      - name: Get Created Issue Number
        id: step1
        run: |
          branch_name=`echo '${{ github.event.ref }}'`
          issue_num=`echo ${branch_name#*#} | egrep -o '^[^/]+'`
          re='^[0-9]+$'
          if ! [[ $issue_num =~ $re ]] ; then
            echo "::set-output name=tracked::false"
          else
            echo "::set-output name=tracked::true"
          fi
          echo "::set-output name=issue_num::$issue_num"

  Add-Linked-Issue-To-Project:
    needs: Check-Branch-Name
    if: needs.Check-Branch-Name.outputs.tracked == 'true'
    env: 
      ISSUE_NUM: ${{ needs.Check-Branch-Name.outputs.issue_num}}
    runs-on: ubuntu-latest
    steps:
      - name: Get Issue ${{ env.ISSUE_NUM }} ID and State
        run: |
          gh api graphql -f query='query FindIssueID {
            repository(owner:"${{ env.ORGANIZATION }}",name:"${{ env.REPO }}") {
                issue(number:${{ env.ISSUE_NUM }}) {
                      id,
                      state
                      }
                    }
                  }' > project_data.json
          echo 'ISSUE_ID='
           $(jq '.data.repository.issue.id' project_data.json) 
            >> $GITHUB_ENV
          echo 'ISSUE_STATE='
           $(jq '.data.repository.issue.state' project_data.json) 
            >> $GITHUB_ENV
                

We created a step called “Get Issue ${{ env.ISSUE_NUM }} ID and State”. In this step we run a GraphQL query and save its result into project_data.json. The query finds a repository by its organization name and repo name, then looks for an issue by its number and returns the issue’s id and state. We save the issue id and issue state from the result into env variables called ISSUE_ID and ISSUE_STATE for later use.

We use GitHub’s “gh api” to make an authenticated HTTP  request to the GitHub API. 

Our endpoint is the GraphQL API, and the flag -f  adds a string parameter in key=value format so the key ‘query’ is set to be our raw GraphQL query FindIssueID.

name: New Branch Created 

on:
  create

env:
    GH_TOKEN: ${{ secrets.PERSONAL_TOKEN }}
    ORGANIZATION: your-organization-name
    REPO: the-repository-name
    
jobs:
  Check-Branch-Name:
    runs-on: ubuntu-latest
    outputs:
      issue_num: ${{ steps.step1.outputs.issue_num }}
      tracked: ${{ steps.step1.outputs.tracked }}
    steps:
      - name: Get Created Issue Number
        id: step1
        run: |
          branch_name=`echo '${{ github.event.ref }}'`
          issue_num=`echo ${branch_name#*#} | egrep -o '^[^/]+'`
          re='^[0-9]+$'
          if ! [[ $issue_num =~ $re ]] ; then
            echo "::set-output name=tracked::false"
          else
            echo "::set-output name=tracked::true"
          fi
          echo "::set-output name=issue_num::$issue_num"

  Add-Linked-Issue-To-Project:
    needs: Check-Branch-Name
    if: needs.Check-Branch-Name.outputs.tracked == 'true'
    env: 
      ISSUE_NUM: ${{ needs.Check-Branch-Name.outputs.issue_num}}
    runs-on: ubuntu-latest
    steps:
      - name: Get Issue ${{ env.ISSUE_NUM }} ID and State
        run: |
          gh api graphql -f query='query FindIssueID {
            repository(owner:"${{ env.ORGANIZATION }}",name:"${{ env.REPO }}") {
                issue(number:${{ env.ISSUE_NUM }}) {
                      id
                      state
                      }
                    }
                  }' > project_data.json
                  echo 'ISSUE_ID='
                   $(jq '.data.repository.issue.id' project_data.json) 
                     >> $GITHUB_ENV
                  echo 'ISSUE_STATE='
                   $(jq '.data.repository.issue.state' project_data.json) 
                     >> $GITHUB_ENV
                           
      - name: Reopen Issue
        if: ${{ env.ISSUE_STATE }} == 'CLOSED'
        run: |
         gh api graphql -f query='
            mutation {
              reopenIssue(input: { issueId: ${{ env.ISSUE_ID }} } ){
              issue {
                     title
                     state
                }
              }
            }'

 query that runs if the issue state is closed. 

We run this query in case we closed the issue in the past and want to reopen it once a branch for it exists, implying that the fix was not done. 

, quick and simple Workflow file that uses GitHub Actions with GraphQL queries to reopen an issue by a branch being created for it. You can modify this basic example to your own needs — you can run a job when a PR is created, you can run a job when an issue is opened, you can run a job every time a commit is made to a branch or run a job on any 

you desire. You now have the tools to create your own automation.

Here are some more advanced examples of using the GitHub GraphQL API with GitHub Actions:

 moves a newly created issue into a specific column in a project. 

 connects branches to issues by branch name. When a branch is created for an issue, the issue will move to a specific column in a project. If the issue was closed prior to the creation of the branch, the issue will reopen.

 connects PRs to issues by branch name. When a PR is created/closed/merged the issue will move to a specific column in a project. Once an issue is moved to the ‘Done’ column the issue will be closed.

If you use these three workflows, your GitHub project’s card management should work similar to this:

Not ready to embark on the GraphQL adventure? Looking for something out of the box to automate your workflows? Looking to mix it all up? Check out GitHub’s 

. You can use the REST API instead of the GraphQL API, or you can integrate one of the apps or actions available in the GitHub Marketplace into your workflows. Whichever way you choose, automating your workflows will save you valuable time that you can now use for more coding! Woohoo!

Trying to use a Marketplace app or action but getting “Resource not accessible by integration” error? Most Marketplace apps and actions use the default “secrets.GITHUB_TOKEN”, but this token doesn’t come with read/write access to all scopes. For example, it doesn’t have write permissions for items in Projects. Set a personal access token like we did in the examples and use it instead of the GITHUB_TOKEN (make sure you give it the correct permissions).

If you’re using the GitHub GraphQL Documentation but having a hard time understanding and making queries work, take a look at the 

. The Documentation there is clear and they have an Explorer section where you can try out queries and see their responses.

Our goal here at LibLab is to make the lives of developers easier, and that includes our own developers. If we can automate it and save time, we will — leaving our developers all the time they need to focus on the tasks that matter. If you’re looking to save time and automate your SDK creation, if you want flawless SDKs in multiple languages directly from your API, and if you care about making developers’ lives easier, check out what 

Using GitHub GraphQL API With GitHub Actions

GitHub is a popular version control system that allows developers to share and manage their code. Here at LibLab we wanted to store the code that our SDK generator wrote, automatically and in a natural way. In this case, we ended up using Octokit, GitHub’s official Javascript and Typescript SDK.

To get started we are going to install Octokit.

Then we can create our typescript entry point. In this case 

import { Octokit } from '@octokit/rest';
const client = new Octokit({
	auth: '<AUTH TOKEN>'
});

We instantiate the Octokit constructor and create a new client. We will need to replace the 

 with a personal access token from GitHub. 

Checkout the guide to getting yourself a personal access token from GitHub.

Now that we have our client setup we are going to look at how we can create files and commit them to a repository. In this tutorial I am going to be writing to an existing repo. This will allow you to write to any repo public or private that you have write access to.

Just like using git or the GitHub desktop application we need to do a couple of things to add a file to a repository.

To create a tree we need to get the latest commits. We will use the 

 is the username or name of the organization the repository belongs to and 

const commits = await client.repos.listCommits({
	owner: "<USER OR ORGANIZATION NAME>",
	repo: "<REPOSITORY NAME>",
});

We now want to take that list of commits and get the first item from it and retrieve its SHA hash. This will be used to tell the tree where in the history our commits should go. To get that we can make a variable to store the commit hash.

Now that we have our latest commit hash we can begin constructing our tree. We are going to pass the files we want to update or create to the tree construction method. In this case I will be representing the files I want to add as an Array of Objects. In my example I will be adding 2 files. 

const files = [
	{
		name: "test.md",
		contents: "Hello World"
	},
	{
		name: "time.txt",
		contents: new Date().toString()
	}
];

interface File {
  path: string;
  mode: '100644' | '100755' | '040000' | '160000' | '120000';
  type: 'commit' | 'tree' | 'blob';
  sha?: string | null;
  content: string;
}

There are a couple of properties in this interface.

We can map to transform our file array into this proper format:

const commitableFiles: File[] = files.map(({name, contents}) => {
	return {
		path: name,
		mode: '100644',
		type: 'commit',
		content: contents
	}
})

Now that we have an array of all the files we want to commit we will pass them to the 

 method. You can think of this as adding your files in git. 

const {
      data: { sha: currentTreeSHA },
    } = await client.git.createTree({
      owner: "<USER OR ORGANIZATION NAME>",
			repo: "<REPOSITORY NAME>",
      tree: commitableFiles,
      base_tree: CommitSHA,
      message: 'Updated programatically with Octokit',
      parents: [CommitSHA],
    });

 . We will need this when we actually commit the files.

Next we go to actually make a commit on the tree

const {
      data: { sha: newCommitSHA },
    } = await client.git.createCommit({
      owner: "<USER OR ORGANIZATION NAME>",
			repo: "<REPOSITORY NAME>",
      tree: currentTreeSHA,
      message: `Updated programatically with Octokit`,
      parents: [

await client.git.updateRef({
      owner: "<USER OR ORGANIZATION NAME>",
			repo: "<REPOSITORY NAME>",
      sha: newCommitSHA,
      ref: "heads/main", // Whatever branch you want to push to
    });

That is all you need to do to push files to a GitHub repository. We have found this functionality to be really useful when we need to push files that are automatically generated or often change.

If you find yourself needing to manage SDKs in multiple languages from an API, checkout LibLab. Our tools make generating SDKs dead simple with the ability to connect to the CI/CD tools you are probably already using.

Writing Files to Github with Octokit and Typescript

Client libraries are shared code to avoid repetitive tasks. Engineers love client libraries. In iOS, libraries are also referred to as frameworks or SDKs. In this post, I’ll stick to using the term 

I’ll show you a common pattern to build a library. Libraries are used everywhere. 

If you think this is a daunting task, worry not! Keep reading and you’ll see it’s easier than you think.

The goal of this post will be to build a library that

Retrieves the latest price of a list of cryptocurrencies

The library is used in a sample app that shows these prices

. With this API you can retrieve current and historic information about cryptocurrencies.

By checking their documentation, you will notice their API is extensive. For this post, only the 

 to create your own API KEY. You will need one to make requests to their service.

Nowadays it is very simple to create a new library in Swift. In iOS, the modern way to publish and deliver libraries is via the 

. From here on out, I’ll walk you step-by-step on how to create the library.

Create a new Xcode project. Make sure you select Swift Package as the project type.

Follow the instructions and you’ll decide where to save the project on your machine. I named the library 

for this tutorial. After the project is created, notice the file named 

// swift-tools-version: 5.6

import PackageDescription

let package = Package(
    name: "MyCryptoCoinSwiftLibrary",
    products: [
        // Products define the executables and libraries 
				// a package produces, and make them visible to 
				// other packages.
        .library(
            name: "MyCryptoCoinSwiftLibrary",
            targets: ["MyCryptoCoinSwiftLibrary"]),
    ],
    dependencies: [
        // Dependencies declare other packages that this package
				//  depends on.
        // .package(url: /* package url */, from: "1.0.0"),
    ],
    targets: [
        // Targets are the basic building blocks of a package. 
				// A target can define a module or a test suite.
        // Targets can depend on other targets in this package, 
				// and on products in packages this package depends on.
        .target(
            name: "MyCryptoCoinSwiftLibrary",
            dependencies: []),
        .testTarget(
            name: "MyCryptoCoinSwiftLibrary Tests",
            dependencies: ["MyCryptoCoinSwiftLibrary"]),
    ]
)

If you want to know more about each field in this file, take a gander at the 

 site by Apple. Know that in a package, you can add resources like images and videos, and not just code. The library in this post is fairly simple because it only interacts with a server API.

 from the list of targets. I will not focus on how to write unit tests for our library in this tutorial. Yet, unit tests are very important for a real library, you want make sure you doesn’t introduce critical bugs.

Because the library needs to connect with the CoinMarketCap API, a networking layer is needed. For that, our library will make use of the most famous networking library in iOS, 

. In their documentation, there are instructions on how to add it as a dependency in our Package.swift, 

This sample library will only support iOS, so make sure to list it in the 

After those modifications, Package.swift now looks like this:

// swift-tools-version: 5.6

import PackageDescription

let package = Package(
    name: "MyCryptoCoinSwiftLibrary",
    platforms: [
        .iOS(.v10)
    ],
    products: [
        // Products define the executables and libraries a 
				// package produces, and make them visible to 
				// other packages.
        .library(
            name: "MyCryptoCoinSwiftLibrary",
            targets: ["MyCryptoCoinSwiftLibrary"]),
    ],
    dependencies: [
        // Dependencies declare other packages that this package 
				// depends on.
        // .package(url: /* package url */, from: "1.0.0"),
      .package(url: "https://github.com/Alamofire/Alamofire.git", 
			.upToNextMajor(from: "5.6.1"))

    ],
    targets: [
        // Targets are the basic building blocks of a package. 
				// A target can define a module or a test suite.
        // Targets can depend on other targets in this package, 
				// and on products in packages this package depends on.
        .target(
            name: "MyCryptoCoinSwiftLibrary",
            dependencies: ["Alamofire"], // Important so 
							// Alamofire can be used in your library.
            path: "Sources"), // Short explanation: What
							// you want the library to expose to the public.
    ]
)

After you add dependencies to your library, you should see them listed in your Xcode project. From here, the setup is done and all that is left is the code!

The code will be simple. I won’t overcomplicate the library with a complex design. There will be a struct called 

public func latestPrice(
						coins: [String], 
completionHandler: @escaping (Result< Coins, AFError>) -> Void)

This expects to receive a list of coins to retrieve their latest price. For this tutorial keep it simple and stick with just supporting the cryptocurrency symbol, for example, “BTC”, “ETH”.

It will return the response with the block 

 is listed as the success value, and this is something that I’ll explain now.

This function will call the CoinMarketCap API endpoint 

. As listed in their docs, a sample response is:

Instead of parsing the JSON, a better approach is to create models that represent the response of the API.

From bottom to top, three models can be identified for this response.

public struct Quote: Decodable {
    public let price: Double
}

public struct Coin: Decodable, Identifiable {
    public let id: Int
    public let name: String
    public let symbol: String
    public let quote: [String: Quote]
}

his model is used in the sample app. This model is the input of a List View. To simplify the classes that are used in this tutorial, the List View requires the model to be Identifiable.

In a real scenario, I would suggest creating an extra model or class that is used in the UI, to keep this one decoupled from the client logic.

public struct Coins: Decodable {
    public let data: [String: [Coin]]
}

Notice that all the members of these models match a value from the API response. As an example, let’s say that Coin also cares about 

 from the response, in that case Coin would look like

public struct Coin: Decodable, Identifiable {
    public let id: Int
    public let name: String
    public let symbol: String
    public let maxSupply: Int
    public let quote: [String: Quote]
		
		enum CodingKeys: String, CodingKey {
			case id
			case name
			case symbol
			case maxSupply = "max_supply"
			case quote
		}
}

This is to illustrate what is needed to support names that do not map between the response and the model members. No need to add it for this tutorial.

import Alamofire // 1. Import dependency listed in Package.swift

public struct CoinRetriever {
    private var apiKey: String; // 2. apiKey is needed for the 
			// CoinMarketCap API
    
    public init(apiKey: String) {
        self.apiKey = apiKey;
    }
    
    public func latestPrice(coins: [String], completionHandler: 
			@escaping (Result< Coins, AFError>) -> Void) {
        let headers: HTTPHeaders = [ // 3. Headers needed by 
					// CoinMarketCap
            "X-CMC_PRO_API_KEY": apiKey,
            "Accept": "application/json",
            "Accept-Encoding": "deflate, gzip"
        ]
        let parameters: Parameters = ["symbol": 
					coins.joined(separator: ",")] 
				// 4. The parameter that this method will support. 
				// E.g. "BTC", "ETH"
				// 5. Alamofire request to the endpoint, it decodes
				// the value to the Coins model previously created
				let endpoint = "https://sandbox-api.coinmarketcap.com" +
					"/v2/cryptocurrency/quotes/latest"
        AF.request(endpoint, 
          parameters: parameters, 
					headers: headers)
					.responseDecodable(of: Coins.self) { response in
            guard let coins = response.value else {
                completionHandler(.failure(response.error!))
                return
            }
            completionHandler(.success(coins))
        }
    }
}

Steps to make a request using Alamofire and decoding the response into the models.

Import the dependency listed in Package.swift. This will be used to make the actual request to the API.

CoinMarketCap needs an API KEY to authenticate its request, if you still don’t have one, 

Apart from putting the API KEY in the headers, they also 

 to see what other parameters are supported. For this tutorial only “symbol” will be used.

Alamofire does the request. It decodes the response as the Coins model created before.

This step is the simplest of all. SPM works with Github out of the box. All you need to do is upload the library project to a Github repository. In this case, I created the repo 

. From here, it’s all about advertising your repo, which is out of the scope of this post.

As an extra step, you might be wondering how would someone use your new library. To demonstrate this, create a sample app.

In Xcode create a new iOS app. I named mine CryptoCoinSampleApp.

As a suggestion, add the sample app to the same directory where you created the library. This way you will include a sample app alongside your library as part of your repository.

Now the important step is how to add your library that now lives in github. As a matter of fact, this process is the same for any other library published through SPM.

 (remember the Xcode version I used! this UI/menu can change in a different Xcode version). It will open up a menu like the following

Notice I searched for the Github repo where the library was published, that’s how you will find yours too. In a production library, instead of using a specific branch to get the code from, the normal use case is to specify a release version, something like 1.0.0. By the time you are using this approach you should be more comfortable building libraries.

After this, your code will have access to your new library, and you can import it like this:

Since the app itself is out of the scope of this tutorial, I will only point you to it in the 

Play with it! Create a PR with a suggestion, create an issue in the repo, let me know what you think! Feel free to use the library as well in your own sample app!

The previous screenshot shows the response of the library in the sample app.

As you work on this tutorial, you might notice that a lot of what was coded is very repetitive and tedious. At LibLab, our goal is to automate this process. We have a product that will let you create what I explained in this tutorial in an automatic way. For a lot of languages and different platforms, not just Swift and iOS.

 to connect with us and soon enough join our beta launch! Check the 

 for all the news and more of this content!

Create an API client library for iOS in Swift

Some people see technical debt as a list of missing features, but it should be a list of the problems that you know you have to vs want to solv

e. The list can vary but should include known bugs and errors in your code. It should also include how readable your code is and any bloat you might carry. Slowness in build and execution time needs consideration as well.

The point of figuring out your technical debt ahead of time is that you need to be honest with yourself. The more problems we have to solve, the less we get to work on problems we want to solve. So we treat technical debt the same as financial debt, by paying it down while avoiding more.

The rule of thumb should always be to pay off your debts first, then start accumulating assets because you don’t want to try to pay for assets when you have debts holding you down.

Why do I need to build an SDK

LibLab’s GraphQL Summit 2022 Recap

Using GitHub GraphQL API With GitHub Actions

Writing Files to Github with Octokit and Typescript

Create an API client library for iOS in Swift

Accruing Technical Assets vs paying off Technical Debt

Thinking of GraphQL SDK's as an Active Record pattern or Web ORM

A Big Look at Security in OpenAPI

Follow

Product

Company

Legal