I'm a software developer who writes about Laravel, JavaScript, Rails, Linux, Docker, WordPress and the tech industry. Follow me on Twitter @tylerlwsmith
The biggest feature that drew me to server-side JavaScript was code-sharing. I liked the idea of being able to share TypeScript interfaces on both the server and the client. Now that I'm using Laravel as my back-end again, keeping REST API changes in sync with the front-end interfaces is a challenge.
Server-side React rendering and fear of missing out were the other reasons I used Node. I'm glad I gained a new skillset in the process, and I'm sure it'll come in handy someday.
If rest api changes in sync that is your problem, I think you can take a look of graphql. GraphQL is a schema that define a standard of how the client communicate with your server. All api will consolidate with one url and data format is like a graph
Something like that
{user:1{idname}}
If your server side schema change, your client don't need to worry about more calling more and more api.
I'm a software developer who writes about Laravel, JavaScript, Rails, Linux, Docker, WordPress and the tech industry. Follow me on Twitter @tylerlwsmith
I've used client-side GraphQL from a React app before. It was fine.
On the server, it sounds like it would add a lot of complexity outside of simple CRUD apps. REST API endpoints have a predictable code execution path and can be separated into distinct concerns. I don't know how that looks on the server for GraphQL, especially when performing validations, triggering side-effects, etc.
I know it's possible, and maybe it's easier than I'm thinking. It just feels like I'd be moving a lot of complexity from the front-end to the back-end, and since I'm already working on both, I don't see a big advantage.
If I were on a team of 20+ engineers with people only working on the front-end and only working on the back-end, GraphQL would be extremely appealing though.
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.
Thanks for reading the article, Vero!
The biggest feature that drew me to server-side JavaScript was code-sharing. I liked the idea of being able to share TypeScript interfaces on both the server and the client. Now that I'm using Laravel as my back-end again, keeping REST API changes in sync with the front-end interfaces is a challenge.
Server-side React rendering and fear of missing out were the other reasons I used Node. I'm glad I gained a new skillset in the process, and I'm sure it'll come in handy someday.
If rest api changes in sync that is your problem, I think you can take a look of graphql. GraphQL is a schema that define a standard of how the client communicate with your server. All api will consolidate with one url and data format is like a graph
Something like that
If your server side schema change, your client don't need to worry about more calling more and more api.
Thanks for the suggestion, CircleCurve!
I've used client-side GraphQL from a React app before. It was fine.
On the server, it sounds like it would add a lot of complexity outside of simple CRUD apps. REST API endpoints have a predictable code execution path and can be separated into distinct concerns. I don't know how that looks on the server for GraphQL, especially when performing validations, triggering side-effects, etc.
I know it's possible, and maybe it's easier than I'm thinking. It just feels like I'd be moving a lot of complexity from the front-end to the back-end, and since I'm already working on both, I don't see a big advantage.
If I were on a team of 20+ engineers with people only working on the front-end and only working on the back-end, GraphQL would be extremely appealing though.