personally I found gql to have a steeper learning curve in that it adds an abstract layer to the stack.
I call it an abstract layer, the author calls it a BFF (backend for the frontend).
As far as dev time excluding onboarding time, lets not forget why gql was created - facebook wanted to separate the data responses to their mobile and web platform
first of all, not all organizations are facebook
secondly, especially for smaller to medium sized startups, not all responses need to be separated, and "shaving" off data for an extra endpoint is not difficult in REST.
and I remember graphql's early website where they made the claim saying that you'll need to have some really huge number of endpoints in order to emulate what graphql has to offer, and since then they have taken that down because of how ridiculous that sounded.
In reality and practice, the number of endpoints that you need to "shave", again, especially for small to medium startups, is slim to none.
As far as dev time excluding onboarding time, lets not forget why gql was created - facebook wanted to separate the data responses to their mobile and web platform
first of all, not all organizations are facebook
secondly, especially for smaller to medium sized startups, not all responses need to be separated, and "shaving" off data for an extra endpoint is not difficult in REST.
and I remember graphql's early website where they made the claim saying that you'll need to have some really huge number of endpoints in order to emulate what graphql has to offer, and since then they have taken that down because of how ridiculous that sounded.
In reality and practice, the number of endpoints that you need to "shave", again, especially for small to medium startups, is slim to none.