are you supposed to say urql like "Urkel"?
I clicked the article link just because I was expecting to see this guy: https://en.wikipedia.org/wiki/Steve_Urkel#/media/File:Steve_...
Urql: a GraphQL client library
31–40 of 79 posts
Re: Urql: a GraphQL client library
#32Earlier quoted context omitted.
It does incrementally make a difference. You want all your libraries to stay under a certain budget if you don't want to hit your users with a 500 KB bundle size. It is not only about how long it takes to download, it is also about parsing that amount of code in low end phones.
> if you don't want to hit your users with a 500 KB bundle size. Still I do think if you are building a web application (and not a static site or a blog) it is expected it can take a second or two to load it for the first time. 500 KB bundle is nothing wrong in that case.
The initial question of why did you make something iteratively better (in terms of size). It's only 20KB. Can be used to stop progress in any field by replacing the keywords.
I would hate to use something built by people with the attitude that compromising on performance when you don't need to is OK because it falls in line with current expected ranges.
Re: Urql: a GraphQL client library
#33Excited to see some competition for Apollo. Apollo may do lots of things but exactly what and why and how remains a mystery to me. Apollo just feels needlessly large, opaque, and inadequately documented to me. Reading about urql, the combination of minimalist architecture with first class support for React hooks sounds like just what I'd been hoping would emerge.
Hi from Apollo! We appreciate your honest feedback. Part of my team (Developer Experience) is responsible for our documentation. What features are inadequately documented? We'd like to fix that for you if we can.
I am enjoying using apollo, it's hard to explain but at the beginning the language of the docs seems foreign (think apollo link) and the site feels huge, it's not a particular problem just more a matter of the feeling /impression it gives. Uninviting and intimidating is the words that come up.
Vue's documentation is a good example of the opposite, it feels friendly an accesible, it has a nice flow to it. Apollo has the opposite feeling even though everything seems to be documented and everything is explained.
Probable more an organization and presentation issue than a content issue.
Just my 2c.
Re: Urql: a GraphQL client library
#34Fun, I don't know Typescript (and barely remember JavaScript!) but maybe I'll try to add automatic persisted queries compatible with the apollo-link syntax https://github.com/apollographql/apollo-link-persisted-queri...
Re: Urql: a GraphQL client library
#35There is also the new GraphQL integration into mobx-state-tree that was just announced last week by the author of mobx, you can check it here https://github.com/mobxjs/mst-gql
Re: Urql: a GraphQL client library
#36Does it typecheck queries for you based on the schema, and generate a response type for TypeScript?
Re: Urql: a GraphQL client library
#37Excited to see some competition for Apollo. Apollo may do lots of things but exactly what and why and how remains a mystery to me. Apollo just feels needlessly large, opaque, and inadequately documented to me. Reading about urql, the combination of minimalist architecture with first class support for React hooks sounds like just what I'd been hoping would emerge.
Hi from Apollo! We appreciate your honest feedback. Part of my team (Developer Experience) is responsible for our documentation. What features are inadequately documented? We'd like to fix that for you if we can.
At work, we are a fairly established company with an existing codebase. We don’t use Apollo React, simply the client and Apollo explorerer. I would like better documentation for the vanilla client.
Personally, I have no trouble with it’s usage since I have been dealing with it for 2 years, and I keep up with the GitHub changesets but new devs have a harder time on boarding since all the links on the site seem to lead to a framework specific documentation.
Re: Urql: a GraphQL client library
#38There is also the new GraphQL integration into mobx-state-tree that was just announced last week by the author of mobx, you can check it here https://github.com/mobxjs/mst-gql
> this project closes the gap between GraphQL and mobx-state-tree as state management solutions. GraphQL is very transport oriented, while MST is great for client side state management. GraphQL clients like apollo do support some form of client-side state, but that is still quite cumbersome compared to the full model driven power unlocked by MST, where local actions, reactive views, and MobX optimized rendering model be used.
MST and GraphQL together does sound like a pretty serious win
Re: Urql: a GraphQL client library
#39Earlier quoted context omitted.
Hi from Apollo! My team (Developer Experience) is responsible for making sure you can find what you need in the docs. What improvements would you like to see?
A more consistent documentation experience. A lot of code examples import various modules, but those modules have no documentation. For example: Docs > Client > Apollo Link mentions `graphql-tools` and schema stitching, with a link to read more. Clicking that link takes you to a page that says it's deprecated, and then links to a blog post about why. Another example: Is `apollo-link-state` deprecated? The docs for `a…
Similar to the deprecation issue, a number of Links still say "under active development" or similar pre-release "warnings" in their GitHub READMEs but that isn't reflected in the documentation site, making it tough to figure out what is considered stable and what isn't without jumping back and forth between GitHub and the documentation site, and there's still questions of whether or not perhaps the README warnings are stale. It would also maybe be great to have something of a roadmap of when those links might be considered "production ready" especially if the documentation site is already recommending them as project solutions.
The example to mind is last time I was trying to do something (a few months back) `apollo-link-rest` was highly recommended in the documentation as a potential solution, but yet visiting the GitHub for it seemed to be saying the exact opposite that it wasn't ready yet and was filled with massive API shifts and bugs/issues to iron out before "production ready".
Re: Urql: a GraphQL client library
#40Earlier quoted context omitted.
Hi from Apollo! We appreciate your honest feedback. Part of my team (Developer Experience) is responsible for our documentation. What features are inadequately documented? We'd like to fix that for you if we can.
The issue is not that there is a simple feature that's inadequately documented. It's that I have no high level understanding of what all the pieces are and how they fit together. Tell me exactly what I'm getting from Apollo that I don't get from fetch. Tell me what caching does, when, how, and how to invalidate it. Tell me about links and middleware. This is a very complex batteries included technology. I don't even…
You can’t invalidate the cache in Apollo. You have to clear all items, or update a specific part to a new value.
It’s not a simple key value cache, but a graph of values, which makes invalidation more complex but still in my opinion that is a huge oversight.
Hopefully an Apollo dev can give us some insight here: why is the cache a requirement? Why is it threaded into every bit of code? I’ve seen so many bugs from the cache, and I know there is a technical reason it has to be part of the core codebase, but I have forgotten why.