Being the Gentle Giant – Helping people integrate for the long haul – Helping developers integrate

View Github Repository Open presentation in a new window

mmcc

See all presentation from mmcc

Being the Gentle Giant – Helping people integrate for the long haul – Helping developers integrate

0 0

gentle-giant

Slides for talk on "Being the Gentle Giant"

On Github mmcc / gentle-giant

Being the Gentle Giant

Helping people integrate for the long haul

@matt_mcclure

What makes an API good?

Usefulness Design Support

Getting people to use an API

Usefulness, design, support Good enough (parity with DIY)

Deciding on an API is a big deal

APIs can help developers focus on their product's core competency ...but takes control out of their hands

Issues with that API can still have drastic negative affects (example)

Taking the job seriously

Frequently, developers use an API because they're unable to perform the task

  • Developers depend on API to function
  • API stability is important, but API *integration* stability is even more so

Helping developers integrate

Recognize that developers are going to vary wildly in skill

Easy Wins are fun

  • Everyone likes an easy win
  • Get to see basic usage examples
  • Get a quick feel for the service
  • Service gets to show off cool features
Don't just give them the easy win to hook them, show what a real integration looks like (Zencoder example)

Easy ends quick

  • Quick hacks never get refactored
  • Never get a chance to show best practices
  • Doesn't exclude non-fits
  • "As for what the language is in, its php with java of course" - User

Talk about best practices

  • Guides
  • Blog posts
  • Documentation
  • Support
  • Dinner with their family

Provide integration libraries

Integration libraries should just get out of the way

  • don't try to do or abstract too much
  • make sure it's easily maintainable. (minor API changes shouldn't break libraries)
  • Zencoder libraries examples

Provide Feedback

Have developers' backs...be proactive.

  • Don't just wait for things to break and them to send a support email
  • If you see potential issues or shortcomings in how they're using the API, *let them know*

Post-integration world

Once a customer is up and running, real support begins

How we like to think support will be

But really...

Be up front about downtime or potentially breaking changes

  • Let users know as soon as you confirm unscheduled downtime will occur
  • Eventually you'll have to deploy a chance that will break things...
    • Find all potentially affected users
    • Test recent requests
    • Contact them, contact them, contact them

Ask for feedback

  • Allows you to find annoyances, not just bugs
  • Lets developers know you care
  • Let users know as soon as you confirm unscheduled downtime will occur
  • If you have to deploy changes that could break certain things (JSON / YAML example)
    • Find all the users that have used those features in the last reasonable time period
    • Test their recent requests against the new changes
    • Contact them, contact them, contact them.

Take pride

The world of open APIs is amazing.

Questions?

@matt_mcclure