It certainly depends what you're doing with it. When I'm building something small I never want to go through the effort of setting up something like Vue or React, as in small projects I think the downsides often outweigh the ups.
That being said, I have 2 big reasons I like them. One is they keep the frontend and the backend separate which is nice sometimes. Especially in big projects, I prefer to keep the clients separate from the server-side. It also means if I have someone helping me who is not familiar with the backend languages/services, they can still easily work on the frontend, requiring nothing more than API documentation.
The other reason is in a lot of my projects I like providing an API that is accessible from mobile apps, discord bots, etc. If I build something serverside rendered it often means I then need to build API endpoints separately to provide the same services. If my whole backend is an API from the start, it makes it easier to stick any number of clients on top of it, whether they be mobile, web or other services.
Really depends on what you're doing. I wouldn't use them for small projects or anything where an API is generally unnecessary. But certainly useful for very large projects or anything where you're going to have a lot of clients attached to the one backend service.
Well i think you have good points. I agree on the having APIs part but i usually do server side rendering and it just consumes the APIs.
And working with other people isn't hard because at least for me. I use ejs. So the templates are pure js as well. And the frontend people can do whatever they like as long as the server can return it.
Would you have a separate serverside project that consumes the API or just abstract it in such a way that the SSR and the API endpoints call the same services in your code?
Usually, when I think of SSR I think of templating (An example is my personal site, written with ASP.net Core and Razor templating. No API's are present there and the front-end is part of the back-end code in that it uses ASP's templating engine).
So what we currently do is yeah if I want to get all the documents I have a model for the documents API uses at GET /documents/{id} uses and the view uses.
The views are ejs templates. The frontend is part of the backend code but the way its set up it's in its own folder and has its own build process with parceljs.
So it's a big ol monorepo basically.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It certainly depends what you're doing with it. When I'm building something small I never want to go through the effort of setting up something like Vue or React, as in small projects I think the downsides often outweigh the ups.
That being said, I have 2 big reasons I like them. One is they keep the frontend and the backend separate which is nice sometimes. Especially in big projects, I prefer to keep the clients separate from the server-side. It also means if I have someone helping me who is not familiar with the backend languages/services, they can still easily work on the frontend, requiring nothing more than API documentation.
The other reason is in a lot of my projects I like providing an API that is accessible from mobile apps, discord bots, etc. If I build something serverside rendered it often means I then need to build API endpoints separately to provide the same services. If my whole backend is an API from the start, it makes it easier to stick any number of clients on top of it, whether they be mobile, web or other services.
Really depends on what you're doing. I wouldn't use them for small projects or anything where an API is generally unnecessary. But certainly useful for very large projects or anything where you're going to have a lot of clients attached to the one backend service.
Well i think you have good points. I agree on the having APIs part but i usually do server side rendering and it just consumes the APIs.
And working with other people isn't hard because at least for me. I use ejs. So the templates are pure js as well. And the frontend people can do whatever they like as long as the server can return it.
Would you have a separate serverside project that consumes the API or just abstract it in such a way that the SSR and the API endpoints call the same services in your code?
Usually, when I think of SSR I think of templating (An example is my personal site, written with ASP.net Core and Razor templating. No API's are present there and the front-end is part of the back-end code in that it uses ASP's templating engine).
Just curious how you would usually go about it!
So what we currently do is yeah if I want to get all the documents I have a model for the documents API uses at
GET /documents/{id}uses and the view uses.The views are ejs templates. The frontend is part of the backend code but the way its set up it's in its own folder and has its own build process with parceljs.
So it's a big ol monorepo basically.