Skip to content
Anallely Olivares edited this page Aug 2, 2014 · 2 revisions

Convener

Alan Languirand (@13protons)

Attendees

Notes

How do you write client apps for apis that are still in development?

The issue of coordinated client/api dev is similar to design/ui dev. The photoshop comp drives UI requirement and vice verse. A client app drives api requirements and vice versa.

It's a hard problem, but might be necessary. There are several approaches:

  • Keep your teams in sync. lots of overhead, like weekly sprint checkins. This works best for small teams.
  • Data contracts - agree on how an api should look before it's built so UI team can mock up data and start building.
  • One source of truth. Let's build a [swagger, apiary, raml] doc then build an api to look like that, and a client to consume resources like that.

Problems that get introduced:

  • Two parallel creative processes mean that things can and will change.
  • Design comps can reveal features that storytelling/text didn't capture.
  • Flavor disease can cause dev team to use newer tech and introduce unexpected capabilities. Just SHIP!

An effective communication is always the key

Additional Considerations (added later)

Despite all this, your first client is an excellent lens through which to view your api. Even if a client is not a product you plan on producing, some client will be necessary to give your api team a reality check. The goal is always something else that isn't an API or a Client (like looking up flight info) - your team has just chosen to provide a service and is a using an API as a tool to deliver it. Keep it real and remember the goal, especially to resolve discrepencies between comps/apis, excessive feature requests, etc. If it's good for the user and accomplishes the ultimate goal, build it into product regardless of level.

Clone this wiki locally