Prisma

everything reported green over on <https://status.graph.cool/>

but yea, seeing a major slowdown on response times

getting issues loading the graph cool console also

still not seeing any indication on status.graph.cool

It works here. Which region are you using?

I’m also getting a lot of 504 gateway timeout

<https://status.graph.cool/> still showing all green tho, and its been getting bad for the last 1.5 hours

got product demos with clients next week :scream:

Thanks everyone, we're currently looking into this, I'll keep this channel posted.

hey <@U63RJH69E> <@U5LU7PU5U> <@U4M2NK7A8> <@U691W40GY> <@U5G4E19U7> <@U3C0NSE76> <@U67SJHPEH> <@U5UB5283Y> <@U4C31EJ8K> <@U5P82S230> <@U4RHJB44A> <@U5FEM4YUW> <@U55220BU6> <@U4KES2J7P> we could narrow the problems down, so it should only affect a few projects now. Please send me a PM if you are still affected by performance issues, thanks :raised_hands:

Seems to be good - although today I’m working on some loading states/error states so it would be quite nice if you could break the API again. Thanks :stuck_out_tongue:

Funny- actually having the same problems as yesterday - although it’s good for what I’m building right now, what’s up?

Thanks, I just updated the status page: <https://status.graph.cool/incidents/2017/08/03/degraded-performance-for-apis/>

same here, console works only occasionally

Here (from EU on EU project) some slowness in console and Playground, but no 504's

Anyone have any tips on how to make a query in Relay Modern that should not be tied to a render? (i.e. no QueryRenderer or containers). I’m toying around with exporting the fetchQuery from my Environment, but I’m not sure if it’s the way to go

the only way I’m aware of is to use ` this.props.relay.environment._network.fetch(query, variables)`

this is also used here if you want a practical example: <https://www.howtographql.com/react-relay/6-more-mutations-and-updating-the-store/>

Thanks! However, the component that needs to perform the fetch is not wrapped in a container

Ah I see - well you could just import the environment then and simply call `environment._network.fetch(query, variables)`

… you were faster than me :wink: Was about to ask that

Going to try it out, give me a couple of minutes

also be aware that `query` is an _object_ where the actual query string should be in a field called `text`

```
  const checkVoteQueryText = `
  query CheckVoteQuery($userId: ID!, $linkId: ID!) {
    viewer {
      allVotes(filter: {
        user: { id: $userId },
        link: { id: $linkId }
      }) {
        edges {
          node {
            id
          }
        }
      }
    }
  }`
  const checkVoteQuery = { text: checkVoteQueryText }

  const result = await this.props.relay.environment._network.fetch(checkVoteQuery, {userId, linkId})
```

Yeah, thanks :slightly_smiling_face: It works

However, it feels hacky to access the private variable _network

I feel like Facebook might change that (or the access to it) without alerting anyone of it as a breaking change

I’ve found another approach on Hackernoon: <https://gist.github.com/koistya/7e92b345d0792df8ba5d75445ca74318#file-api-js>

He exposes an object with both the environment, as well as the fetchQuery itself (amongst others)

<https://hackernoon.com/getting-started-with-relay-modern-for-building-isomorphic-web-apps-ae049e4e23c1>

What do you think is cleaner? Using the _network variable, or this way? I’m in doubt

I think that if you’re using it only once or twice then this approach might be a bit overkill and just importing using the environment might just be faster… if you find yourself doing this more often I think this is definitely the cleaner approach though

Agreed. I think I might set it up similar to how the Hackernoon article suggests, I feel like it could be something that is needed a lot more down the road as the app evolves

Thanks for the inputs! :slightly_smiling_face: ;+1:

Did something change with react-relay that breaks this method of calling fetch on _network. I have tried calling it on this.props.relay.environment._network, tried importing environment and calling directly on imported env... All the other part of the full stack react-relay tutorial are working fine.

I must have missed something a fresh clone works will have to figure it out.

Well FB has removed fetch in 1.3.0 and is moving things to observer which looks to have been renamed execute in more recent commits.

We’ve moved away from _network as it seemed too hacky, seeing as it’s a private var. We’re now exposing the fetchQuery from the relay-runtime to our app when we need to make seperate fetches:

```// @flow
'use strict';

import {
  Environment,
  Network,
  RecordSource,
  Store,
  fetchQuery,
} from 'relay-runtime';

import { getConfig } from './../util/configHelper';
import { graphql } from 'relay-runtime';

const TAG = 'RelayApi';

export type RelayApi = {
  environment: Environment,
  performFetchQuery: (
    environment: Environment,
    query: any,
    variables: any
  ) =&gt; {},
  graphql: graphql,
  hasGraphcoolToken: boolean,
};

const create = (graphcoolToken?: string): RelayApi =&gt; {
  console.log(
    `${TAG} creating RelayApi with token ${graphcoolToken
      ? graphcoolToken
      : 'null'}`
  );
  const source = new RecordSource();
  const store = new Store(source);

  const environment = new Environment({
    network: Network.create((operation, variables, cacheConfig, uploadables) =&gt;
      fetch(getConfig().graphcool.baseURL, {
        method: 'POST',
        headers: _getHeaders(graphcoolToken), // Add authentication and other headers here
        body: JSON.stringify({
          query: operation.text, // GraphQL text from input
          variables,
        }),
      }).then(response =&gt; {
        return response.json();
      })
    ),
    store: store,
  });

  const _getHeaders = (graphcoolToken?: string | null) =&gt; {
    let headers = {
      Accept: 'application/json',
      'Content-Type': 'application/json',
    };

    if (
      graphcoolToken !== null &amp;&amp;
      graphcoolToken &amp;&amp;
      graphcoolToken.length &gt; 0
    ) {
      headers.Authorization = `Bearer ${graphcoolToken}`;
    }
    return headers;
  };

  const performFetchQuery = (
    environment: Environment,
    query: any,
    variables?: any
  ) =&gt; {
    return fetchQuery(environment, query, variables);
  };

  return {
    environment,
    performFetchQuery,
    graphql,
    hasGraphcoolToken: !!graphcoolToken,
  };
};

export default { create };```

Any closer to solving the response times? Sooooo slow right now

we are still investigating the cause of the issue :slightly_smiling_face: stand by!

Is there any system in place to track which users create/update/delete certain records? Or is that something i’d have to create myself

Is it possible to mock a graphql server with graphql-tools so that i can use graphiql without express ?

does `updateOrCreate` work for other fields yet?

<@U5GF08HKM> What do you mean by other fields?

so right now `updateOrCreate` will work based on `id`, but will it work based on `email` for example

Any possibility to upload multiple files in the same request? <@U0RQY0KK5> .

no :slightly_smiling_face: there's a feature request, however: <https://github.com/graphcool/feature-requests/issues/115>

thanks <@U4K613RSS> :slightly_smiling_face:

<@U5GF08HKM> But _supposedly_ a new and better version of updateOrCreate is planned: <https://github.com/graphcool/feature-requests/issues/25#issuecomment-316313552>. But yeah, it makes a lot of sense to be able to perform upsert on all unique fields