Hello,
I am wondering whether this starter is actually bad practice since it forces the frontend (html,css,js) and backend (node.js, API endpoints) to be in the same project.
It means that they are coupled. for example, if you want to upgrade one you must also deploy the other, you can't have separated git projects, and more
Thanks
edit:
I see some people voted this post "-1". I apologize if this post offended anyone. I'm using this starter myself and I think it's awesome so I don't mean to imply that it's no good. I just hope to see an open discussion here about the disadvantages of specifically combining the backend with the frontend under the same project
@LiranBri,
I'm not a developer of this project, but I'll give you my viewpoint.
The most important thing to understand is that this is an example project. One of the goals is to demonstrate the architecture in a way that is easy to install and understand. Combining the the frontend and backend in one project accomplishes that.
If you are building an application for production, then I think it depends on what your needs are. If the backend uses the same language and tools and has the same deployment cycle, I think it works fine included with the frontend. This is what I do for my application. When it starts to cause pain, I'll split it off.
I've been close to re-implementing the API server using a framework more expressive for REST APIs, but I keep deferring it.
Thank @roof12. i agree that it has benefits such as simplicity (and also you get things like server-side rendering). i'm just wondering if anyone thought about the disadvantages like those i presented and if so, if he tried to overcome them.
@LiranBri
Overcoming any disadvantages is pretty trivial. Just remove the API server pieces and change the API proxy address to the new value. Everything should just work.
In no way would you ever couple your backend into the same repo. This is a boilerplate the API is a mock API
Andrew, If you are saying that the backend part of this boilerplate is only for mocks during development I must say that it doesn't looks like that. What makes you say that?
For example, it wouldn't make sense to support server rendering..
It can be located on a different physical serve or the same server. It could be on Mars. As long as HTTP requests get through.
In this project it seperate a the web server from the API server. Server rendering has nothing to do with the API. Our web server (this project) makes requests for information, builds react based html and sends that to the clients browser
The actual business logic / API could be written in php, ruby, Python, Haskell, c... Fuck maybe even QBasic
@andrewmclagan how can I do SSR if I separate frontend and backend on different server?
I thought it's good to have a thin backend layer like nodejs to be a part of "frontend", the real backend could be java or something else to do the heavy lift
@xujihui1985 The part of frontend serve the static files with a little server, with SSR or not. And the backend contains an API that is used by the frontend.
I thought it's good to have a thin backend layer like nodejs to be a part of "frontend",
the real backend could be java or something else to do the heavy lift
@xujihui1985 You can absolutely do that.
Most helpful comment
@LiranBri,
I'm not a developer of this project, but I'll give you my viewpoint.
The most important thing to understand is that this is an example project. One of the goals is to demonstrate the architecture in a way that is easy to install and understand. Combining the the frontend and backend in one project accomplishes that.
If you are building an application for production, then I think it depends on what your needs are. If the backend uses the same language and tools and has the same deployment cycle, I think it works fine included with the frontend. This is what I do for my application. When it starts to cause pain, I'll split it off.
I've been close to re-implementing the API server using a framework more expressive for REST APIs, but I keep deferring it.