Ask HN: Do you recommend splitting your app into an API and an FE that uses it? - it
======
marz0
No, unless you plan to have one team focused on the front-end and another on
the API. In that case, it might make sense to make your code more modular (and
explains how Conway's Law [0] comes about)

Otherwise, it's easier to support one monolith. Imagine having to change some
back-end code that your front-end code relies on. This could be accomplished
in one deployment with a monolith, but would require two deployments if you
separate the FE and API. Not only that, but it would require you to keep them
in sync or version your API.

[0]
[https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)

------
alexmingoia
No. Unless your product is the API nobody will use it, and it’s a waste of
time and resources to create an extra layer you don’t need.

Development can be faster and require less code if you go with a traditional
web application architecture (request -> db query -> render HTML response).
Rails and Laravel have everything you need out-of-the-box.

Its also faster to iterate than a separate SPA + API, which is important when
building an MVP and when making changes based on stakeholder demands.

------
tboyd47
If you split your app into an API and a front-end, you double your personnel
costs for no added benefit to those customers that do not have a need for an
API.

