4 ms·
Ask HN: What is the best way to build an app when the API is not finalised?
What is the best way to start building a mobile app when the API is not finalised?
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/backend architecture and data for the app
2) That we start development on the app BEFORE the API is done
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.
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.
-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.
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 10y agoTechnically 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 10y agoThanks for the suggestion, I will look into swagger.
- sharemywin 10y agoWhy 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 10y agoMy recommendation is to reflect the difficulties in the price of services and terms and conditions of the proposal.