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.
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.