Time for a Community-Supported Apollo Support Forum?

The Apollo team is doing a fantastic job of enhancing Apollo. At the same time, there aren’t a lot of options for getting Apollo support yet. Slack isn’t intended for support, so the excellent Apollo Slack channel may not be the appropriate place. Apollo questions on Stack Overflow too often go unanswered.

Since Meteor doesn’t have official Meteor-specific support for Apollo at this time, Apollo questions don’t really seem to fit in here yet. And of course, Apollo is such a big topic in and of itself that it may warrant its own support forum in any case.

Is it time yet for a community-supported Apollo support forum? Just cloning this forum and dedicating it to Apollo may be all that is needed.

Please post thoughts and comments!

1 Like

I’d really like this. Other than the Apollo blog and its comment section, I don’t really know where to go to see what the community is up to.

2 Likes

I just had another really bad experience skilling up on Apollo.

Note: I love Apollo. It provides amazing features. And I finally have queries, mutations and subscriptions working, with the latest Apollo libs. It’s just the support and docs that appear to me to need some improvement.

I had a situation where a subscription was properly returning the newly added object to the component, but when the render function was called, the array of objects to be rendered was missing from props where it is expected to be by the render function. I asked about this on StackOverflow and got no responses. I asked about this on the Apollo Slack and AFAIK got no responses.

After two weeks of spare-time work I found the answer and posted it to my StackOverflow question. The __TYPENAME of the returned object has to be identical to something else – evidently the varname assigned in Apollo UpdateQuery to the array of objects returned by that function. THE APOLLO DOCS DON’T MENTION THIS PROMINENTLY or possibly at all. Check this page out – the text TYPENAME does not appear! You know where else it isn’t mentioned? In the official tutorial referenced by the docs.

Not coordinating with the value of __TYPENAME kills subscriptions, and the docs don’t mention this. Trip over this and you can spend days or weeks trying to find it. Ask about it on Apollo Slack or StackOverflow and you get no guidance back.

Most likely it’s in the docs someplace and I missed it, or I didn’t think of it because I’m not super-experienced in ES6 or something like that.

But I’m not the only one trying to learn Apollo. There are tons of people interested in this fantastic database technology and a lot of them are going to have the same kinds of questions I have had.

@sashko, MDG, I am begging you for the good of Apollo, please improve the situation.

</soapbox> :slight_smile:

1 Like

I would use it but I wonder if it’d be better to keep it here, given there is a lot of traffic here.

My two big gripes:

  • There’s like 6 ways to do a simple CRUD operation and they are not really that straight forward
  • we need a more actively supported accounts system that ties meteor and apollo. There’s an open source package for this, but its fallen on one guy to maintain it (and I’m sure he has better things to do than work on that package at every beckon call from the issues list). MDG should maybe pick this up. You can use meteor account stuff on the client, but then if you make a react-native version of your app, you have to use react-native-meteor. I’d rather have a graphql only implementation of meteor accounts to use on the client… then it can easily be used in your react-native application.