Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
In my opinion it comes down to requirements and being able to justify the creation of individual endpoints versus exposing a gigantic amalgamation of data versus GraphQL. The complexity of your objects also will weigh heavily on this decision.
I personally find REST a better system for modifying data whereas GraphQL is more convenient for querying data, especially when many variations exist in possible queries.
Hoping to use it in a system at work soon, but deadlines don't give me much time to add new technologies or anything that could add risk 😪
A secret strength of gql is how its resolvers can slide between user and backend - even if backend is traditional rest endpoints. So a field can resolve by a db call, or by a call to your (or someone else's) rest api.
Given that: it's not really a question of cost in maintaining two ways. GQL is basically a noop passthrough. The question is where to spend your time. Migrate legacy rest to gql, or keep maintaining rest as is.
GQL, in this case, is a non-issue.
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.
Brilliant overview of when you should/shouldn’t use Graph/REST!
I often find the biggest resistance to using a hybrid approach is the cost of having two ways access/use data. How do you address this?
In my opinion it comes down to requirements and being able to justify the creation of individual endpoints versus exposing a gigantic amalgamation of data versus GraphQL. The complexity of your objects also will weigh heavily on this decision.
I personally find REST a better system for modifying data whereas GraphQL is more convenient for querying data, especially when many variations exist in possible queries.
Hoping to use it in a system at work soon, but deadlines don't give me much time to add new technologies or anything that could add risk 😪
A secret strength of gql is how its resolvers can slide between user and backend - even if backend is traditional rest endpoints. So a field can resolve by a db call, or by a call to your (or someone else's) rest api.
Given that: it's not really a question of cost in maintaining two ways. GQL is basically a noop passthrough. The question is where to spend your time. Migrate legacy rest to gql, or keep maintaining rest as is.
GQL, in this case, is a non-issue.