by eterps on 3/20/2020, 2:26:44 PM
by sntran on 3/20/2020, 2:24:24 PM
While ES6 proxies are really nice, I came across this experiment (1) and their tests showed that ES6 proxies can be very bad at performance. I could reproduce the test case. Not sure whether this GraphQL client has some way to optimize.
1. https://thecodebarbarian.com/thoughts-on-es6-proxies-perform...
by adamkl on 3/20/2020, 2:32:16 PM
I think this looks very cool, but this quote concerns me:
If you’re into laziness and magic (who isn’t?)
I can see this being a great tool for whipping out quick prototypes, but I'd be scared to use it for anything bigger.
That being said, it does look very cool!
by tango12 on 3/20/2020, 2:38:12 PM
I'm excited about the fluent GraphQL ecosystem and to see where it goes! Using the nice syntax of GraphQL does get lost a little bit ofcourse, but having the benefits of being able to "compose" to some degree and not dealing with strings is nice.
From the SQL ecosystem, jOOQ is so amazing: http://www.jooq.org/
This Ruby one was one of the first ones I came across https://github.com/contentful-labs/gqli.rb
And then we've been putting together a list here as well: https://github.com/hasura/awesome-fluent-graphql
As a backend developer I can't help but feeling we have gone full circle. As in, how is this effectively different from regular server side HTML? I know this is rendered on the client, and I'm not doubting it's usefullness, but what advantages does this setup have?
I also guess their demo app isn't representative of what problems this setup intends to solve:
https://youtu.be/wM5KDPG9Ugk?t=2866
The example whould have been extremely simple to implement in JS/TS on the server side, it would also be much faster and have better concurrency, caching and scalability options.