
Ask HN: What is the best way to build an app when the API is not finalised? - klunger
What is the best way to start building a mobile app when the API is not finalised?<p>My company makes native Android and iOS apps for our customers. A regrettably large percentage of the time, the customer will insist on 2 things:
1) that they will take care of the API&#x2F;backend architecture and data for the app
2) That we start development on the app BEFORE the API is done<p>I feel that #1 is quite reasonable, as the customer often has ingested their own user data somehow and wants to keep control of it. The problem comes with #2, which has caused no end of headaches for us.<p>Things we have tried:
-Making our own quick’n dirty internal test servers that returns mock data that we guess is reasonably close in format to what will actually be provided by the actual API. Often, we guess wrong. A request that returns multiple objects is often broken up by the customer API into several requests, or vice versa. The end result is a LOT of refactoring, headaches and wasted time once the real API is available.<p>-Creating static views that just show mock data from the app internally, and not even messing with requests to an internal test server because this is bound to change (see above). The problem with this, of course, is that there is a lot of work to be done once the API is actually set up. Crunch and stress ensues, as the customer will often deliver the API close to the deadline.<p>So, my question is, what is the best practice for dealing with this kind of situation? Obviously, in an ideal world, we would simply not start work on a project until the customer has delivered a working test server, or at the least some API documentation.  I have been told by the sales guys that this is not a reasonable expectation, so a better technical solution is needed.
======
onion2k
Technically speaking, I'm a big fan of
[http://swagger.io/](http://swagger.io/), especially since it's turned in to
the Open API Initiative. You (or your client) define an API in YAML, and then
you can use the Swagger Codegen tool to automate building a client SDK and a
mock server based on it. API changes are handled by simply rerunning the
generator. I've found that the NodeJS/Angular code that's generated is good
enough to use in production if you're sensible.

As far as managing the process, the only way to do it is to make sure the
customer understands that the lack of a working API test server (with good
stubs to start with, and actual data further on in the project) will delay the
project. Make sure that you tell them the app development will lag behind the
API by at least a month.

~~~
klunger
Thanks for the suggestion, I will look into swagger.

------
sharemywin
Why not create a wrapper service that calls their api. The wrapper could be
very screen dependent similar to a ViewModel type data structure. Then do all
your Model to ViewModel mapping from the wrapper api on the server. In fact,
if they own the server they could be the ones responsible for changing the
mapping code.

------
brudgers
My recommendation is to reflect the difficulties in the price of services and
terms and conditions of the proposal.

