Post AVtGtCgKdkArtChLSS by dolanor@hachyderm.io
 (DIR) More posts by dolanor@hachyderm.io
 (DIR) Post #AVsTIZw8JwaPXozlvU by louis@emacs.ch
       2023-05-21T11:00:31Z
       
       0 likes, 0 repeats
       
       Is the huge additional effort to implement an API with GraphQL support as opposed to a simple JSON/REST model for a moderately complex API (with an SQL backend) in Go make sense?Any hints, experiences, pro and cons?#webdev #graphql #golang
       
 (DIR) Post #AVsUMofpZQqyMZxFD6 by gothnbass@linuxrocks.online
       2023-05-21T11:12:01Z
       
       0 likes, 0 repeats
       
       @louis Off the top of my head, I'd say it comes down to expected usage patterns.How likely/frequent is it that clients make REST requests from *this system* that effectively fetch a coherent tree of data?
       
 (DIR) Post #AVsV6dLrztxWZNSv1k by galdor@emacs.ch
       2023-05-21T11:20:48Z
       
       0 likes, 0 repeats
       
       @louis Last time I was in this situation, it took a lot of work to make sure there would be no GraphQL no matter what. The concept is interesting, but the ecosystem is insanely complex.We went instead with a backend-for-frontend system, where you put a service between the core and the web applications to aggregate, transform and serve data in a way that works for frontend devs, without affecting the internal architecture.
       
 (DIR) Post #AVtGtCgKdkArtChLSS by dolanor@hachyderm.io
       2023-05-21T20:16:12Z
       
       0 likes, 0 repeats
       
       @louis my point of view would be: how frequently would the client change the way it accesses the API. If "a lot" because thr use cases are not completely clear, then it could make sense.Otherwise, I'd stay with REST.But then, there is stuff like: https://github.com/dosco/graphjin