The Never Wrong Approach to Web App Development
There seems to be no end to excellent approaches for building web-based applications. Everyone claims that their framework is best, and they are probably right under some combination of conditions. The task of studying when an approach is the best option is almost always left to the community. There is nothing wrong with that, but it can be extremely overwhelming for all of us to decide which approach to follow when starting a new project or refactoring an existing one.
While I can’t recommend what’s the best approach for each type of app and context, I can recommend an approach that it’s never wrong. That is not as trivial as it sounds because much of the anxiety of choosing an approach is caused by the fear of selecting the wrong one. Fortunately, there is one approach that is never wrong, and this article is simply a reminder of it.
When faced with too many options, you can always go for one time-tested solution: the decoupling of backend and frontend into independent applications that communicate via a well-documented API. That is a robust approach that somehow gets lost among the hype of frameworks that want to sell themselves as end-to-end solutions.
What language and framework should you use for the backend? That’s up to you to decide. What framework should you use for the frontend? Same, you decide. There is, however, a rule of thumb, which is to develop for team growth, so if things go well, you can add more team members to help you out. That, at a minimum, means that you must build the apps in terms of modules that are self-documented and testable on their own. That is the case for both backend and frontend apps.
Another piece of advice is to remember that an app that runs on the server is not immediately a backend app. A backend is one or more apps implementing business logic and exposing it via an API. In addition to a backend, you can have an app on the server in charge of rendering webpages for the front end. Such server-rendering app is part of the frontend solution even though it runs on the server. There is no problem with that setup. Just don’t thing that the server-side rendering logic is part of the backend and you will be okay.
In conclusion, all business logic and access to data is wrapped into a backend that can be accessed via an API. The problem of creating interfaces for users is left to frontend apps, which can rely on “frontend” server-side logic to help them achieve their goals. How you choose to implement the backend should not influence your frontend solution and viceversa. Treat them as two independent realms and you will not be wrong in doing so. You will have implemented a solution that can accommodate boundless growth.
