My mind is in conflict with this idea, should i keep frontend and backend in a single project with single dependencies and blunder, this structure will helps to implement SSR easily, but it makes code management and bundling complicate. I other hand frontend and backend as separate project with independent bundle and dependencies, code and dependency management is much easier.
Nowadays do we really need SSR?
I found something like this to be most flexible.
/root
../src
../../client (entrypoint for client, rehydrates react tree/etc)
../../server (entrypoint for server, spins up db, express, etc)
../../blog
../../../common (react components, graphql typedefs)
../../../../components
../../../../routes
../../../server (graphql resolvers, other stuff that only runs on server)
../../../../resolvers
../../user
../../../common
../../../../components
../../../../routes
../../../server (authentication logic, express middleware, gql resolvers for store, etc )
../../../client (browser cookie/local storage logic)
../../layout (sitewide react components, IE: PageHeader, NavBar, etc)
../../ui (reusable sitewide micro-components ie: Button, Modal)
note: ./layout and ./ui don't have "server"/"common"/etc divisions because they purely in a single domain (common) so I just put their contents at the root instead of ./layout containing a single folder.
Obviously it depends on the complexity of your site. But I find this allows me to seperate different aspects of the site (ie: a blog, and a user portal) and break them down into client/common/server. you probably end up with multiple folders named "client" or "common" in your tree but I think that's of minimal concern.
Keep them separate. Supposed you have a folder called the server create a folder inside the server folder name the folder (client). The client folder should be your frontend while your server files should be in the root of the server folder
Keep them separated, create your backend as an API and make your frontend use it to fetch data and stuff.
You need to provide more information and details about your project and how you will use it in order for me to give you any tips for going with SSR or not. But, I would say, with todays tools it is really simple to go with SSR and there are basically no downsides going with it imo.
Xingheng Wang
Co-founder Moesif.com (API analytics). Previous Microsoft & Zynga. CS from MIT.
You can also separate out the "rendering of the UI" whether client side or server side, vs. "business logics/data base."
Generally, for security reasons, your core business logic and database should always be as part of the backend. And you can design an API interface for it.
Your UI, whether client side render or server side rendered, is just an optimization. And it should interface with your business logic and database via an API only.
Also important: never completely trust the front end, i.e. make sure you have the right Authentication & Authorization in place for the APIs set up.
moesif.com/blog/technical/restful-apis/Authorizat…