Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Eating Your Own Dog Food

Eating Your Own Dog Food

C7f3b4756d808ef0e2548bd0965ac225?s=128

Nick Jackson

July 12, 2012
Tweet

Transcript

  1. EATING YOUR OWN DOG FOOD Building a repository with API-driven

    development
  2. HTTP://LNCN.EU/FMR9 It’s in a repository and everything!

  3. NICK JACKSON Lead Web Developer @jacksonj04

  4. JOSS WINN Senior Lecturer @josswinn

  5. DO WHAT? • New RDM Platform • Focus on data

    during research, not after.
  6. YE OLDE REPOSITORY • Built on the premise of deposition

    of files (or pointers). • Generally limited interface methods, eg browser or nothing. • Focuses on format (if filetype), not form (ie structure).
  7. OUR APPROACH

  8. LOVE YOUR BACKEND (LOL) • Be prepared to deal with

    raw data. • Build your APIs first. Not your UI, your APIs. • Build good APIs which people will want to use.
  9. EAT YOUR OWN DOG FOOD • Use your own APIs

    to build the frontend. • Use your own documentation. • Find a user, and make them use things.
  10. None
  11. None
  12. None
  13. FORGET THE CONTAINERS • Storing a CSV file is great,

    if you want a whole CSV file. • Research happens on subsets of data. • Give researchers a shared, easily usable database. • Use the APIs to put stuff in and out automatically.
  14. MAKE IT EXTENSIBLE • Make sure data is accessible and

    writable easily. • Encourage re-usable modularity. • Rely on things that do things to get things done.
  15. WHY?

  16. WE BUILD BETTER STUFF • APIs are robust and reliable.

    • APIs are easily implementable by 3rd parties. • All functionality is available over APIs. • Error handling is consistent and clear. • Security is forcibly implemented across the board.
  17. IMPROVED VISIBILITY • Database querying lets researchers find what they

    want. • Improved quantitative information on how much stuff. • Data can be seamlessly integrated with other systems.
  18. SCALE TO INFINITY (And Beyond!) • Designed to scale horizontally.

    • No horrible statefulness to maintain. • Loose coupling means no un-picking necessary. Just go.
  19. None
  20. THE PROBLEMS • Takes time to design decent architecture first,

    so less ‘jump in’. • Doubling up development at API and interface ends. • APIs can add overhead, especially ‘heavy’ types like XML-RPC.
  21. FIN.