In my limited spare time, I’m creating something based on the grapher boilerplate. Should I just keep on going, and then migrate when your Apollo boilerplate is released? Or would it be better to pause, and wait for it?
I recommend you go with Apollo.
@diaconutheodor where should I go to see an example of logging into meteor from React Native using your packages? Before I was using react-native-meteor so that I could gain access to the Account functions client side inside of react-native-meteor’s createContainer() in my react native app. How would I gain access to those functions? Thanks so much for all of the work you guys are doing!
Yes, it’s all in the documentation, if you have any questions ask, or feel free to improve it.
How interesting is Live queries for Vulcan.js?
Is it something you think would happen?
Live queries? What do you mean?
I mean in terms of Apollo subscriptions and real time:
Maybe, if we end up using CoC’s Apollo integration. Although real-time and subscriptions are not a priority for Vulcan right now, I feel like if that’s what you need Meteor’s own support for real time is already pretty good.
1 Like
@sacha @stig Apollo Live is completely decoupled from our intergration, you can use it in vulcan, and if you respect the interfaces you can also use it in any pure npm apollo server. But it’s made to work easy with Meteor.
Great!. Thanks for letting me know.
@diaconutheodor is there a way to change the fetchPolicy for the Query in the <ReactiveQuery> component? I find that if I have fetched the query already and then close the subscription (navigate away from the page) and anything is changed while I am gone and then I come back the initial load will pull from the cache and be out of sync. I think that would be fixed just by changing the fetchPolicy to “cache-and-network” but I looked at the component and it looks like you’re only passing the query and variables to the <Query> component. Thanks! 
BTW Meteor + Apollo with Subscriptions + React Native = 
! Thanks for all your hard work!
1 Like
Can you please create a feature request on GitHub?
@yellowspaceboots sorry for the delay. It’s done. Just specify fetchPolicy as a prop to ReactiveQuery.
Released 0.7.1
- Fully supported Upload capabilities, with zero-config.
- Full SSR support (with React) that works out of the box with authentication flawlessly
6 Likes
How are things progressing with the extensive boilerplate?
1 Like
Sorry for my absence lately. I’ve been working on a secret project that our company already started rolling out. It’s a tool that helps you build Apollo/GraphQL/React apps extremely fast.
The problem of extensive boilerplate is just a matter of running a command and you get asked questions about how should we structure the app.
But the real problems are not related to the technology, but rather, do we want to share it ? The company (Cult of Coders) invested a lot in this, and open-sourcing it, would provide competitors the same advantage.
So there’s a moral battle going on, between “knowledge sharing principle” and “business intelligence”. If we find a way to monetise it enough so it fits our goals by open-sourcing it I’m very very open to ideas/suggestions.
8 Likes
Is it related to Meteor, or it’s just Apollo/GraphQL/React?
About the other topic: IMO without open-sourcing it, no-one will know about it ("-Should I hire you? -Yes, we have a super-secret weapon!"). Positioning yourself as the creator of a great tool could bring you customers. Or if you want direct money, you can create non-essential developer tools related to the project like engine for apollo (not required for apollo server/client but nice to have), meteor toys, prisma cloud, etc.
Appreciate your ideas.
It’s built on the shoulders of Meteor. We believe Meteor is amazing in what it does. But no-one will stop you to switch over to webpack for frontend, and because the integration with Meteor is light, if at any point you want to switch to pure Node & webpack, it’s not going to be that huge, you will merely refactor some facades. As long as Meteor stays up to date with LTS Node, we’ll stick with it.
Regarding open-sourcing, I agree there can be revenue streams, but that’s not our goal, our goal is to iterate on the next paradigm of programming (like C was for assembler) when it comes to building web & mobile rich apps. And we do think that ultimately this will be free for all, but we have limited resources currently, and if someone with more resources sees this idea, they can make in 6 months what we could’ve done in 24.
So we either get a big investment so we can start open-source and full-speed ahead, either we slowly build it in house to fit our needs, and when we have enough resources we are going to open-source it.
Meteor itself was a next paradigm of web-programming, it sped up the development time a LOT. It’s open source and nobody “stole” it… but they got investment and created apollo later. I think it’s a chicken or egg question. You have to show that devs are interested in your project to get a big investment but you can’t show it without open sourcing the project. Can you tell me a similar project which is not open-sourced and succeeded? We have tons of options regarding the tech-stack, no-one will even consider something which is not proved AND not open-sourced.
IMHO big companies lack developer-times these days and you always will be the best resource for the project since you’re the author. Just my 20 cents.