When developing single page applications I always question myself which is the best way to design my project. Should I de-couple client and backend? Should my client application be in the same server as my backend code? Should I invest in multiple hosting plans for client and server ? So I'm asking, which is the best approach to organize and develop a single page app?
When I was first getting started, this is a question I had and it was hard to find a complete answer online. Generally speaking, although this will be an oversimplification, here is how companies move through this process.
Monolith: An application where the back-end and front-end code live within the same project.
What this means: The codebase is easy to maintain because it is all right there. There are less complexities initially and much less time to production because it is easier to get "out the door". You don't have complexities such as how different parts of the "system" talk to each other, etc. All start-ups start here.
The cons here are that eventually the code base becomes very unmaintainable as developers cram new features and ideas into it. Also, your API is not exposed, so it can only be used for this application (more on this below).
Front-End & API: An application where the front-end code and API live separately in different codebases. The API provides just the data, usually in a JSON format in which the front-end code consumes and displays this data.
What this means: Now that you've broken out the API and front-end code bases, you can use the API to provide data for ANY front-end application that needs it. For instance, think web vs. mobile. They can both use the same API. For a larger app, this becomes much more maintain able and now you can build teams around both back-end and front-end processes. You can now achieve better scaling and efficiencies too as the project grows.
The cons here are that you now have two separate codebases to maintain, up-keep, make updates too, make sure are in sync, etc.
FEBE & Micro-services: An application where all parts of the "system" live in very siloed codebases, architecture, etc. A FEBE is a "front-end, back-end" and a micro-service is a service (could be an API) that serves a VERY specific function within the business logic. The front-end in this world may need to consume several micro-services to accomplish its goal.
What this means: This is where successful, larger companies land eventually, if they make it. Again, oversimplification, but all of the major companies are running infrastructures in this realm. This architecture is much more for teams than for coding or development. Companies with hundreds of engineers can give them each a piece of the system to own and maintain, enabling them to release at their own pace to production, etc.
The cons here are that the system is now broken into hundreds of pieces and without the man-power becomes extremely difficult to maintain. Again, the reason companies do this is because it allows teams to operate extremely efficiently and independently.
All companies as a start-up generally migrate down this list, starting with the monolith, as they survive, turn revenue, become profitable, hire more people, etc.
My advice to you is this: Start with a monolith using a Node.js (Express) back-end and either an React.js or Angular front-end.
I say this because Node.js is the future and is very easy to learn and either React or Angular are good starting places in terms of frameworks.
When you move to Phase 2 (the front-end and API), stick with Node.js and probably React at that point OR if it were me, I would just consume my API's data in Handlebars and be done with it (not using a front-end framework at all).
Hope this helps. I replied because I know how frustrating this was for me when I was searching for an answer years ago.