Contributor week ideas

[helfer]

This issue thread is to collect ideas for contributor week projects. 🎉

Contributor week will be from Feb 7 - Feb 14.

Read the kickoff post for more info: https://dev-blog.apollodata.com/apollo-contributor-week-starts-today-39dd139c70ee#.52v38b2nh

[davidyaha]

Two cool ideas for contributors week of whatever:

1. Mutation aggregation for offline first apps (Maybe on the networkInterface level)
2. Service discovery network using GraphQL - at least talk about the idea and what will be a good approach to implement that.

Also from relay - Persisted queries (Sending id’s of queries instead of actual queries)

[stubailo]

For GraphQL tools:

• Adding better schema modularity support and docs
• Mocking based on a remote introspection schema

For codegen:

• Easier dev setup so that any TypeScript developer can easily start getting typing information in their code without having to run build scripts manually

[sheerun]

• something like reselect/dataloader/mobx that is able to combine graphql queries and redux state

[abhiaiyer91]

Client Side

• Apollo Forms
• Input Type Validation for JS Objects e.g. define a graphql input type and validate it against a JS Object.

Documentation

• Living Documentation that updates as our APIs change
• Better Documentation around graphql-tools

Project Structure

• Monorepo managed by lerna @calebmer :)

Community Project

• apollo boilerplate server
• apollo boilerplate per UI

[SachaG]

Devtools

• A new "Errors" tab

[davidyaha]

Remote dev tool for react native 📶

[jakubriedl]

• Immutability implementation for client (maybe immutable.js)
• query test crawler - will get initial query and then crawls through whole graph looking for corrupted data & failing resolvers

[xavxyz]

Meteor integration:

• A codetour of the Atmosphere apollo package to explain & show folks that it's really not that hard to have a Meteor app running with Apollo 🤗

Meteor + Apollo in general:

• A standalone package that enables server-side rendering with Apollo & React Router, including taking care of the Meteor's account login token stored in local storage and sending it via cookies server-side (what fast-render does)

[migueloller]

I'll be doing some work on a GraphQL library very similar to graphql-tools: https://github.com/bloveit/graphql-utilities

See: migueloller/graphql-utilities#12

Maybe we can even work this one out: ardatan/graphql-tools#185

🤗

[bgentry]

ember-apollo-client has a few possible projects:

ApolloClient upgrade

It needs an upgrade to the latest apollo-client. However, that requires some tweaks to how we're doing builds. If you know the ember-cli build system (Broccoli) and/or Webpack, this might be trivial: ember-graphql/ember-apollo-client#10

Pagination

@viniciussbs has been working on Relay-style pagination and might be able to PR some of it, even if it's just examples or docs.

Standalone example app

It doesn't have a standalone demo app like GitHunt, although it has a few good examples in the tests. It should be pretty easy to build a new Ember app in the style of the other GitHunt demo apps by just following what's done in the ember-apollo-client tests + dummy app.

Subscriptions

I still haven't gotten around to doing anything with subscriptions, but I would sure love to see a demo of them if anybody is excited about that.

And of course any others that people can think of would be more than welcome. I can promise to promptly review any PRs 😄 🚀

[Urigo]

copy-pasting from the Apollo Slack Subscriptions channel:

We've released [email protected] and [email protected] with many merged PRs and improvements, please check those out!
This week is going to be Apollo Contributors week and I think the thing we are most lacking of in subscriptions is docs.
So I would love any help I can from the community:

• Update Githunt examples (server, React, Angular)
• Documentation - Just start writing. Then let's discuss here the structure
• Blog posts - write about your experience. we will help you spread that around the community and also can review the posts if you wish
• Tutorials - Written, video, anything goes
• Issues and PRs - There are still some open issues and PRs. take a look and see if there is something you want to tackle. also file issues on anything you think can be better.
• Talks - Now that we have a better solution for GraphQL subscriptions, we should start talking about it. Conferences, Meetups, etc.... If you need help preparing, let me know

Thank you all for pushing another great milestone for Apollo!

[AntonyThorpe]

Any Knockout fans out there? New client library for Apollo just created - link. Has documentation, a demo and an example based upon Learn Apollo. Idea: try to break it (and then let me know, he he). Did I mention that pull requests are most welcome. Thank you.

[stubailo]

I think working on file upload for Apollo Client and GraphQL Server could be great - ideally you'd be able to pass File objects as variables and get them in the server-side resolver! Right now there isn't a clear standard for how to pass files along with GraphQL mutations, so that could be a cool thing to look into. cc @schickling

[HriBB]

Definitely subscriptions and file upload.

[jferrettiboke]

1. File uploads in the client-side and server-side (inside resolvers).
2. More about subscriptions. The documentation is very poor on this.
3. Some hack to write GraphQL syntax for Relay (connections, etc). It would be very nice because we might save time. Something like graphql/graphql-relay-js for GraphQL.js.

[jnwng]

here's a few issues / thoughts / ideas that are (hopefully) easy to get started on - i'm happy to help get people started if these look interesting!

1. Adding support for enforcing / linting against "optional" parts of the GraphQL spec, most specifically to check that GraphQL operations like "query" have names in Apollo (for debuggability) or making sure fragments don't have names in Relay.
2. Here's an easy one for documenting how to retrieve the GraphQL schema from a remote endpoint for use with the eslint-plugin-graphql plugin.
3. For those a little more familiar with eslint (or want to get more familiar), here's an issue to figure out how to get the react/no-unused-proptypes rule to work properly with our beloved graphql HOC
4. If you have a little more GraphQL experience and want to work on a feature, we could use help building a validator for deprecated fields. The work has been done upstream and we just need to integrate those changes!
5. Here's a fun one - the GraphQL spec requires that fragments be unique within a GraphQL document, yet with some of the new additions to graphql-tag we're not properly de-duplicating identical fragments from our documents. this one is a good one to get acclimated to both the graphql-tag repository as well as webpack loaders.

as for some ideas for things that haven't been reported, here's some we brainstormed up the other day:

• having ts/flow support is really awesome - but its currently limited to separate .graphql files, which we don't use. this issue covers what it might look like to just pull the gql definitions right out of the javascript itself
• graphql-config is pretty cool, but doesn't yet have support for apollo (or eslint-plugin-graphql). it'd be really great to be able to use this seamlessly with apollo so you dont have to keep downloading a schema to use the linters.

that's all i have for now, but those are some simple ones to get started with.

[schickling]

👍 for a GraphQL way of file uploads

[Poincare]

There are also a few issues around persisted queries that would be cool to work on:

1. Make it possible to pass tags other than gql with persistgraphql - issue here
2. Make it possible to use any network interface with persisted queries rather than subclass the fetch-based network interface - issue here
3. Add a CLI option to persistgraphql that allows you to merge two persistgraphql outputted files

I'd be happy to answer questions, help out, etc. with these!

[vladinator1000]

File uploads <3

[HriBB]

The biggest problem ATM for me is how to update queries after a mutation or subscription. I think this is far more important than file upload.

[timbrandin]

I biggest problem we have today is to combine client side state (i.e. localstorage, history, redux, navigator, location) with server side state. It would be great if we could remove all mappings that we need to do to combine them in the redux store.

I'm thinking this could maybe be solved with a client side graphql schema, mutations and resolvers.

Wouldn't it be nice to have resolvers that combine client side state such as the url, localstorage and server side in one place?

And instead of this:

const mapStateToProps = ({ wizard }) => ({ wizard });
const mapDispatchToProps = (dispatch, { currentStep = 0 }) => ({
  initStep: (cardCount) => dispatch({
    type: 'WIZARD_INIT_STEP',
    currentStep,
    cardCount,
  }),
});
const mergeProps = (stateProps, dispatchProps, ownProps) => {
  const {
    route: { childRoutes = [] },
    location: { pathname },
  } = ownProps;
  const {
    data: { loading = true, cards = [] } = {},
    wizard,
  } = stateProps;
  const currentStep = childRoutes
    .findIndex(({ path }) => (new RegExp(`${path}$`)).test(pathname));
  // Extract current step state.
  const { wizard: { currentWizard, [currentWizard]: wizard = {} } } = stateProps;
  const { steps: { [currentStep]: stepState = { } } = [] } = wizard;

  if (!loading && stepState.max !== cards.length) {
    initStep(cards.length);
  }

  return ({
    ...stateProps,
    ...dispatchProps,
    ...ownProps,
    currentStep,
    stepState,
  });
};
compose(
  graphql(`
    query getCards {
      cards {
        _id
        name
      }
    }
  `),
  connect(mapStateToProps, mapDispatchToProps, mergeProps)
)(WizardStepComponent);

We could write this:

graphql(gql`
  query getCards {
    $cards: cards {
      _id
      name
    }
  }
  client getStep($route: InputRoute, $location: InputLocation) {
    stepState: wizard(route: $route, location: $location, cards: $cards) {
      current
      max
    }
  }
`)(WizardStepComponent);