This is more of a full-stack response, but I'm very much looking forward to the time when GraphQL-as-a-service matures and you can code a SPA without ever configuring a database or a server.
At the moment, you can already do this in limited cases (AWS AppSync, Prisma, Hasura), but all the services have some glaring weak spots around relations. Somewhat surprisingly, the best one I've found is neo4j-graphql, which is only held back by a few bugs and the need to manage your own neo4j instance. Still, the ability to have a graphql api generated for you if you just define the models is very nice.
If you're referring to migrations of the database, one of Hasura's touted features is its "rails like" migration system. In neo4j-graphql's case, neo4j is schema-optional so migration's are generally unnecessary. I think the same applies to AppSync backed by DynamoDB. Prisma seems to have the most attention (over 10,000 github stars), but looking at the various options, it seems the least mature by a fair margin (not sure if I'm missing something or if they just do a better job marketing).
If you're referring to migrating a graphql api itself, I would argue that this is, inherently, not an issue as the structure of the spec makes API changes straightforward (just create a new field and mark the old one as deprecated).
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.
This is more of a full-stack response, but I'm very much looking forward to the time when GraphQL-as-a-service matures and you can code a SPA without ever configuring a database or a server.
At the moment, you can already do this in limited cases (AWS AppSync, Prisma, Hasura), but all the services have some glaring weak spots around relations. Somewhat surprisingly, the best one I've found is neo4j-graphql, which is only held back by a few bugs and the need to manage your own neo4j instance. Still, the ability to have a graphql api generated for you if you just define the models is very nice.
Last time I checked this subject, the issue was with migrations. Did they already invent migrations for GraphQL?
If you're referring to migrations of the database, one of Hasura's touted features is its "rails like" migration system. In neo4j-graphql's case, neo4j is schema-optional so migration's are generally unnecessary. I think the same applies to AppSync backed by DynamoDB. Prisma seems to have the most attention (over 10,000 github stars), but looking at the various options, it seems the least mature by a fair margin (not sure if I'm missing something or if they just do a better job marketing).
If you're referring to migrating a graphql api itself, I would argue that this is, inherently, not an issue as the structure of the spec makes API changes straightforward (just create a new field and mark the old one as deprecated).