Social dev camp_2011

1,125 views

Published on

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

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,125
On SlideShare
0
From Embeds
0
Number of Embeds
72
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \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

    1. 1. Craig Ulliott likes building things
    2. 2. About me
    3. 3. About me• Needs to know how everything works
    4. 4. About me• Needs to know how everything works• Likes things that scale
    5. 5. About me• Needs to know how everything works• Likes things that scale• Think’s almost everything is inefficient
    6. 6. About me• Needs to know how everything works• Likes things that scale• Think’s almost everything is inefficient• Hates people
    7. 7. About me• Needs to know how everything works• Likes things that scale• Think’s almost everything is inefficient• Hates people • Just kidding
    8. 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. 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. 10. Mistakes I’ve Made
    11. 11. Mistakes I’ve MadeLessons I’ve Learned.
    12. 12. Minimum Viable Product
    13. 13. Minimum Viable Product• Short sprints (release code regularly)
    14. 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. 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. 16. Surround yourself with business people
    17. 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. 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. 19. Bootstrap if you can
    20. 20. Bootstrap if you can• BUSINESSES that work when they are small are easier to scale
    21. 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. 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. 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. 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. 25. Fail quickly and fail often
    26. 26. Fail quickly and fail oftenone in seven businesses make it...
    27. 27. Fail quickly and fail oftenone in seven businesses make it... ...so start seven businesses!
    28. 28. WIB APIs in 2009
    29. 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. 30. What is abstractiona web application is like an onion
    31. 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. 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. 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. 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. 35. WIB APIs in 2011
    36. 36. WIB APIs in 2011
    37. 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. 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. 39. How to build an API(an opinionated approach)
    40. 40. how to build stuff in general
    41. 41. how to build stuff in general• Developers cost
    42. 42. how to build stuff in general• Developers cost• Servers cost
    43. 43. Use Ruby on Rails
    44. 44. Use Ruby on Rails• It allows you to build reliable, powerful, readable code
    45. 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. 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. 47. Why Ruby on Rails is good for an API
    48. 48. Why Ruby on Rails is good for an API Especially if you’re a startup
    49. 49. Why Ruby on Rails is good for an API Especially if you’re a startup• RESTful out of the box
    50. 50. Why Ruby on Rails is good for an API Especially if you’re a startup• RESTful out of the box• Normalized data
    51. 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. 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. 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. 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. 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. 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. 57. Authorization and Authentication• Authentication • Who is this• Authorization • Can the Authenticated entity access this resource
    58. 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. 59. HTTP Request Authentication Web server Framework AuthenticationIt makes things really easy for developers Authorizationlots of libraries and examples exist API Controller
    60. 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. 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. 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. 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. 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. 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. 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. 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. 68. Limit how much data gets send back• Mobile developers care a lot about this• allow customizations: fields=name,gender
    69. 69. DRY Definitions
    70. 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. 71. GetExceptional
    72. 72. GetExceptional - Backtraces
    73. 73. New Relic
    74. 74. New Relic
    75. 75. Roll your own
    76. 76. Roll your own
    77. 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. 78. Returning Data• Standarized - objects - arrays of objects - nested objects
    79. 79. Standardize object output
    80. 80. DRY Documentation never goes out of date• Build it off the - models - connections - methods
    81. 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. 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. 83. Thanks• Hope this was useful

    ×