8 ms·

Urql: a GraphQL client library

217 points by smusumeche 7y ago

mxstbr 7y ago
Have been playing around with urql on a project for a couple of months now, mainly due to the small bundle size. Urql is 7.5kB min+gzip, where Apollo and Relay add ~30kB min+gzip! Great to see Formidable investing further in it, I am very excited to see first class extensibility.
- methyl 7y ago
  > Urql is 7.5kB min+gzip, where Apollo and Relay add ~30kB min+gzip! How is that 22.5kB making any difference? Unless you are working on a project that will be used on very slow connections I see no point in choosing a library basing on such small difference in size. And if you really are targeting those slow connections then maybe going SPA is not the best choice?
  - helloguillecl 7y ago
    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.
    - methyl 7y ago
      > 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.
      - pavel_lishin 7y ago
        > it is expected It's also expected that my train is going to be late, but we can lament this condition, instead of resigning ourselves to it.
      - RossDM 7y ago
        18% of the Alexa Top 10K sites grew by 1MB+ from July 2017 - July 18. (source: https://twitter.com/katiehempenius/status/1133209127000379393 https://twitter.com/katiehempenius/status/113320912700037939...) Ignoring the impact of libraries you send to the frontend will lead to death by a thousand cuts.
        methyl 7y ago
        How many of those Top 10k Alexa sites are full-blown web applications that need GraphQL in the first place?
      - ctvo 7y ago
        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.
      - RussianCow 7y ago
        It might be expected, but I have to admit, there is a certain joy to using a website that loads instantaneously (like Hacker News). Whether or not that joy translates into additional revenue to justify the costs is another question entirely...
    - underwater 7y ago
      Most apps need to do two core things: render UI and manage data. Setting a sub 30kb budget for something so core is madness.
  - brianmathews 7y ago
    From recent bundle audits of e-commerce sites built with React, less than 20% of the code was actual custom site code and the remaining 80% was from dependencies. If the bundle size is 550kb min/gzipped, that's 110kb of app code, and 440kb of dependencies. Some of the largest dependencies in a recent audit were: moment (60kb), swiper (32kb), lodash (24kb), react-select (26kb), raven.js (12kb), polyfills (25kb), mobile-detect (15kb), and then a bunch of smaller dependencies that made up the remaining 300kb. Using this performance budget calculator you can quickly see how each 25kb of JS adds ~.3s to your TTI on a mobile phone: https://perf-budget-calculator.firebaseapp.com/ https://perf-budget-calculator.firebaseapp.com/ If developers shop around for smaller alternatives of each dependency, then they can cut their load times pretty drastically.
    - underwater 7y ago
      Fixating on package size alone is missing the forest for the trees. A good library can massively reduce your application size and pay for itself many times over. For example, Relay removes the need for a lot of Flux and network request boilerplate. Going beyond that, it can collapse serial network fetches down into one request, massively speeding up page loads. (This doesn't apply to moment, that library is just designed in a brain dead way).
    - wolco 7y ago
      Not using moment will give you back 60k almost three times the savings: 22k
  - itsangaris 7y ago
    When talking about a few kilobytes, it’s less the download time than the parse time that’s the main performance concern.
danpalmer 7y ago
We use Urql and are loving it at Thread. Nice and lightweight, easy to use, easy to build our own infrastructure around.
yodon 7y ago
Excited 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.
- peggyrayzis 7y ago
  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.
  - underbluewaters 7y ago
    I've often found the react-apollo docs in particular confusing. They often rely on opaque type definitions to describe argument formats. For example, it took me a long time to understand what to pass to the `refetchQueries` argument of a Mutation component. A set of examples for common scenarios would be helpful.
  - svachalek 7y ago
    I've also recently started using Apollo client. The basic usage was pretty straightforward (although either I don't understand something about the loading flag or it just doesn't work very well). But in dealing with the loading flag issue I ended up writing middleware and there's a whole lot of types involved, links and middleware and afterware that seem needlessly complicated (why is middleware and afterware different, why does it seem like it's reinventing either Rx or Promises instead of just using one), compared to Redux middleware which is trivial to understand, write, and use and does basically the same thing as far as I can tell. Possibly this is just a doc issue but it seems like the API could benefit from some streamlining.
  - yodon 7y ago
    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 feel like I understand where the batteries go, much less what they are doing for me, I'm just copying and pasting code that others have used into my projects and hoping I have about the right amount of stuff included. Your customer didn't write all the Apollo code. The docs feel like they are written with the assumption that we understand the architecture and goals as well as you do and we just want to do some simple task with it to get started. I fear however that this is fundamentally not a docs problem. It feels like a problem where the Apollo devs didn't start by asking "how can I build something that will be easy for 3rd party devs to use and understand", they started with "oooh that would be cool". Urql feels like it started with a very simple and clear conceptual foundation that provides a clear roadmap for how and where more complex features get attached. If you can reduce Apollo down to a clear and simple framework in the docs that actually covers everything that it does, then you're golden. I suspect however that the underlying architectural simplicity that would be required for you to do this doesn't actually exist. If it does, you face a docs problem, if it doesn't, then docs are just a bandaid.
alexrage 7y ago
This is refreshing upon first glance. The Apollo Client docs are such a mess.
- peggyrayzis 7y ago
  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?
  - alexrage 7y ago
    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 `apollo-link-state` don't mention that, but the Local state management page in Apollo Client sure says it is.
    - WorldMaker 7y ago
      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".
      - 7y ago
xiaomai 7y ago
GraphQL is amazing. Building an API and then playing around with it in GraphiQl is really a exciting experience. I've played with Relay (relay-modern looks great, but when I needed to pick a graphql client it hadn't been released yet). Apollo is frustrating: it's big and complicated and obsessed with stuff that I don't want (link-state and a bunch of product up-sells). I'm glad urql is getting some more attention and I'll definitely give it a spin.
- helloguillecl 7y ago
  I was just looking for a smaller/simpler graphQL client. But I cannot try this yet as I need SSR (I'd need to remove SSR from my app in order to implement this library) I hope SSR support is included soon!
  - philplckthun 7y ago
    Yes, we're already working on SSR support! https://github.com/FormidableLabs/urql/issues/218 https://github.com/FormidableLabs/urql/issues/218 Since we didn't want to go down the same road as some other libraries that use renderToStaticMarkup and a promise-queue, we've already built a supporting package so that we can implement SSR-support using suspense. (At least the unstable API of suspense; which is as simple for us as adding throwing promises to our components and hooks) https://github.com/FormidableLabs/react-ssr-prepass https://github.com/FormidableLabs/react-ssr-prepass
    - huy-nguyen 7y ago
      Will definitely try it when it comes out.
      - philplckthun 7y ago
        Quick update: We've just published v1.1 with server-side rendering support! https://github.com/FormidableLabs/urql/releases/tag/v1.1.0 https://github.com/FormidableLabs/urql/releases/tag/v1.1.0
- 7y ago
leetbulb 7y ago
I _really like_ the implementation with hooks. I experimented with a similar pattern on top of Apollo on a side project. Going to play with urql today! Thank you!
scyclow 7y ago
urql's great, and the maintainers are super helpful and friendly. I've been using it on a project for a couple months now. Very straightforward and plays well with TypeScript. My one criticism is that it doesn't quite do enough in some cases, but I haven't spent the time to learn much about exchanges. As the ecosystem grows, I see this problem going away.
- huy-nguyen 7y ago
  I’m also interested in exploring exchanges.
kodon 7y ago
are you supposed to say urql like "Urkel"?
- jevakallio 7y ago
  Yes.
- thom_nic 7y ago
  I clicked the article link just because I was expecting to see this guy: https://en.wikipedia.org/wiki/Steve_Urkel#/media/File:Steve_Urkel.jpg https://en.wikipedia.org/wiki/Steve_Urkel#/media/File:Steve_...
ludwigvan 7y ago
This library is also quite minimal: https://github.com/f/graphql.js https://github.com/f/graphql.js
lprd 7y ago
Excited to try this out! Also glad to see Apollo getting some more competition. I made a side project last year with the Apollo ecosystem, it confused the hell out of me.
cobaimelan 7y ago
They also support abort fetch request :) :) :)
nicwolff 7y ago
Fun, 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-queries#protocol https://github.com/apollographql/apollo-link-persisted-queri...
patrickaljord 7y ago
There 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 https://github.com/mobxjs/mst-gql
- yodon 7y ago
  > 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
  - patrickaljord 7y ago
    It is pretty cool indeed, you can watch his presentation of the project here https://www.youtube.com/watch?v=Sq2M00vghqY https://www.youtube.com/watch?v=Sq2M00vghqY (disclosure, I organize this conf).
mikeyhew 7y ago
Does it typecheck queries for you based on the schema, and generate a response type for TypeScript?
- smusumeche 7y ago
  No, but you can do something like this: https://formidable.com/blog/2019/strong-typing/ https://formidable.com/blog/2019/strong-typing/
  - mikeyhew 7y ago
    Oh cool, they have a package for urql: https://graphql-code-generator.com/docs/plugins/typescript-urql https://graphql-code-generator.com/docs/plugins/typescript-u... I might try it out once it supports the new hooks.
holtalanm 7y ago
their Exchange architecture reminds me of the Plug framework used by Phoenix on Elixir.
holtalanm 7y ago
really interesting, but i took a look at the docs, and they 100% look like urql is only compatible with react. Can I use urql with Vue.js, or would I just be inviting misery upon myself if i tried?
- no1youknowz 7y ago
  > Can I use urql with Vue.js Would like to know this also.
- fernandotakai 7y ago
  we've been using apollo with vue.js (and typescript!) with a django-graphene backend and we've been having zero problems. honestly, it's my favorite stack nowadays.
revskill 7y ago
Most of graphql client library is non-lazy on url part. In my apps, i use a lazy apollo client API interface though: const data = useQuery(url, graphql_query, variables) The point here is that, the ApolloClient is lazily constructed and reused only when the hook is called. I don't know why Graphql must be used with non-lazy url instead. More than that, you don't need a Provider, because the apollo-client is reused between the calls.
DrFell 7y ago
GraphQL is a technology only a frontend webdev could love. You really want the burden of understanding the database schema and building the JS framework app? You really want ad-hoc data models written in some weird 'query language' littered throughout your frontend code? Building an API is actually easy, if you bother. 'No! GraphQL is lit!' OK kid, have fun snicker.
- tdy_err 7y ago
  No, I prefer writing an API endpoint and controller method for every resource I need to use on the client.
  - DrFell 7y ago
    It is just as easy as lots of things we take for granted, line making a new app route, or component. That is a non issue.
- kromem 7y ago
  It's clear from your comment you've not actually used the thing you are criticizing. Nothing about the spec necessitates duplicating your DB schema. In terms of the data models, you only need to spec out models based on what you want returned. It's perfectly fine to have limited data models for only what's being requested in a specific use case.
- priceytomato292 7y ago
  That's just moronic, I would even go as far that GraphQL is something only backend dev could love, the only benefits frontend dev gain using GraphQL is not having to wait on backend dev to change some random endpoint response. From a backend dev perspective GraphQL completely removes that chunk of work, solves the issue of over-fetching/under-fetching, and more importantly allows you to map your REST APIs into a single interface (and break your monolith into microservices transparently). If you're API is a todo list CRUD, then yes, you prob don't need GraphQL.
  - dang 7y ago
lewisl9029 7y ago
I really like the simplicity of the core library and this approach of starting from a simple core and building on top of it with the same primitive for extensibility as the one you offer to users. Apollo has also been moving in this direction with composable links, but in a zig-zaggy way since it's still got some baggage from its days as a monolithic library, and recent decisions to move local state management into core seems to be backtracking from that effort somewhat, so it's great to see some competition in this area that really approaches extensibility as a first class citizen rather than an afterthought. With that said, I'd love to see an officially supported normalizing cache implementation as well, in addition to the simple document cache Urql currently provides as a default: https://formidable.com/open-source/urql/docs/basics/#code-classlanguage-textcacheexchangecode https://formidable.com/open-source/urql/docs/basics/#code-cl... Apollo and Relay's normalizing cache helps ensure a single source of truth for every piece of server data, which is incredibly valuable for non-trivial apps that have the same pieces of data fetched in multiple places that would otherwise have to be manually kept in sync, which anyone who has ever tried to do so can tell you is generally extremely tedious, error prone, and likely a frequent contributor to user-facing bugs. That to me is by far the most compelling value prop of GraphQL clients like Apollo and Relay. It'd be great if I didn't have to choose between automatic normalization and a more flexible extensibility model (fwiw, I'd choose the former).
- philplckthun 7y ago
  Cheers! I'm happy to say that a normalising cache is indeed in progress and we're planning to finish it soon https://github.com/kitten/urql https://github.com/kitten/urql exchange-graphcache We've got the cache itself done but are just figuring out the API for its customisability in terms of cache resolvers and such
mc5ive 7y ago
Glorious

217 points by smusumeche 7y ago

Have been playing around with urql on a project for a couple of months now, mainly due to the small bundle size. Urql is 7.5kB min+gzip, where Apollo and Relay add ~30kB min+gzip! Great to see Formidable investing further in it, I am very excited to see first class extensibility.

methyl 7y ago
> Urql is 7.5kB min+gzip, where Apollo and Relay add ~30kB min+gzip! How is that 22.5kB making any difference? Unless you are working on a project that will be used on very slow connections I see no point in choosing a library basing on such small difference in size. And if you really are targeting those slow connections then maybe going SPA is not the best choice?
- helloguillecl 7y ago
  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.
  - methyl 7y ago
    > 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.
    - pavel_lishin 7y ago
      > it is expected It's also expected that my train is going to be late, but we can lament this condition, instead of resigning ourselves to it.
    - RossDM 7y ago
      18% of the Alexa Top 10K sites grew by 1MB+ from July 2017 - July 18. (source: https://twitter.com/katiehempenius/status/1133209127000379393 https://twitter.com/katiehempenius/status/113320912700037939...) Ignoring the impact of libraries you send to the frontend will lead to death by a thousand cuts.
      - methyl 7y ago
        How many of those Top 10k Alexa sites are full-blown web applications that need GraphQL in the first place?
    - ctvo 7y ago
      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.
    - RussianCow 7y ago
      It might be expected, but I have to admit, there is a certain joy to using a website that loads instantaneously (like Hacker News). Whether or not that joy translates into additional revenue to justify the costs is another question entirely...
  - underwater 7y ago
    Most apps need to do two core things: render UI and manage data. Setting a sub 30kb budget for something so core is madness.
- brianmathews 7y ago
  From recent bundle audits of e-commerce sites built with React, less than 20% of the code was actual custom site code and the remaining 80% was from dependencies. If the bundle size is 550kb min/gzipped, that's 110kb of app code, and 440kb of dependencies. Some of the largest dependencies in a recent audit were: moment (60kb), swiper (32kb), lodash (24kb), react-select (26kb), raven.js (12kb), polyfills (25kb), mobile-detect (15kb), and then a bunch of smaller dependencies that made up the remaining 300kb. Using this performance budget calculator you can quickly see how each 25kb of JS adds ~.3s to your TTI on a mobile phone: https://perf-budget-calculator.firebaseapp.com/ https://perf-budget-calculator.firebaseapp.com/ If developers shop around for smaller alternatives of each dependency, then they can cut their load times pretty drastically.
  - underwater 7y ago
    Fixating on package size alone is missing the forest for the trees. A good library can massively reduce your application size and pay for itself many times over. For example, Relay removes the need for a lot of Flux and network request boilerplate. Going beyond that, it can collapse serial network fetches down into one request, massively speeding up page loads. (This doesn't apply to moment, that library is just designed in a brain dead way).
  - wolco 7y ago
    Not using moment will give you back 60k almost three times the savings: 22k
- itsangaris 7y ago
  When talking about a few kilobytes, it’s less the download time than the parse time that’s the main performance concern.

danpalmer 7y ago

We use Urql and are loving it at Thread. Nice and lightweight, easy to use, easy to build our own infrastructure around.

yodon 7y ago

Excited 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.

peggyrayzis 7y ago
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.
- underbluewaters 7y ago
  I've often found the react-apollo docs in particular confusing. They often rely on opaque type definitions to describe argument formats. For example, it took me a long time to understand what to pass to the `refetchQueries` argument of a Mutation component. A set of examples for common scenarios would be helpful.
- svachalek 7y ago
  I've also recently started using Apollo client. The basic usage was pretty straightforward (although either I don't understand something about the loading flag or it just doesn't work very well). But in dealing with the loading flag issue I ended up writing middleware and there's a whole lot of types involved, links and middleware and afterware that seem needlessly complicated (why is middleware and afterware different, why does it seem like it's reinventing either Rx or Promises instead of just using one), compared to Redux middleware which is trivial to understand, write, and use and does basically the same thing as far as I can tell. Possibly this is just a doc issue but it seems like the API could benefit from some streamlining.
- yodon 7y ago
  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 feel like I understand where the batteries go, much less what they are doing for me, I'm just copying and pasting code that others have used into my projects and hoping I have about the right amount of stuff included. Your customer didn't write all the Apollo code. The docs feel like they are written with the assumption that we understand the architecture and goals as well as you do and we just want to do some simple task with it to get started. I fear however that this is fundamentally not a docs problem. It feels like a problem where the Apollo devs didn't start by asking "how can I build something that will be easy for 3rd party devs to use and understand", they started with "oooh that would be cool". Urql feels like it started with a very simple and clear conceptual foundation that provides a clear roadmap for how and where more complex features get attached. If you can reduce Apollo down to a clear and simple framework in the docs that actually covers everything that it does, then you're golden. I suspect however that the underlying architectural simplicity that would be required for you to do this doesn't actually exist. If it does, you face a docs problem, if it doesn't, then docs are just a bandaid.

alexrage 7y ago

This is refreshing upon first glance. The Apollo Client docs are such a mess.

peggyrayzis 7y ago
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?
- alexrage 7y ago
  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 `apollo-link-state` don't mention that, but the Local state management page in Apollo Client sure says it is.
  - WorldMaker 7y ago
    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".
    - 7y ago

xiaomai 7y ago

GraphQL is amazing. Building an API and then playing around with it in GraphiQl is really a exciting experience. I've played with Relay (relay-modern looks great, but when I needed to pick a graphql client it hadn't been released yet). Apollo is frustrating: it's big and complicated and obsessed with stuff that I don't want (link-state and a bunch of product up-sells). I'm glad urql is getting some more attention and I'll definitely give it a spin.

helloguillecl 7y ago
I was just looking for a smaller/simpler graphQL client. But I cannot try this yet as I need SSR (I'd need to remove SSR from my app in order to implement this library) I hope SSR support is included soon!
- philplckthun 7y ago
  Yes, we're already working on SSR support! https://github.com/FormidableLabs/urql/issues/218 https://github.com/FormidableLabs/urql/issues/218 Since we didn't want to go down the same road as some other libraries that use renderToStaticMarkup and a promise-queue, we've already built a supporting package so that we can implement SSR-support using suspense. (At least the unstable API of suspense; which is as simple for us as adding throwing promises to our components and hooks) https://github.com/FormidableLabs/react-ssr-prepass https://github.com/FormidableLabs/react-ssr-prepass
  - huy-nguyen 7y ago
    Will definitely try it when it comes out.
    - philplckthun 7y ago
      Quick update: We've just published v1.1 with server-side rendering support! https://github.com/FormidableLabs/urql/releases/tag/v1.1.0 https://github.com/FormidableLabs/urql/releases/tag/v1.1.0
7y ago

leetbulb 7y ago

I _really like_ the implementation with hooks. I experimented with a similar pattern on top of Apollo on a side project. Going to play with urql today! Thank you!

scyclow 7y ago

urql's great, and the maintainers are super helpful and friendly. I've been using it on a project for a couple months now. Very straightforward and plays well with TypeScript. My one criticism is that it doesn't quite do enough in some cases, but I haven't spent the time to learn much about exchanges. As the ecosystem grows, I see this problem going away.

huy-nguyen 7y ago
I’m also interested in exploring exchanges.

kodon 7y ago

are you supposed to say urql like "Urkel"?

jevakallio 7y ago
Yes.
thom_nic 7y ago
I clicked the article link just because I was expecting to see this guy: https://en.wikipedia.org/wiki/Steve_Urkel#/media/File:Steve_Urkel.jpg https://en.wikipedia.org/wiki/Steve_Urkel#/media/File:Steve_...

ludwigvan 7y ago

This library is also quite minimal: https://github.com/f/graphql.js https://github.com/f/graphql.js

lprd 7y ago

Excited to try this out! Also glad to see Apollo getting some more competition. I made a side project last year with the Apollo ecosystem, it confused the hell out of me.

cobaimelan 7y ago

They also support abort fetch request :) :) :)

nicwolff 7y ago

Fun, 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-queries#protocol https://github.com/apollographql/apollo-link-persisted-queri...

patrickaljord 7y ago

There 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 https://github.com/mobxjs/mst-gql

yodon 7y ago
> 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
- patrickaljord 7y ago
  It is pretty cool indeed, you can watch his presentation of the project here https://www.youtube.com/watch?v=Sq2M00vghqY https://www.youtube.com/watch?v=Sq2M00vghqY (disclosure, I organize this conf).

mikeyhew 7y ago

Does it typecheck queries for you based on the schema, and generate a response type for TypeScript?

smusumeche 7y ago
No, but you can do something like this: https://formidable.com/blog/2019/strong-typing/ https://formidable.com/blog/2019/strong-typing/
- mikeyhew 7y ago
  Oh cool, they have a package for urql: https://graphql-code-generator.com/docs/plugins/typescript-urql https://graphql-code-generator.com/docs/plugins/typescript-u... I might try it out once it supports the new hooks.

holtalanm 7y ago

their Exchange architecture reminds me of the Plug framework used by Phoenix on Elixir.

holtalanm 7y ago

really interesting, but i took a look at the docs, and they 100% look like urql is only compatible with react. Can I use urql with Vue.js, or would I just be inviting misery upon myself if i tried?

no1youknowz 7y ago
> Can I use urql with Vue.js Would like to know this also.
fernandotakai 7y ago
we've been using apollo with vue.js (and typescript!) with a django-graphene backend and we've been having zero problems. honestly, it's my favorite stack nowadays.

revskill 7y ago

Most of graphql client library is non-lazy on url part. In my apps, i use a lazy apollo client API interface though: const data = useQuery(url, graphql_query, variables) The point here is that, the ApolloClient is lazily constructed and reused only when the hook is called. I don't know why Graphql must be used with non-lazy url instead. More than that, you don't need a Provider, because the apollo-client is reused between the calls.

DrFell 7y ago

GraphQL is a technology only a frontend webdev could love. You really want the burden of understanding the database schema and building the JS framework app? You really want ad-hoc data models written in some weird 'query language' littered throughout your frontend code? Building an API is actually easy, if you bother. 'No! GraphQL is lit!' OK kid, have fun snicker.

tdy_err 7y ago
No, I prefer writing an API endpoint and controller method for every resource I need to use on the client.
- DrFell 7y ago
  It is just as easy as lots of things we take for granted, line making a new app route, or component. That is a non issue.
kromem 7y ago
It's clear from your comment you've not actually used the thing you are criticizing. Nothing about the spec necessitates duplicating your DB schema. In terms of the data models, you only need to spec out models based on what you want returned. It's perfectly fine to have limited data models for only what's being requested in a specific use case.
priceytomato292 7y ago
That's just moronic, I would even go as far that GraphQL is something only backend dev could love, the only benefits frontend dev gain using GraphQL is not having to wait on backend dev to change some random endpoint response. From a backend dev perspective GraphQL completely removes that chunk of work, solves the issue of over-fetching/under-fetching, and more importantly allows you to map your REST APIs into a single interface (and break your monolith into microservices transparently). If you're API is a todo list CRUD, then yes, you prob don't need GraphQL.
- dang 7y ago

lewisl9029 7y ago

I really like the simplicity of the core library and this approach of starting from a simple core and building on top of it with the same primitive for extensibility as the one you offer to users. Apollo has also been moving in this direction with composable links, but in a zig-zaggy way since it's still got some baggage from its days as a monolithic library, and recent decisions to move local state management into core seems to be backtracking from that effort somewhat, so it's great to see some competition in this area that really approaches extensibility as a first class citizen rather than an afterthought. With that said, I'd love to see an officially supported normalizing cache implementation as well, in addition to the simple document cache Urql currently provides as a default: https://formidable.com/open-source/urql/docs/basics/#code-classlanguage-textcacheexchangecode https://formidable.com/open-source/urql/docs/basics/#code-cl... Apollo and Relay's normalizing cache helps ensure a single source of truth for every piece of server data, which is incredibly valuable for non-trivial apps that have the same pieces of data fetched in multiple places that would otherwise have to be manually kept in sync, which anyone who has ever tried to do so can tell you is generally extremely tedious, error prone, and likely a frequent contributor to user-facing bugs. That to me is by far the most compelling value prop of GraphQL clients like Apollo and Relay. It'd be great if I didn't have to choose between automatic normalization and a more flexible extensibility model (fwiw, I'd choose the former).

philplckthun 7y ago
Cheers! I'm happy to say that a normalising cache is indeed in progress and we're planning to finish it soon https://github.com/kitten/urql https://github.com/kitten/urql exchange-graphcache We've got the cache itself done but are just figuring out the API for its customisability in terms of cache resolvers and such

mc5ive 7y ago

Glorious