relayjs

We have a graphql server (not written in javascript) serving a paginated list of objects. We're trying to conform to the relay specification, but we've hit an interesting case that could use clarification. Specifically: are cursors allowed to depend on other inputs to the connection? Similar to https://github.com/graphql/graphql-relay-js/issues/20 , our connection takes a sort_key argument that determines the sort order of the returned list. Depending on the specified sort order, the edge for an object may return different cursor values (since the server needs different information in each

How to handle Authorization in GraphQL servers? Shall I pass the JWT token in the Authentication header of every requests and check for the authorized user after resolve() and check for the role of user on every query and mutation Introduction First of all, a common approach for authentication as you state is using a signed JWT that contains the id of the user making the request. Now let's have a look at the different parameters we can use when considering the authorization of a given request. who is making the request? determined by the user id mentioned above. More information about the

I have a root query of songs , this is in a pagination container. I then have a nested property on songs called comments that I also want to be paginated because I don't want to load 10k comments for each song all at once. songsContainer.js: fragment songsContainer on Query { songs( first: $count after: $cursor genre: $genre filter: $filter ) @connection(key: "songsContainer_songs") { edges { node { audioId name coverImageUrl artist likes dislikes ...commentsContainer } } } } const connectionConfig = { direction: 'forward', query: graphql` query songsContainerForwardQuery( $count: Int! $cursor

I've been working on an application using react and relay, and now I'm stuck on implementing authentication. I know that you can pass value to each graphql request through the context which is available in GraphQL resolves functions. I'm more confused about what to pass for it and how. Is it better to use JSON Web token, passport, something else? And how should I pass the identifier for the user? Basically what I'm asking, What is best suitable for Relay: jwt, passport, something else? And how to hook it up with relay. Thanks! I think your best bet is to study some of the starter kit.

The official line from Facebook is that Relay is " intentionally agnostic about authentication mechanisms ." In all the examples in the Relay repository, authentication and access control are a separate concern. In practice, I have not found a simple way to implement this separation. The examples provided in the Relay repository all have root schemas with a viewer field that assumes there is one user. And that user has access to everything. However, in reality, an application has has many users and each user has different degrees of access to each node. Suppose I have this schema in JavaScript

I have to start a new (web + native) project (mid-size app) from scratch. Due to the plethora of JS frameworks and implementation out there especially in the last couple of years, I have been having a second doubt on my usual stack. I have been using react + redux on the front-end along with Node and MongoDB on the backend communicating through REST API's. For this new project, I have decided to go with React-Native + React Native for Web + Node + PostgreSQL. However, I am wondering which framework I should use to the data fetching and state/store management. So far, redux worked for me nicely

In Relay GraphQL, connections and lists are both array-like, but they have different features. When should I use each? Connections More powerful and flexible than simple lists. Support pagination (forward and back), with cursors. Fine-grained mutation support (eg. RANGE_ADD , RANGE_DELETE , NODE_DELETE , as described in the guide ). Requires a first or last argument in order to limit the size of the result set. Has an edges field that provides a place to locate per-edge, edge-specific data. A heavier-weight concept, requiring more work to define in the schema. Lists Simple and lightweight. No