113 Matching Annotations
  1. Jan 2024
  2. Sep 2023
  3. Aug 2023
    1. TL;DR For classic Rails apps we have a built-in scope for preloading attachments (e.g. User.with_attached_avatar) or can generate the scope ourselves knowing the way Active Storage names internal associations.GraphQL makes preloading data a little bit trickier—we don’t know beforehand which data is needed by the client and cannot just add with_attached_<smth> to every Active Record collection (‘cause that would add an additional overhead when we don’t need this data).That’s why classic preloading approaches (includes, eager_load, etc.) are not very helpful for building GraphQL APIs. Instead, most of the applications use the batch loading technique.
  4. Jul 2023
    1. ```js // Getting details on a Threads user and outputting it to the console

      const getUserDetails = async (username) => { let userInfo = await threads.getUserData(username); console.log( "", Name: ${userInfo.full_name}\n, Bio: ${userInfo.biography}\n, ID: ${userInfo.user_id}\n, Followers: ${userInfo.follower_count}\n, Website: ${userInfo.bio_links[0].url} ); } getUserDetails("Gisgar3"); ```

    1. ```js import { ThreadsAPI } from 'threads-api';

      // or in Deno 🦖: // import { ThreadsAPI } from "npm:threads-api";

      const main = async () => { const threadsAPI = new ThreadsAPI();

      const username = '_junhoyeo'; const id = await threadsAPI.getUserIDfromUsername(username); console.log(id);

      if (!id) { return; }

      const user = await threadsAPI.getUserProfile(username, id); console.log(JSON.stringify(user));

      const posts = await threadsAPI.getUserProfileThreads(username, id); console.log(JSON.stringify(posts));

      const replies await threadsAPI.getUserProfileReplies(username, id); console.log(JSON.stringify(replies)); }; main(); ```

  5. May 2023
    1. Sharing models

      This looks worth trying as an alternative to generating types from inspecting the schema from a running API instance.

  6. Mar 2023
  7. hydrogen.shopify.dev hydrogen.shopify.dev
    1. ```js import {defer} from "@shopify/remix-oxygen";

      export async function loader({ params: {handle}, context: {storefront} }) { const {product} = storefront.query({ query: #graphql query Product( $country: CountryCode, $language: LanguageCode, $handle: String! ) @inContext(country: $country, language: $language) product(handle: $handle) { id title }, variables: {handle}, cache: storefront.CacheLong() }); const {productRecommendations} = storefront.query({ query: #graphql query ProductRecommendations( $country: CountryCode, $language: LanguageCode, $handle: String! ) @inContext(country: $country, language: $language) productRecommendations(handle: $handle) { id title } }, variables: {handle} }); if (!product) { throw new Response('Not Found', { status: 404, }); } return defer({ product: await product, productRecommendations, }); } ```

  8. Feb 2023
    1. [Episode!]! represents an array of Episode objects. Since it is also non-nullable, you can always expect an array (with zero or more items) when you query the appearsIn field. And since Episode! is also non-nullable, you can always expect every item of the array to be an Episode object.

      Note that this still allows an empty array, []. It only disallows: null and [null].

  9. Nov 2022
  10. Oct 2022
  11. Aug 2022
  12. Jun 2022
    1. The creator of GraphQL admits this. During his presentation on the library at a Facebook internal conference, an audience member asked him about the difference between GraphQL and SOAP. His response: SOAP requires XML. GraphQL defaults to JSON—though you can use XML.
    2. Conclusion There are decades of history and a broad cast of characters behind the web requests you know and love—as well as the ones that you might have never heard of. Information first traveled across the internet in 1969, followed by a lot of research in the ’70s, then private networks in the ’80s, then public networks in the ’90s. We got CORBA in 1991, followed by SOAP in 1999, followed by REST around 2003. GraphQL reimagined SOAP, but with JSON, around 2015. This all sounds like a history class fact sheet, but it’s valuable context for building our own web apps.
  13. May 2022
  14. Feb 2022
    1. Rejecting based on query complexity (cost analysis)Amount limitingDepth limiting

      limit the load on the network

    2. We can reduce the load on the database significantly by batching and caching with Data Loader
    3. The issue is that potential attackers can easily call complex queries, which may be extremely expensive for your server and network.
    4. If you are in a development environment, it is definitely useful to allow introspection for various purposes. In production, however, it can leak important information for potential attackers, or it can also just reveal information about a new feature which has not yet been implemented on the frontend.
    1. When testing and trying out your mutations, I suggest you only use variables, and use inline arguments as little as possible. This will force you to make GraphQL documents that can be copy-pasted right from the GraphiQL into your integration test suits and to your frontend. If you only use inline arguments, you will need to rewrite the GraphQL document in the client.
    2. In most cases, it is much better to use the object type and input object type. If you want to add some field as the return, you should not use simple scalars as return values, as this will cause your GraphQL document to break.
    3. GraphQL does not support versioning out of the box, but is designed in a way that minimises the need for it
    1. The risk is that when you build a new thing for the second time, you'll feel less cautious and more experienced, and end up over designing the whole thing.
    2. Avoid implementing things that you might need in the future in favor of things that you definitely need today.
    3. When building queries, focus on the underlying data, rather than how it's represented in your application.
    4. Describe the data, not the view. Make sure that your API isn't linked too closely with the demands of your initial interface.
    5. Your objective with GraphQL should be to create a unified, cohesive graph that allows users of your API to create subsets of that graph in order to build new product experiences.
    1. it is much better to nest the output types. This way we can call everything with one single request, and also perform caching and batching with the data loader.
    2. Whenever you fetch lists, I suggest you use paginated if it makes sense. You will avoid breaking changes of the schema in the future, and it is almost always a much more scalable solution.
    3. Returning affected objects as a result of mutations
    4. Using the input object type for mutations
    5. Use consistent naming in your schema

      camelCase for fields, PascalCase for type names

  15. Jan 2022
    1. HyperGraphQL is a GraphQL interface for querying and serving linked data on the Web. It is designed to support federated querying and exposing data from multiple linked data services using GraphQL query language and schemas. The basic response format is JSON-LD, which extends the standard JSON with the JSON-LD context enabling semantic disambiguation of the contained data.
    1. I just got caught out by realising I wasn't wrapping my component in a <Provider> that provides our own GraphQL client because the default context value is a urql client. I get why this is a good default out the box for getting started, but I'd love to disable that so that we can ensure all our components are wrapped with a provider that exposes our custom client.
      • defaults

      • disable defaults/safeguard to make sure you always provide a value

    1. Exchanges are bi-directional. So suppose you have the default order: [dedupExchange, cacheExchange, fetchExchange], then an operation describing the GraphQL request, which is only the intent to send a request, goes from outer to inner, or left to right. It'll reach dedup first, then cache, then fetch. This is the operation stream. The operation result stream goes the other way. fetch might emit a result, which is seen by cache, and then seen by dedup. This is a little abstract and we will need some visuals to make this an accessible concept to everyone. This is how it works because every exchange receives a stream of operations. It can then transform this stream and call forward with an altered stream (so every exchange has full control over filtering, mapping, reducing, timing of operations). Furthermore, every return value of an exchange is a stream of results. This means that the simplest exchange just forwards all operations and returns an unaltered stream of results: ({ forward }) => ops$ => forward(ops$). For your "error exchange" (which we should probably provide by default?) this means that it must come before the fetch exchange: [dedupExchange, cacheExchange, errorExchange, fetchExchange] Specifically, it won't need to alter the operations probably, but it will need to look at the results from the fetchExchange which means it must be outside fetch or come before it. Here's an example of a simple implementation of such an exchange: import { filter, pipe, tap } from 'wonka'; import { Exchange } from 'urql'; export const errorExchange: Exchange = ({ forward }) => ops$ => { return pipe( forward(ops$), tap(({ error }) => { // If the OperationResult has an error send a request to sentry if (error) { // the error is a CombinedError with networkError and graphqlErrors properties sentryFireAndForgetHere() // Whatever error reporting you have } }) ); };

      exchange

  16. Dec 2021
    1. declaration accepts: | null | [] | [null] | [{foo: 'BAR'}] ------------------------------------------------------------------------ [Vote!]! | no | yes | no | yes [Vote]! | no | yes | yes | yes [Vote!] | yes | yes | no | yes [Vote] | yes | yes | yes | yes
    2. [Vote!]! means that the field (in this case votes) cannot return null and that it must resolve to an array and that none of the individuals items inside that array can be null. So [] and [{}] and [{foo: 'BAR'}] would all be valid (assuming foo is non-null). However, the following would throw: [{foo: 'BAR'}, null] [Vote]! means that the field cannot return null, but any individual item in the returned list can be null. [Vote!] means that the entire field can be null, but if it does return a value, it needs to an array and each item in that array cannot be null. [Vote] means that the entire field can be null, but if it does return a value, it needs to an array. However, any member of the array may also be null.
  17. Nov 2021
    1. Feature GraphQL REST

      GraphQL vs *REST (table)

    2. There are advantages and disadvantages to both systems, and both have their use in modern API development. However, GraphQL was developed to combat some perceived weaknesses with the REST system, and to create a more efficient, client-driven API.

      List of differences between REST and GraphQL (below this annotation)

  18. Jul 2021
    1. Because GraphQL is an opinionated API spec where both the server and client buy into a schema format and querying format. Based on this, they can provide multiple advanced features, such as utilities for caching data, auto-generation of React Hooks based on operations, and optimistic mutations.
  19. Jun 2021
    1. This kind of error handling does express error state (either via HTTP 500 or by the top-level "errors" key), but it doesn’t take advantage of GraphQL’s type system and can only express one error at a time.
    2. It works, but a stronger solution is to treat errors as data.
    3. In mutations, when errors happen, the other fields may return nil. So, if those other fields have null: false, but they return nil, the GraphQL will panic and remove the whole mutation from the response, including the errors!
    1. In general, top-level errors should only be used for exceptional circumstances when a developer should be made aware that the system had some kind of problem. For example, the GraphQL specification says that when a non-null field returns nil, an error should be added to the "errors" key. This kind of error is not recoverable by the client. Instead, something on the server should be fixed to handle this case. When you want to notify a client some kind of recoverable issue, consider making error messages part of the schema, for example, as in mutation errors.
    1. With GraphQL-Ruby, it’s possible to hide parts of your schema from some users. This isn’t exactly part of the GraphQL spec, but it’s roughly within the bounds of the spec.
  20. Mar 2021
  21. Feb 2021
  22. Oct 2020
  23. Sep 2020
    1. urql/packages/svelte-urql/ Go to file Add file Go to file Create new file Upload files urql/packages/svelte-urql/
    1. you may specify only the form state that you care about for rendering your gorgeous UI. You can think of it a little like GraphQL's feature of only fetching the data your component needs to render, and nothing else.
    1. Intro to using GraphQL with Craft CMS, using a practical example. Rather technical (many things I don't understand). But it gives a good idea of what is happening.

  24. Jun 2020
    1. const httpLink = new HttpLink({ uri: 'https://instagram-clone-3.herokuapp.com/v1/graphql' }); const authLink = setContext((_, { headers }) => { const token = accessToken; if (token) { return { headers: { ...headers, authorization: `Bearer ${token}` } }; } else { return { headers: { ...headers } }; } }); const client = new ApolloClient({ link: authLink.concat(httpLink), cache: new InMemoryCache() });

      concat two link

  25. May 2020
    1. Although there were some patenting and licensing concerns with GraphQL, these have been resolved to our satisfaction by the relicensing of the reference implementations under MIT, and the use of the OWF license for the GraphQL specification.
    1. Apollo client, help with handling errors, but not as easily as in a REST API

      Error handling conventions

    2. not recommended because it adds more complexity because of things such as: Types Queries Mutators Resolvers High-order components

      Using GraphQL in a simple application (for example, one that uses a few fields in the same way, every time)

  26. Apr 2020
    1. GraphQL gels especially well with modern JavaScript driven front ends, with excellent tools like Apollo and Apollo-Server that help optimise these calls by batching requests.

      GraphQL + Apollo or Apollo-Server

    2. BFF is an API that serves one, and specifically only one application

      BFF (backend for frontend):

      • translates an internal domain into the terminal language of the app it serves
      • takes care of authentication, rate limiting, and other stuff you don't want to do more than once
      • reduces needless roundtrips to the server
      • translates data to be more suitable for its target app
      • is pretty front-end-dev friendly. Queries and schema strongly resemble JSON & it keeps your stack "JS all the way down" without being beholden to some distant backend team
    3. GraphQL really is just a smart and effective way to schema your APIs, and provide a BFF – that’s backend for frontend
    4. What sets GraphQL apart a little from previous approaches (notably Microsofts’ OData) is the idea that Types and Queries are implemented with Resolver code on the server side, rather than just mapping directly to some SQL storage.

      What makes GraphQL favorable over other implementations.

      In result:

      • GraphQL can be a single API over a bunch of disparate APIs in your domain
      • it solves the "over fetching" problem that's quite common in REST APIs (by allowing the client to specify a subset of data to return)
      • acts as an anti-corruption layer of sorts, preventing unbounded access to underlying storage
      • GraphQL is designed to be the single point of connection that your web or mobile app talks to (it highly optimises performance)
    5. GraphQL is confusingly, a Query Language, a standard for HTTP APIs and a Schema tool all at once.

      GraphQL

  27. Mar 2020
    1. The combination of WordPress, React, Gatsby and GraphQL is just that - fun

      Intriguing combination of technologies.

      Keep an eye on the post author, who is going to discuss the technologies in the next writings

  28. Feb 2020
  29. Jan 2020
  30. Dec 2019
    1. The foundation of GraphQL is its type system. There are basic types like String and Integer and there are complex types that have named attributes.

      Type system is the foundation of GraphQL

  31. Nov 2019
    1. REST and GraphQL are wonderful tools to create an API that is meant to be consumed by third parties. Facebook's API, for example, is consumed by ~200k third parties. It is no surprise that Facebook is using (and invented) GraphQL; a GraphQL API enables third parties to extensively access Facebook's social graph enabling them to build all kinds of applications. For an API with that many consumers, GraphQL is the fitting tool. But, to create an internal API (an API developed and consumed by code written by the same organization), RPC offers a simpler and more powerful alternative. Large companies, such as Netflix, Google and Facebook, are starting to replace REST/GraphQL with RPC for their internal APIs. Most notably with gRPC which is getting popular in the industry.
    2. RPC is increasingly used to create backend APIs as most are internal: most of the time, a backend API is consumed only by frontends developed within the same organization. In general, REST and GraphQL are the right tools if you want to create an API consumed by code written by third parties and RPC is the right tool if you want to create an API consumed by code written by yourself / your organization.
  32. Jun 2019
  33. Nov 2018
    1. GraphQL is being used in production by a variety of high scale companies such as Airbnb, Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, Shopify, The New York Times, Twitter, Pinterest and Yelp. GraphQL also powers hundreds of billions of API calls a day at Facebook.

      Usage of graphql by companies

  34. Oct 2018