apollographql / apollo Goto Github PK

I see there are integrations already for React and Angular. I would be very interested in trying out apollo if it were available for Ember

Eg this one I got a few hours after starring Onsen UI:

Load the page, press spacebar, no scrolling. Seems to be a keyboard focus issue? Once you click anywhere on the page scrolling is fine.

I really like the idea behind GraphQL and think it solves a couple of problems which we come across with dpp like scalability, support for other databases, faster partial queries and absolutely controlable mutations. Controlable realtime propagation of changes. However GraphQL often seems to me to ways more loselessly coded. Read one field/object here, update another column there. Different to the more classical model based approach.

Imho I am having the feeling that the ismorphic model/collection based approach (which is the major benefit of meteor) a little bit gets lost through the GraphQL strategy?

I'm building smaller really data-driven apps. So I have to CRUD to several models. I think this is a really strong major advantage and usecase of many meteor users.

• Make DB usage in the front-end a nobrainer (honestly I'dont want to waste a lot of time writing server code)
• Don't have to worry about data syncing, optimistic updates and so on
• Optimistic and realtime
• Having simple isomorphic reusable models on client and server with functionality like create, save, update, validate, very smartly available on both
• I'm missing native MySQL and support though :(

Both, GraphQL and the DPP, have advantages. Is combining them anyhow possible and a good idea?

• Maintaing universal model using graphql in background for syncing?
• Allowing for both stragies, a GraphQL-driven one and an model driven one using GraphQL for syncing in background with tunable data strategies?

Or do you think this model/collection driven approach will be deprecated in future and we'll us solely GraphQL instead?

Heads up to you guys! I think GraphQL/Falcor do have their major advantages in ultra large scale systems right now. I really like the idea behind apollo's mission is to bring this advantage down to simple earth projects and their typical use-cases!

PS.: I'm pretty knew to meteor and just run across apollo and not an expert, so excuse if I'm not have a fully understanding, yet.

I was wondering if you guys were thinking about how resolvers will be managed as the Namespaces grow in number and in size?

I was thinking you could do something like...

function generateRootQuery(Query) {
 return {
    Query
  };
}

function author(root, args){
      return Authors.findOne({
        firstName: args.firstName,
        lastName: args.lastName
      }, {
        fields: {
          'firstName': 1,
          'lastName': 1
        }
      });
    }
}

export const rootQuery = generateRootQuery({ author });

This would work well becuse you could then separate the query resolvers into modules, then do a rootQuery export.

Then you could combine resolvers as well

function rootResolver(Query, Types) {
   return Object.assign({}, {Query}, {...Types});
}


// used like

import rootQuery from '/imports/data/rootQuery';
import Author from '/imports/data/resolvers/Author';

export default rootResolver(rootQuery, {Author});

I dont know something like that?

Hey guys, absolutely epic work here! 👏 Can't believe how quickly everything has been put together, especially all the various integrations, etc.

One of the most awesome things about Meteor for me has always been how packages could rely on the full stack. But for the majority of cases, this really just amounted to having database access on the client and server (and routing, but we'll save that for another day).

I think it would be great to have some guidelines for package authors, even if they're pretty simple and obvious. The idea is that application developers will have a consistent experience in adding apollo-aware packages to their app. i.e.

npm install --save apollo-awesome apollo-admin

// client/lib/apollo-packages.js
import apolloClient from './apollo-client.js';

import Admin from 'apollo-admin';
import Awesome from 'apollo-awesome';

const admin = new Admin({ apolloClient });
const awesome = new Awesome({ apolloClient, and, other, options });

export { admin, awesome };

// server/lib/apollo-packages.js
import apolloServer from './apollo-server.js';
import Awesome from 'apollo-awesome';
const awesome = new Awesome({ apolloServer });
export { awesome };

And then for package authors, maybe something like:

import ApolloClient from 'apollo-client';

class Awesome {
  constructor({ apolloClient }) {
    if (!(apolloClient instanceof ApolloClient))
      throw new Error("awesome.init(options) expects options.apolloClient to be a valid ApolloClient instance");
    this.apolloClient = apolloClient;
  }
}

export default Awesome;

with guidelines / recommendations, i.e. Apollo packages should:

• Export a default class with a constructor(options) that takes an apolloClient or apolloServer
• Assert that said object is an instance of the respective class
• Include apollo-client/server as a peer dependency.

Like I said, this is may be quite simple and obvious, but I think a consistent and easy application developer experience will do wonders for quick and happy adoption.

The directory layout about could also be a recommendation for application developers, but they can do whatever makes sense for them, the main thing is that instantiating apollo packages is a consistent and natural experience.

First of all, congratulations for taking on this big challenge!

Let's say you want to display a list of top 5 users (ordered desc by points). Given that another user gains enough points to be in top 5, how will you invalidate the results?

When using Apollo's SSR implementation with react-router v4 with the following code (in express-context, assuming res was provided bei express) the following error appears:

    const context = createServerRenderContext();
    const client = new ApolloClient({
      ssrMode: true,
      networkInterface: createNetworkInterface('http://localhost:3000/graphql', {
        credentials: 'same-origin',
        headers: req.headers,
      }),
    });

    const app = (<ApolloProvider client={client}>
      <ServerRouter
        location={req.url}
        context={context}
      >
        <div>
          <h1>Hello World!</h1>

          <Match pattern="/" exactly render={() => (<span>Home</span>)} />
          <Match pattern="/foo" render={() => (<span>Foo</span>)} />
          <Match pattern="/bar" render={() => (<span>Bar</span>)} />
          <Miss render={() => (<span>Sorry, nothing found =(</span>)} />
        </div>
      </ServerRouter>
    </ApolloProvider>);

    getDataFromTree(data.children).then((apolloContext: Object) => {
      // this breaks...
    }).catch((e: Object) => {
      throw new Error(e);
    });

Error Message:

TypeError: Cannot set property 'hasMissComponent' of undefined
    at Object.registerMissPresence (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:109436:45)
    at new Miss (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:107196:30)
    at getQueriesFromTree (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:70527:27)
    at /Users/Stefan/Documents/www/projects/starterkit/build/server.js:70543:78
    at forEachSingleChild (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:66125:10)
    at traverseAllChildrenImpl (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:67110:7)
    at traverseAllChildrenImpl (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:67126:25)
    at traverseAllChildren (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:67205:12)
    at Object.forEachChildren [as forEach] (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:66145:5)
    at getQueriesFromTree (/Users/Stefan/Documents/www/projects/starterkit/build/server.js:70543:28)

Any idea on how to setup react-router v4 with apollo?

Maybe I'm missing the obvious, but how will we be able to retrieve / mutate data with variable schema? Consider the following scenario:

• Mongo collection where each document contains a the schema definition for a sub-document. This schema is not fixed but varies from document to document. How can we retrieve such documents when we don't know in advance its schema?

Example collection:

[
  {
    "_id": "1",
    "name": "A",
    "fldDef": [
      {
        "name": "f1",
        "type": "str",
        "opt": false
      },
      {
        "name": "f2",
        "type": "bool"
      }
    ],
    "flds": {
      "f1": "value1",
      "f2": true
    }
  },
  {
    "_id": "2",
    "name": "B",
    "fldDef": [
      {
        "name": "f3",
        "type": "str",
        "opt": true
      },
      {
        "name": "f4",
        "type": "str",
        "opt": true
      },
      {
        "name": "f5",
        "type": "num"
      }
    ],
    "flds": {
      "f3": "value3",
      "f5": 25
    }
  }
]

i'm new to apollo (new to react, really). i'm trying to use react-codemirror in an apollo component.

i'm loading some code from the server as base64, then attempting to decode it and display in the react-codemirror component i have wrapped in an apollo component.

below

Here is my component. I'm having trouble with backticks in the markdown, so it's a little odd:

`import React, { Component } from 'react';
import {browserHistory} from 'react-router';
import { graphql } from 'react-apollo';
import gql from 'graphql-tag';
import b64 from 'js-base64';
import CodeMirror from 'react-codemirror';
import {getCodeMirror} from 'react-codemirror';
import '../../../../../node_modules/codemirror/mode/javascript/javascript'
import FbktComponent from '../FbktComponent';

class KvXform extends FbktComponent {
constructor(){
super();

	const data = {
		name:	'A Place',
		contacts:	[
			{
				email:	'[email protected]',
				location:	{
					name:		'Main Store',
					geoJson: {type: 'Point', coordinates: [-122.341856, 47.610606]}
				}
			}
		]
	};
	
	this.inputData = `````const inputData = ${JSON.stringify(data,null,2)};`````;

	this.outputData = 'const outputData = {}';
}

updateCode(newCode) {
	this.code = newCode;
}

executeCode(e){
	const code = this.xformCode.getCodeMirror().doc.getValue();
	const codeWithData = `````
${this.inputData}

${code}

xform(inputData);

		console.log('codeWithData', codeWithData);
		const output = eval(codeWithData);
		console.log('output', JSON.stringify(output,null,2));

		this.outputData = `````const outputData = ${JSON.stringify(output,null,2)};`````;
	}
	
	static decodeXform(xformText){
		console.log('XFORM TEXT', xformText !== 'No Xform', xformText);
		return xformText !== 'No Xform'
			? b64.Base64.decode(xformText)
			: xformText;
	}
	
	componentDidUpdate(){
		this.xformCodeMirror.forceUpdate();
	}
	
	render() {
		const options = {
			lineNumbers: true,
			mode:	'javascript'
		};
		
		const style = {
			width: 	'50%',
			float:	'left'
		};
		
		const {kvXform={}} = this.props.data;
		const {name='No Xform'} = kvXform;
		const {xformText='No Xform'} = kvXform;

		const xformCode = KvXform.decodeXform(xformText);
		console.log('XFORM TEXT', xformText !== 'No Xform', xformCode);

		return (
			<div>
				<button type="button" onClick={this.executeCode.bind(this)}>Execute</button>
				<hr></hr>
				<CodeMirror
					ref={(codeMirror)=>this.xformCodeMirror = codeMirror}
					value={xformCode}  // THIS VALUE NEVER UPDATES
					onChange={this.updateCode.bind(this)}
					options={options}
				/>
				<hr></hr>
				<div style={style}>
					<CodeMirror
						ref={(codeMirror)=>this.inputCodeMirror = codeMirror}
						value={this.inputData}
						onChange={this.updateCode.bind(this)}
						options={options}
					/>
				</div>
				<div style={style}>
					<CodeMirror
						ref={(codeMirror)=>this.outputCodeMirror = codeMirror}
						value={this.outputData}
						onChange={this.updateCode.bind(this)}
						options={options}
					/>
				</div>
			</div>
		)
	}
}

const Query = gql`````
query kvXform($id: Int!){
	kvXform (id: $id){
		id,
		name,
		xformText
	}
}
`````;

const KvXformWithData = graphql(Query, {
	options: props => ({ variables: {id: props.params.id} }),
})(KvXform);

export default KvXformWithData;
`


so i guess i have two questions:

1) for the first render, this is where loading is true, and i want to have the app act accordingly?
2) on the second render, i'm guessing that the codemirror state is not being properly updated somehow.  would this be a problem with apollo or with react-codemirror?  or neither and is there something i'm just doing incorrectly.

thanks,

kevin

Maybe the high level design document could be moved into the documentation?

Hi, for Meteor applications you are using a standalone express server that is ruinning on port 4000. How secure is this to deploy to the live app? What if the app crashes? I have several deployments on Galaxy, thinking of using GraphQl, but that express server scares me a bit. Will it be detected by Meteor app and crash as well? This way Galaxy would start a new instance with no issues. Thanks for any advice.

test issue

After toying with the Express-GraphQL file upload demo, I have been thinking about how to bring file uploads inside GraphQL mutations to Apollo.

Here is the rundown of what I've learned and the best solution I have formulated:

• Canonical file uploads happen via a mutipart/form-data POST request, whereas Apollo Client interfaces with the Server exclusively with application/json requests at present.

• There are other ways to transmit a file from browser to server, but they are often flimsy and poor solutions.

• The ideal solution delivers both a GraphQL mutation and the uploaded file(s) to the server in such a way that the schema resolvers have access to the files, such that custom logic can test, modify, and/or store the uploads. The best way to ensure both mutation string and file(s) reach the server at the same time is to merge them into the same request.

• Thus, I think that Apollo Client needs to either

  • gain a new method, e.g. mutateWithFiles( "gqlQueryString", { apolloOptions }, [ files ] ) or
  • include a new option, e.g. uploadFiles : [ ... ]

  which, when used, sends a multipart/form-data POST to the specified Apollo Server endpoint. The request would be identical to the normal request apart from the inclusion of a new files field or similar which contains the uploading files. I think I would lean towards the clarity of a new method on account of readability.

• Apollo Server will then need to check each request for its content-type; if it is application/json, then no upload-specific logic happens and the mutation continues as usual. If, however, the POST is of content-type multipart/form-data, the server will append the files in memory to the root query object. The mutation then continues as usual.

  • This way, the files are available to the resolvers via the first root argument and subsequently to connectors if need-be.

Please chime in if you have any thoughts. I'd especially like for members of the Apollo team to offer their opinions. If we get to a design that satisfies the dev team, I am happy to work alongside any other interested parties to create a PR!

http://www.apollostack.com/

Could you please restore it?

Greetings,

I am just starting out with Apollostack and I have a generic question regarding data and api calls.
Would it be possible to somehow get analytics data using google analytics api ?
If this is already answered or there is already documentation could you please point me in the right direction.

Thank you.

Hey all,

in our web app we need to use multiple graphql servers. Is there a documented way on doing this? Is it allowed to have multiple "nested" apollo providers without overriding the wrapping provider/s?

Thanks,

Michael

I know apollo-tools support merge multiple graphql files, but can I go further to split one type across multiple files, especially for the root schema like below?

# author.js
export default [`
type Author {
   id: ID!
   name: String!
}
type Query {
  authors: [Author]
}
`]

# book.js
export default [`
type Book {
   id: ID!
   name: String!
}

type Query {
  books: [Book]
}
`]

// schema.js
import authorSchema from './author'
import bookSchema from './book'
const rootSchema = [`
schema {
  query: Query
}
`]
export const schema = [...bookSchema, ...authSchema, ...rootSchema] 
/*
I am expecting to have 
type Query {
    books: [Book]
    authors: [Author]
}
*/

Notify that the email address was accepted/rejected after the user submits email address.

Spec: https://facebook.github.io/graphql/#sec-Language.Variables
More info: https://medium.com/the-graphqlhub/graphql-tour-variables-58c6abd10f56

Hi,

I'm really looking at how the client of this will work? What's are the plans?
For the reactive part, I suggest to use something like Rx.js instead making it Tracker based.

And distribute it via NPM. Not sure whether Lokka fits into this or now. But I like to discuss.
May be we can share some ideas.

It's annoying that you need a specific babel plugin to compile Relay.QL template strings at build time. Specifically, you need to:

1. Compile your server
2. Run the introspection query and save the result to a file
3. Pass that result into a Babel 6 plugin to compile your client code
4. Run your client

This has several unfortunate consequences, in particular:

1. You absolutely need to use Babel 6
2. You can't easily develop the client and server in parallel (if one person is working on both) because of the multitude of compilation steps above
3. You can't easily play around with queries in the browser console

It's pretty easy to run the parser at runtime in development mode, and this will make it much easier to work around the drawbacks above.

I should publish this as an NPM package so that you can use Relay.QL just like you would use any template string.

I just wonder, what if: we have some front-end components, which composes a relatively big query, then Relay merge it together and send to GraphQL endpoint, it resolves part of the query fast, and then one of resolvers trying to get some REST and get timeout on it. Will the entire query timeout? Can we avoid such a situation and send answers partially? Or it is already done?

can i split my schema into more than one file.. and then import. something like...

eventSchema.js

const eventSchema = `
    type Event {
      _id: String
      title: String
      subtitle: String
      description: String
      region: String
    }

    type QueryEvent {
      allEvents: [Event]  
      event(id: String, title: String): Event

    }
    schema {
      query: QueryEvent
    }
`;

export default () => [eventSchema];

index.js

import eventSchema from './eventSchema';

export default {
    eventSchema
};

I'm sorry about all these questions I have, but hopefully, as whole they will improve the documentation part as the technical part is really awesome ;)

With the announcement of Meteor 1.5 and the promise of use of Node 4 and soon after Node 6, possibly we will see the direct use of ES6 without transpilation in Meteor applications (ast least on the dev side). I proposed this on Meteor forum and had quite a strong positive reaction from the community. No-transpilation will improve dev's life in so many ways.

As a result, my question is: How can I work with Apollo without the async/await? I am not great with "Promises" so I failed to create a working example with pure ES6 Promises.

Having a working example would really help already as it is not possible to write Apollo code in Typescript as async/await operators are transpiled to some "_asyncAwaiter" crap from Typescript that breaks the functionality as reported here apollographql/apollo-client#216.

The async/await currently appears in two parts:

1. Resolvers
2. In Meteor code, when grabbing a Meteor user and feeding it into context

Thanks.

Currently only the bold text is clickable for footer links to Slack, Medium, etc, making it hard to land on the actual link. We should expand the clickable area so visitors don't have to be so precise.

Is there an example of a GraphQL schema that the Meteor Data project will support? E.g. a simple example in the documentation would help clarify the expected use.

One thing I really miss in DDP is backpressure support. So that the way client could say back to the server: please slow down, I cannot process changes as quickly as you are sending them. Or even, please batch them together. I do not need every change, you can aggregate changes over the same field together and send them every X seconds.

I think this is one thing node.js learned a lot with their multiple iterations of streams. And how they were adding backpressure to them.

A good talk about one similar project with backpressure is this one: http://www.infoq.com/presentations/streaming-data-back-pressure

@stubailo we've been working on a GQL server for our meteor apps and are pretty close to launching. We are now starting the reactive query layer as you described in the transmission episode and are going to be supporting MongoDB, MySQL, MSSQL (and webhooks for reactive apis) as they fit our current stack ,and using redis as a caching mechanism.

Do you have any thoughts on if / how the actual queries would be adjusted using what you are working on and if there are any reserved arguments (like reactive: bool) that we can go ahead an implement around so we can be useful in prototyping alongside you guys?

We currently write our sql queries in .sql files and use node to parse and inject variables that way we can have meaningful git history and pretty much copy/paste into our db query tooling for quick iteration. I don't know if this would be seen as an anti-pattern or not. Just wanted to mention it.

Our biggest boon to the reactive work (a lot of our currently supported mappings don't have to be reactive) is for cache breaking. Luckily I think they work hand in hand. In all honesty, we are roughing out having the caching layer (default to redis with in memory / file backup) to be what powers the reactivity on queries as well. So the db change would actually invalidate the cache which would update the queries. This may be the wrong direction?

Looking forward to your thoughts!

In my app, I want to render certain elements as floating portals over the rest of the app. As there are places where I use overflow: hidden, I need to render the windows out of the main DOM tree. My current solution for this is for those elements that represent windows, render 'null', but update another react root with the children, so it can update it's dom tree and render the windows.

My problem is that I want to connect that extra DOM tree to my apollo store, so I can share data, but when I do this I get

 TypeError: Cannot set property 'middleware' of undefinedApolloClient 
@ index.js:72(anonymous function) 
@ ReactCompositeComponent.js:305measureLifeCyclePerf 
@ ReactCompositeComponent.js:74_constructComponentWithoutOwner 
@ ReactCompositeComponent.js:304_constructComponent 
@ ReactCompositeComponent.js:279mountComponent 
@ ReactCompositeComponent.js:187mountComponent 
@ ReactReconciler.js:47performInitialMount 
@ ReactCompositeComponent.js:370mountComponent 
@ ReactCompositeComponent.js:257mountComponent 
@ ReactReconciler.js:47mountComponentIntoNode 
@ ReactMount.js:105perform 
@ Transaction.js:138batchedMountComponentIntoNode 
@ ReactMount.js:127batchedUpdates 
@ ReactDefaultBatchingStrategy.js:61batchedUpdates 
@ ReactUpdates.js:98_renderNewRootComponent 
@ ReactMount.js:321_renderSubtreeIntoContainer 
@ ReactMount.js:402render 
@ ReactMount.js:423render 
@ WindowManager.js:16updateWindows 
@ WindowManager.js:28componentDidMount 
@ Window.js:10(anonymous function) 
@ ReactCompositeComponent.js:264measureLifeCyclePerf 
@ ReactCompositeComponent.js:74(anonymous function) 
@ ReactCompositeComponent.js:263notifyAll 
@ CallbackQueue.js:67close 
@ ReactReconcileTransaction.js:81closeAll 
@ Transaction.js:204perform 
@ Transaction.js:151perform 
@ Transaction.js:138perform 
@ ReactUpdates.js:90flushBatchedUpdates 
@ ReactUpdates.js:173closeAll 
@ Transaction.js:204perform 
@ Transaction.js:151batchedUpdates 
@ ReactDefaultBatchingStrategy.js:63batchedUpdates 
@ ReactUpdates.js:98dispatchEvent 
@ ReactEventListener.js:150

Does this mean it's not possible to use the same client with 2 providers?

Hello guys, noob here. I just learned React and a bit of Node, now I'm looking to get into backend properly. What would be your ultimate learning/reading list for a noob to learn how to make a complete app, top to bottom?

I watched the server tutorial on your youtube channel.

I also made a reddit thread asking the same question.

http://socketcluster.io has a good idea and implementation. Please take a look, may help Apollo designers.

I'm wondering what is the development stage of Invalidation Server mentioned here.
Is someone working on its implementation?
Also how do I push updated data to a client (with Apollo Server)?

Eg give feedback if the email signup input isn't a valid email, or if not all the required fields are filled in for the GraphQL Support request

I think this has a lot of really great developer UX goals in mind, specifically around debugging, optimistic UI, and mutations.

https://github.com/gyzerok/adrenaline

@gyzerok, we're working on a GraphQL and Relay-based system, you can check out some info here:

• Read the blog post about our goals for the project.
• Read about the high-level design of the system.

Curious what you think about our ideas!

Also, of note is that you decided to implement a new store rather than using the Relay one - I wonder what the tradeoffs were there.

Dear, I am receiving a weird schema error on following schema:

type NotificationParameter {
    scheduleName: String,
    practicalName: String,
    exerciseName: String,
    rank: Int,
    count: Int,
    mark: Float
  }

  type Notification {
    _id: String,
    userId: String,
    code: String,
    date: String,
    parameters: [NotificationParameter]
  }

  type RootQuery {
    notifications: [Notification]
  }

  schema {
    query: RootQuery
  }

I'm getting: Resolve function missing for \"Notification.parameters\"

When I use a simple String type in:

  type Notification {
    parameters: [String]
  }

the error disappears.

I believe an essentially correct counterantidisintermediationist solution has been found to transport agnosticism on the issue @mitar raised. #17

Deps would then be named merkle-links. JSON++ graphs of merkle-links form a DAG suited to dependency management and version control iff there are no SHA collisions.

Mutations fully determined on the client or server need only inform the server or client of the multihash. End-to-end, p2p.

With lexing and parsing and marshalling done by the IPFS ecosystem we can dispense with most of GraphQL except for GraphiQL and all the server specific code.

Probably something like this was the right way to build the entire file structure in POSIX the whole time.

Maybe I'm wrong? (I've almost definitely got some of the terminology from IPFS wrong, but that's another issue)

Can anyone pop the @MasterJames big ideas bubble?

https://github.com/ipfs/specs/tree/master/ipld
https://github.com/ipfs/js-ipld

This is an issue thread just to test commenting via GitHub's GraphQL API. Try to post a comment or add a reaction to an existing comment!

If GraphQL schema may replace the pub/sub approach to template data handling, what will security look like? E.g. some publications perform security checks before returning data to the client. How will this be done with a GraphQL schema?

Further help would be including in docs at launch a list of the other major libs and what the differences are.

Great idea! As a good side-effect, this will force us to really understand those other libraries.
apollographql/apollo-client#7 (comment)

When I tried to get my React friend to use Apollo for data, they were like, "Why not use Relay?". It will often be the first thing React devs think when they see Apollo. So I think it would be good to say why here http://docs.apollostack.com/ and maybe here http://apollostack.com/. While the design doc https://github.com/apollostack/apollo-client/blob/master/design.md mentions Relay, I think it would be nicer to have something shorter that you can put up front, like "Simpler to use than Relay, plus reactive, etc" or something.

Similarly, you could say why server better than GraphQL-JS / express-graphql here: http://docs.apollostack.com/apollo-server/index.html

Related: apollographql/apollo-server#2

So what do I mean by a large GraphQL server? -

• It has many many connectors 5+ (Mongo, Redis, MySQL, Postgres, .... etc... and counting)
• Many models and schemas, (which has duplicate definitions)
• and many duplicate resolvers.

So I just want to get opinions, on how someone would structure their code to reduce duplication.

Thanks!!

Steps to reproduce:

1. Open apollostack.com
2. Click Sign up for email updates
3. Enter a valid email address
4. Open developer tools
5. Press SIGN UP

ReferenceError: event is not defined
<anonymous>
 main.js:18
n.event.dispatch()
 jquery.min.js:3
n.event.add/r.handle()
 jquery.min.js:3

FF 46.0.1 on Ubuntu

Sorry, I couldn't help myself

Noticed a few people are knocking on your slack door but there's a limit on the amount of users that can join. Any chance you can change that?

http://puu.sh/opabL/7de89908d7.png

Recently stumbled over DGraph. Seems to become an interesting match for the "application server" (or at least the lower layers) as it natively supports GraphQL.

http://dgraph.io/
https://github.com/dgraph-io/dgraph

I am not familiar enough with the Apollo Stack yet, but would you think it matches and that it could be done?

Hello

Having gained some knowledge about apollo and graphql, I am thinking about restructuring my main application.
I want to make it more modular, so that I can hopefully reuse some modules in the other apps.
I use koa2 for the server with react, react-router, redux and both apollo client and server. I believe that this is my stack for the future :)

Anyway, this is my folder structure ATM:

client
  apollo
  components
  container
  i18n
  reducers
  routes
  store
  stories
  styles
  index.js
server
  db
  graphql
    connectors
    resolvers
    schema
  models
  utils
  server.js

I am thinking about extracting parts of my code into these reusable modules that would export everything required for both client and server. Components and routes, redux actions and reducers, graphql connectors, resolvers and schemas, translations, utility functions ... I'm calling them space ducks :P

Anyway, here's the rought space duck export structure:

module_name

  // client

  components   // export react components
  actions      // redux actions
  reducer      // redux reducer
  routes       // route definitions

  // server

  models       // sequelize in this case 
  connectors   // dataloader someday
  resolvers    // graphql resolvers
  schema       // graphql schema

  // common

  utils        // random functions
  i18n         // translations

What do you think?

I am not sure if it is OK to put client and server code together like this.

Would love to get some feedback on this.

Lots of questions on cached local data...

Will Meteor Data (GraphQL [+ Relay?] based) replace or complement minimongo? if it replaces, can Relay provide the capability to query and manipulate cached data similarly to minimongo? Including the capability to use local only "collections"? If so, will GraphQL also have the capability to query and mutate local "collections"? These capabilities are quite commonly used now...

I haven't seen much discussion around pre-loading data and client-side caching. Pre-loading data in the background can increase the speed of the UI massively - cutting out all server latency. I could create hints to tell the system what queries are likely to come next. I might specify what views are connected to this one. More advanced would be to let the system learn from user patterns to load data optimistically, finding a happy balance between UI performance and server requests.

Client-side caching is sort of the opposite, where I'm not re-fetching data just because my route has changed. Of course, I should be able to set up rules around this, like cache invalidation time, and manually trigger data refreshes.

I would argue that pre-loading/client-side caching is important for almost all apps, with reactivity somewhat less so. Asana also changed some of their focus around this with their Luna framework: https://blog.asana.com/2015/05/the-evolution-of-asanas-luna-framework/

Probably for maximum compatibility it would be great if data layer would be build on top of node.js streams. Then one can simply use any node.js stream as a transport layer. This could build into many community efforts to port node.js on top of websockets, webrtc, IoT protocols and so on.