So you end up maintaining two codebases that talk to the backend database? Implement a feature in one, you have to port it to the other too?
Sounds like a way to artificially pad hours on a project to me.
This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.
> This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.
It stems from APIs having bugs, and not being consumed by the writers. The flows were badly designed because they would never write a client against the API.
By making the web be a client to the API, the design, quality and maintenance of the API is very much to the fore. It also allows the implementations to evolve at their own speed, which helps a lot with maintenance, especially when one adds a mobile client, or changes some other UX flow... it becomes easier to work through things.
So yes, I agree... slower to get started and 2 codebases. But, so many advantages, higher quality, and lower maintenance costs that arise from the kind of short cuts that a single monolith codebase makes possible.
Tests have nothing to do with it. You can have 100% coverage on your API and it can still not be "quality". The best APIs I've seen have been "API First" design.
When talking about API "quality" I mean "does what it says on the tin, reliably".
Testing means you catch regressions.
You seem to be talking about API design, which is honestly a minor concern compared to whether it works reliably.
Have you ever tried to use the Facebook API? It breaks randomly such as endpoints suddenly return 404's, and there is no followup to bug reports.
That is what I'm talking about when I say "quality".
A "perfectly designed" API that randomly breaks because someone made a change and the lack of tests means its an end-user who discovers it is worse than terrible IMO.
- You can have many clients that talk to the same backend. This is really nice if you have an api that you can offer to partners.
- You can throw your client app away and build a new one pretty quickly without worries because it's totally decoupled from the backend. This is really nice when you have fickle stakeholders that have no idea what they want.
If all you're changing is the way it's presented to the user in a browser, you can still make changes without affecting the API - the logic is the same, you just modify the html templates.
Sounds like a way to artificially pad hours on a project to me.
This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.