Stnafy Madcode Meetup: Making Friends with Backend Developers

Making friends with backend developers

Making friends with backend developers. Stanfy MadCode Meetup, 2014. 1

Making friends with backend developers

Well, at least don't fight


Own experience

• Outsource

• Own products

• Working with remote backend team

• Creating backends ourselves


SituationRemote team:

Mobile team <~> Backend team



Mobile team <~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ > Backend team



Mobile team <~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~ ocean ~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ > Backend team


What we want from backend?

• Use less requests

• Send only needed data in suitable format

• Low latency

• Handle heavy computations


What we do?

• Hey, let's change this request

• Hey, let's add this field

• Hey, let's get data in that format

• Hey, let's have public URL to pics

• Hey, let's ...


What we usually hear from backend devs?

• No, I need yet another table to join

• No, it's not simple to add that field

• No, calculate it on your side

• No, our library can't do that

• No, I'll deploy these changes in next sprint


Problems

• Different goals

• Misunderstanding

• Lack of trust

• Limited experience


Solutions?


No solution


Approaches

• Write documentation

• Write tests

• Write constructive emails

• Explain on examples


API documentation

• Need time to write

• Need time to update

• Need time to search

• Useless if outdated


API documentation

• 'Put everything in one place' (not in emails, not in head)

• User friendly

• Access anywhere at any time

• Determined

• Always updated


Creating API documentation

• Auto generated docs from code

• API tests

• Wiki

• Google Doc

• Emails/skype history/developer's head


Documentation in Google Doc• Easy to create (access anywhere)

• Easy to share

• Easy to update (ACL)


Documentation in Google Doc• Loooong & slow

• Not super-structured (as wiki)


Must have: easy navigationTable of changes

• When

• Who

• What was changed (with links)


Must have: easy navigationTable of changes

• When

• Who

• What was changed (with links)


Must have: easy navigationContents

• Quick to search

• Easy to deep into


Must have: fundamentalsEnvinronment description

• Production server URL

• Dev server URL(s)

• Main accounts

• Version


Must have: fundamentalsData formats

• JSON/xml

• Response should be valid!

• Encoding

• Timestamp format

• Boolean format

• Float format


Must have: fundamentalsRequest formats

• GET

• POST (body format)


Must have: headersHTTP headers for Request

• Accept content-type

• Accept encoding

• Cookie

• Device

• App version

• Image scaling

• Session handling


Must have: HTTP codesHTTP codes

• What are valid?

• What app should do?


Must have: response structureResponse structure

• Inner error code

• Error message to user

• Body


Must have: communication with userInner error codes + message

• Ok

• Session is expired

• DB error

• Synchonization needed

• Just show message to user


Must have in API documentation

• Easy navigation and search:

• Table of changes

• Contents

• Fundamentals

• Envinronment description

• Data formats

• Request/response structure


API tests

• Shared with backend dev

• Public results

• 'Everything is broken' - blame


API tests. Heliumhttps://github.com/stanfy/helium

• DSL description

• Poke tests

• Scenarios tests

• Object generation


MiscommunicationBe definite

• Discuss smth in emails/chat -> add to API doc

• Add manager to email thread


MiscommunicationProvide full details

• Add headers

• Add timestamps

• Add session IDs

• Mark out details


Explain


Explain


MiscommunicationExplain

• Backend developer is not iPhone/Android user

• Have no idea how data will shown

• Design driven vs DB-data driven


MiscommunicationBe polite

• Thanks for quick changes

• Thanks for deploy

• Thanks for description


Why we need this?• We deal with real users• We gather feedbacks


Last slide

Heliumhttps://github.com/stanfy/helium

Google dochttp://bit.ly/1s69iVP


Questions

@[email protected]

