Apollo + React is an awesome technical stack. I have experienced it with my personal project and recognized that:
1, Define graphql schema takes more time in comparison with publishing data then query
2. I have decided to use JWT to authenticate devices including Mobile, Web. However, there is no related library
Any suggestions?
If you’ve been working in meteor for years and just started with apollo + react, you will probably move slower. But isn’t that true any time you use something new? It doesn’t seem like it would slow you down once you get in the groove.
Can confirm. Coming from PHP + MySQL.
Meteor ruined my brain. Taken a LONG time to figure this out.
Every new tech you add to your stack will make the development process “slower”, but you are adding them for a good reason, right? Just don’t throw any hype lib you saw in the JS community, have a good notion on how it will be helpful, then the slow down will be paid off.
About JWT I didn’t understood, have looked for “jwt” at npmjs.org or atmospherejs.com?
I can tell you this from my current experience: I’m currently refactoring an app that hasn’t been touched in a long time, I suggested to port over to components since we have time but our product guy insisted to not do it. I’m now writing Blaze code with jQuery plugins and Materialize and the developer experience is the worst I have had in three years.
Everyone complains about JS fatigue, the truth is all of these convenient features new fancy libraries give us exist for a reason. My experience compared to Polymer+Redux+Apollo (same class based syntax, almost identical) is so much worse with Meteor’s “old” stack.
Yes, I could be my problem when learning new framework
it’s human problem not a you problem 
Broadly, React, Apollo, and so many other newer tools give you more control over your app than you had before, at the expense of having to make more decisions. This can cause fatigue!
I think these tools do slow me down at the early part of the project, and speed things up near the end of a project, as they make everything much easier to understand and reason about. Using these tools means I have to do more planning, and often more refactoring if I don’t plan to make sure I’m keeping my components clean and reusable. In a team I could do even more with PropTypes, but I usually work solo. The time it saves me vs a Blaze app in the end (shipping) phase depends on how complex the project is. If the project is relatively simple, like a form or page paradigm, I still use Blaze. But if the project is a complex interface with a lot of moving parts, React is the way to go. This is another way to say that React scales better with app complexity.
Agreed with @captainn. React, ES6, etc. are more verbose, yet also more deterministic. Harder to set things up; but easier to cross the finish line.
That’s exactly the pain that Vulcan is trying to solve, actually. All the power of React/GraphQL with the ease of use of “classic” Meteor. You might want to give it a try?
I know what it is. I asked if you have looked for “jwt” keyword at NPM or Atmosphere because there are plenty of libraries to work with it. My personal favorite is from Auth0.
Don’t know you guys, but for me, personally, Meteor’s killer feature is its awesome real-time capabilities and unfortunately I didn’t found (yet) any satisfiable way of using Apollo/GraphQL with it. I’m watching @sashko’s graphql-subscriptions-place to see what is coming.
Also I took a look at Vulcan, but didn’t found by my own any subscriptions over websockets going there, it seams that updates comes from a 20s interval pooling strategy. Can you confirm, @sacha, please?
Even Apollo and Meteor coming from the same group, it is hard to find examples, guides or documentation of they working together in this real-time context (IMHO what makes Meteor: Meteor!
Since real-time is to me the main feature to choose Meteor over other stacks, I’m not adding GraphQL/Apollo to my comercial apps yet, but I’m trying something in the free time.
I think it’s true that if you need a fully realtime app then Meteor is a good choice for that and Apollo doesn’t currently help much.
Yes, Vulcan doesn’t currently handle Apollo subscriptions. It’s on the roadmap though! But like @sashko said, if real-time is the most important feature for you then Meteor is hard to beat.
We’ve been waiting on subscriptions to be fully baked, even if they’re just polling. Any thoughts on the status of getting subscriptions, paginations, etc up to par with ddp/livedata?
That’s not currently a top priority, but it does seem to me that the majority of reactivity use cases can be covered with a combination of polling and message-based subscriptions.
One thing for me is that is I am still not really able to figure out if and how I can integrate Apollo and React in my current Meteor application. I can see some very clear benefits for both, but I am struggling to find resources on this. Surely I am not the only one thinking about this?
There isn’t really much to it - you can just read the Apollo docs and use it as normal. On the server, you call MongoDB collections from the resolvers. There’s also a Meteor integration package that helps handling stuff like login.