1.
CREATING A GREAT
DEVELOPER EXPERIENCE
THROUGH SDKS

2.
Developer Evangelist at Keen IO
taylor@keen.io
@taylor_atx
TAYLOR BARNETT

3.
@taylor_atx

4.
Collect & store data from
users, websites, apps &
smart devices.
Query instantly to share
results with teams &
customers, anywhere.
@taylor_atx

5.
LET’S BE REAL ABOUT SDKS
@taylor_atx

6.
Most API providers aren’t updating
their SDKs enough
😞
@taylor_atx

7.
Get the most attention when they are 🔥broken🔥
@taylor_atx

8.
Many of SDKs are now open source,
which is great, but…
@taylor_atx

9.
There are a lot of great HTTP request
libraries out there now
🎉
@taylor_atx

10.
We could talk for a really long time
about why using SDKs aren’t great
@taylor_atx

11.
WHY SHOULD YOU
PROVIDE SDKS?
@taylor_atx

12.
Most of the time using an API is
important, but peripheral to why the
software is being written
@taylor_atx

13.
Your SDKs are your API
@taylor_atx

14.
SDKs give quick feedback on how your
API works
@taylor_atx

15.
There’s a business case for putting
resources into SDKs
@taylor_atx

16.
OTHER REASONS
• When there’s no good built in HTTP request library
• Error handling
• Building clients with 100% API coverage
• Helping users with authentication
• Best practices with complex APIs
@taylor_atx

17.
CREATING A GREAT
DEVELOPER EXPERIENCE
@taylor_atx

18.
PRODUCT VS COMMUNITY SDKS
• Clearly define the two to set better expectations
• If you don’t build them, Community SDKs will appear
• Leads to a scattered developer experience
• Community SDK bugs will appear in your Support channels
@taylor_atx

19.
DOCUMENTATION
• Write the SDK documentation first
• Consistency
• Helps evaluate the experience
@taylor_atx

20.
DOCUMENTATION
• Include sections for
• Troubleshooting, with common errors and issues users run
into —> Your Support team will love you for this
• Changelog or release notes
@taylor_atx

21.
SCARY WORLD OF DEPENDENCIES
• Help your users navigate it
• Users need to know changes between SDK versions
• Survey your options
😱
@taylor_atx

22.
DANGERS OF NOT MAKING YOUR OWN SDKS
• Not eating your own dog food is dangerous
• Helps you understand the cost of building with your own API
• It’s also encouragement to add new API features into your
SDK when they released, not later
@taylor_atx

23.
NATIVE AS POSSIBLE
• Please do not auto generate SDKs badly from your API
• Example: Go find a Go developer to write your Go SDK
• Start with the languages that are the most popular for your
target audience and that your team is familiar with
@taylor_atx

24.
COMMON DATA STRUCTURES
• Avoid inconsistency in your users’ code
• Example: JSON is a great option for representing data
• Want to map well to data structures in many different
languages
@taylor_atx

25.
USAGE TRACKING
• Great opportunity to learn about your users
• Critical statistics for developing, maintaining, and improving
your SDKs
• Every popular API company today is tracking this: SendGrid,
Twilio, Stripe, Dropbox, etc.
@taylor_atx
📊

26.
# Example from the Twilio Python module
# https://github.com/twilio/twilio-python
user_agent = "twilio-python %s (python-%s)" % (
LIBRARY_VERSION,
platform.python_version(),
)
headers = {
"User-Agent": user_agent,
"Accept-Charset": "utf-8",
}
USAGE TRACKING
@taylor_atx

27.
EXAMPLES
@taylor_atx

28.
💖
THANK YOU!
taylor@keen.io
@taylor_atx