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

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