You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are many advantages and disadvantages for using GraphQL. Many companies use it, including GitHub. I certainly don't think GraphQL is appropriate for every application as a permanent implementation but for getting something quick to client side developers before you know all the "endpoints" or even the data model you may need it could be a big win.
The situation I am talking about is when you are getting started and may not have a clear understanding of the exact structures of data the client will need. Having a super flexible API such as GraphQL can make it fast at the start when you haven't yet locked down all the application requirements and need to quickly prototype ideas. Instead of wasting time creating perfectly coded REST API calls that may just get thrown away, it would be better to put up a GraphQL API that is less concerned about performance and more concerned about providing the flexibility needed at this early stage. Then as the application development matures, you can identify the areas that are known very well in terms of data structure and access patterns, and at that time decide to either write specific REST API endpoints or just tune the performance of the GraphAPI implementation.
This task is to write templates that generate a fairly simple GraphQL implementation that can be used by client side developers early on.
The text was updated successfully, but these errors were encountered:
There are many advantages and disadvantages for using GraphQL. Many companies use it, including GitHub. I certainly don't think GraphQL is appropriate for every application as a permanent implementation but for getting something quick to client side developers before you know all the "endpoints" or even the data model you may need it could be a big win.
The situation I am talking about is when you are getting started and may not have a clear understanding of the exact structures of data the client will need. Having a super flexible API such as GraphQL can make it fast at the start when you haven't yet locked down all the application requirements and need to quickly prototype ideas. Instead of wasting time creating perfectly coded REST API calls that may just get thrown away, it would be better to put up a GraphQL API that is less concerned about performance and more concerned about providing the flexibility needed at this early stage. Then as the application development matures, you can identify the areas that are known very well in terms of data structure and access patterns, and at that time decide to either write specific REST API endpoints or just tune the performance of the GraphAPI implementation.
This task is to write templates that generate a fairly simple GraphQL implementation that can be used by client side developers early on.
The text was updated successfully, but these errors were encountered: