Social dev camp_2011
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Social dev camp_2011

on

  • 958 views

Presentation on building an API and what it means to be a startup - chicago social devcamp 2011

Presentation on building an API and what it means to be a startup - chicago social devcamp 2011

Statistics

Views

Total Views
958
Views on SlideShare
889
Embed Views
69

Actions

Likes
1
Downloads
4
Comments
0

3 Embeds 69

http://lanyrd.com 66
http://twitter.com 2
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Social dev camp_2011 Presentation Transcript

  • 1. Craig Ulliott likes building things
  • 2. About me
  • 3. About me• Needs to know how everything works
  • 4. About me• Needs to know how everything works• Likes things that scale
  • 5. About me• Needs to know how everything works• Likes things that scale• Think’s almost everything is inefficient
  • 6. About me• Needs to know how everything works• Likes things that scale• Think’s almost everything is inefficient• Hates people
  • 7. About me• Needs to know how everything works• Likes things that scale• Think’s almost everything is inefficient• Hates people • Just kidding
  • 8. About me• Needs to know how everything works• Likes things that scale• Think’s almost everything is inefficient• Hates people • Just kidding • But people are the cause of all the worlds inefficiencies
  • 9. About me• Needs to know how everything works• Likes things that scale• Think’s almost everything is inefficient• Hates people • Just kidding • But people are the cause of all the worlds inefficienciesWhat I do and have done:
  • 10. Mistakes I’ve Made
  • 11. Mistakes I’ve MadeLessons I’ve Learned.
  • 12. Minimum Viable Product
  • 13. Minimum Viable Product• Short sprints (release code regularly)
  • 14. Minimum Viable Product• Short sprints (release code regularly)• Spend an hour thinking about why you’re building something, before you spend a week thinking about how.
  • 15. Minimum Viable Product• Short sprints (release code regularly)• Spend an hour thinking about why you’re building something, before you spend a week thinking about how.• Your developing a business not a website
  • 16. Surround yourself with business people
  • 17. Surround yourself with business people• If you have a good idea, a strong technical co- founder and a business co-founder - you will get money / incubated / successful
  • 18. Surround yourself with business people• If you have a good idea, a strong technical co- founder and a business co-founder - you will get money / incubated / successful• I get asked every 3 days if I know any developers - why are you guys not meeting each other!
  • 19. Bootstrap if you can
  • 20. Bootstrap if you can• BUSINESSES that work when they are small are easier to scale
  • 21. Bootstrap if you can• BUSINESSES that work when they are small are easier to scale• The first step to becoming an Entrepreneur is not quitting your job
  • 22. Bootstrap if you can• BUSINESSES that work when they are small are easier to scale• The first step to becoming an Entrepreneur is not quitting your job• You wont be pragmatic if your worried about rent / children / debt / x / y / z
  • 23. Bootstrap if you can• BUSINESSES that work when they are small are easier to scale• The first step to becoming an Entrepreneur is not quitting your job• You wont be pragmatic if your worried about rent / children / debt / x / y / z• Its also a great lesson in finances
  • 24. Don’t be afraid to share your idea• “But someone might steal it.”• The hardest thing you will do is going to be getting someone genuinely interested in your idea.• People that could actually execute your idea are too busy with their own ideas.• It’s a lot cheaper for someone to take a bet (put all the risk) on you, than try and do it themselves.
  • 25. Fail quickly and fail often
  • 26. Fail quickly and fail oftenone in seven businesses make it...
  • 27. Fail quickly and fail oftenone in seven businesses make it... ...so start seven businesses!
  • 28. WIB APIs in 2009
  • 29. Some problem’s• WIB was completely dependent on lots of different social networks • They break and change stuff • Our code becomes complicated (entropy)• WIB had a small team • And lots of stuff to do• WIB had a lot of members • half a billion db rows & 7000+ queries a second
  • 30. What is abstractiona web application is like an onion
  • 31. The Solution: “Network Abstraction Layer”• Wrapped Facebook, Myspace, Bebo, Hi5, Friendster and Orkut• Normalized the I/O• Absorbed changes where they happen• Handled breakages• Data sharing across the whole network - Facebook user can see a MySpace user
  • 32. and it’s really extensible• We can add functionality and data without breaking the other networks• We can add other networks very easily
  • 33. It’s also nice and scalable (for a team)• An API has a defined protocol, so developers on our team could work side by side on the different networks.• As long as I/O stays the same, they can work independently
  • 34. And it scales well technically• Dividing an application into layers makes it much easier to scale.• Mainly because the independent layers can be scaled (or re-written) independently, without breaking other components.
  • 35. WIB APIs in 2011
  • 36. WIB APIs in 2011
  • 37. WIB Today Where I’ve Been . com The website does not connect directly to the database Facebook Twitter WIB oAuth 2 REST APIFoursquareAnd others... Database Database Database
  • 38. Advantages of a single API• Saves Time (money) and it’s Extensible (future proof)• Teams can work on their own platforms • Website, iPhone, Android, Facebook App et.al.• Federate out content (or build developer network)
  • 39. How to build an API(an opinionated approach)
  • 40. how to build stuff in general
  • 41. how to build stuff in general• Developers cost
  • 42. how to build stuff in general• Developers cost• Servers cost
  • 43. Use Ruby on Rails
  • 44. Use Ruby on Rails• It allows you to build reliable, powerful, readable code
  • 45. Use Ruby on Rails• It allows you to build reliable, powerful, readable code• With RoR you can build a business in a week and host it for free
  • 46. Use Ruby on Rails• It allows you to build reliable, powerful, readable code• With RoR you can build a business in a week and host it for free Even monkeys use tools!
  • 47. Why Ruby on Rails is good for an API
  • 48. Why Ruby on Rails is good for an API Especially if you’re a startup
  • 49. Why Ruby on Rails is good for an API Especially if you’re a startup• RESTful out of the box
  • 50. Why Ruby on Rails is good for an API Especially if you’re a startup• RESTful out of the box• Normalized data
  • 51. Why Ruby on Rails is good for an API Especially if you’re a startup• RESTful out of the box• Normalized data • Encourages powerful abstraction
  • 52. Why Ruby on Rails is good for an API Especially if you’re a startup• RESTful out of the box• Normalized data • Encourages powerful abstraction• It’s easy and quick to develop
  • 53. Why Ruby on Rails is good for an API Especially if you’re a startup• RESTful out of the box• Normalized data • Encourages powerful abstraction• It’s easy and quick to develop• Its easy to write tests
  • 54. Why Ruby on Rails is good for an API Especially if you’re a startup• RESTful out of the box• Normalized data • Encourages powerful abstraction• It’s easy and quick to develop• Its easy to write tests• Scales horizontally (until you’ve already “made it”) - the bottleneck will be your DB
  • 55. RESTful web service• REST is how the web already works (makes it a pretty well known standard)• URL’s are self explanatory (easy to work with)• Closely matches the underlying data/objects • Makes it easy to build in a DRY way • Developers can get started very quickly
  • 56. HTTP methods• POST : Create something new• GET : Retrieve something that already exists• PUT : Update something that already exists• DELETE : Remove something that already exists
  • 57. Authorization and Authentication• Authentication • Who is this• Authorization • Can the Authenticated entity access this resource
  • 58. oAuth1 vs oAuth2• oAuth 2 is slightly less secure• But it makes everyone’s lives SO much easier• Build a “trusted” clients paradigm for internal use - login, register, reset password etc
  • 59. HTTP Request Authentication Web server Framework AuthenticationIt makes things really easy for developers Authorizationlots of libraries and examples exist API Controller
  • 60. Access Tokens• Different tokens for user+client and client• Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567
  • 61. Access Tokens• Different tokens for user+client and client• Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567 client_id = 12345
  • 62. Access Tokens• Different tokens for user+client and client• Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567 user_id = 1234576
  • 63. Access Tokens• Different tokens for user+client and client• Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567 hash(client_secret+user_id)
  • 64. Access Tokens• Different tokens for user+client and client• Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567
  • 65. SSLiPhone WiFi laptop running squid internet • Require it, otherwise developers will expose all sort of stuff (like keys) • Important if you want to be taken seriously by developer community
  • 66. SSLiPhone WiFi laptop running squid internet looking at all the traffic is easy • Require it, otherwise developers will expose all sort of stuff (like keys) • Important if you want to be taken seriously by developer community
  • 67. Standardized Errors• Assume success=true• Always send back errors in the same way, so client libraries can be smart { "error": { "type": "ObjectException", "message": "Object does not exist" } }
  • 68. Limit how much data gets send back• Mobile developers care a lot about this• allow customizations: fields=name,gender
  • 69. DRY Definitions
  • 70. HTTP Request LoggingErrors: Web server • GetExceptional $20 a month (whats your time worth?)Performance: Framework • New RelicAPI Requests • Something simple near the top of your stack Logging (remember, storage is cheap) API Controller
  • 71. GetExceptional
  • 72. GetExceptional - Backtraces
  • 73. New Relic
  • 74. New Relic
  • 75. Roll your own
  • 76. Roll your own
  • 77. JSON• It’s smaller than XML• Developers write bad xml parsers, that rely on the order of the XML nodes• Facebook use it, and they set the standard - you want your API to be sexy don’t you?
  • 78. Returning Data• Standarized - objects - arrays of objects - nested objects
  • 79. Standardize object output
  • 80. DRY Documentation never goes out of date• Build it off the - models - connections - methods
  • 81. Testing• Write tests on your API • Even if you hate tests • It’s easy • You can generate most of them just like the documentation
  • 82. Tie it all together• A good API is a series of simple layers• Keep it DRY • Use the data structure for more dynamic code• Standards are your friend• There are plenty of examples out there - Facebook, Foursquare, Twitter etc
  • 83. Thanks• Hope this was useful