3 ms·
Ask HN: Do you recommend splitting your app into an API and an FE that uses it?
- alexmingoia 7y agoNo. 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 7y agoIf 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.
- marz0 7y agoNo, 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