Eating Your Own Dog Food

Transcript

1. 1.

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

   development
2. 2.

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

3. 3.

   NICK JACKSON Lead Web Developer @jacksonj04

4. 4.

   JOSS WINN Senior Lecturer @josswinn

5. 5.

   DO WHAT? • New RDM Platform • Focus on data

   during research, not after.
6. 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. 7.

   OUR APPROACH

8. 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. 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. 10.

    None
11. 11.

    None
12. 12.

    None
13. 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. 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. 15.

    WHY?

16. 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. 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. 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. 19.

    None
20. 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. 21.

    FIN.