DEV Community

Discussion on: Reflecting on a year with Node.js and why I should have stuck with Laravel

Collapse
const_require profile image
Sean • Edited on

Great read. 👍 Just out of interest why did you decide to go for Node and its ecosystem in the first place? Particularly if you already had experience with Laravel. Was there something that you found lacking in Laravel that you could only leverage through Node? Or was it purely cosmetic?

Collapse
tylerlwsmith profile image
Tyler Smith Author

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.

Collapse
circlecurve profile image
CircleCurve

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 {
       id 
       name
   }
}
Enter fullscreen mode Exit fullscreen mode

If your server side schema change, your client don't need to worry about more calling more and more api.

Thread Thread
tylerlwsmith profile image
Tyler Smith Author

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.