Ask HN: Do you recommend splitting your app into an API and an FE that uses it?

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

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.

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.