I disagree, this is a logic flaw, called academicism. Arguing that an opinion’s truth value is correlated to whom propose such an idea is a flaw.
In synthesis, success is not made by people, but by ideas.
I think MDG is making some management mistakes, as I think the management is under a lot of stress due to some past mistakes.
Maybe this is not one of them, I prefer not to express an opinion on Blaze and Apollo, as I think that the situation is more complex than how it looks at first. Anyhow it’s interesting to notice that:
They said they would drop blaze support in favor of react / angular.
This has been a breach of trust between MDG and the community
They went back on their steps after the community pressured against the decision. Anyhow the trust was already lost, and I didn’t believe it.
Now in a critical decision Blaze has been left behind. Not abandoned, ok, but it’s being treated as a second class citizen.
Again I don’t want to say that not supporting blaze in apollo is bad, but I think that there are some problem in the management group behind MDG.
In all seriousness though, you bring up interesting points @muaddib. My comments though about not worrying based on their impressive VC list comes from my dealings with related companies. These guys have plans. They aren’t just impressed by demo’s, and they bet on both people and ideas. They also hand hold, guide and help find solutions for a lot more than they usually get credit for. The power of a good VC (and these guys are top notch) isn’t just their bankbook. It’s their network. When problems arise with a startup they’re sponsoring, these guys not only dive in to help out, but they bring in the expertise of other successful founders they’ve worked with. This is all of course to their own benefit, but hey - we’re benefiting too!
(EDIT: Sorry, I just realized that I’m totally derailing this thread - it must Friday!)
I agree with both your posts strongly. Having good VCs make a hellava difference. In this case, a technical platform needs top notch VC’s / advisors / board. My concerns as a developer using this technology are well articulated by @muaddib and no great VC is going to take this away, as it has to do with the platform’s vision and direction.
I am extremely comforted that the community is stepping in … but we need more people (myself included) to take a more active role. It’s in everyone’s best interest. Adam Smith’s ‘invisible hand’ will kick in and direct the platform to a point where it satisfies most stakeholders. That may or may not include MDG on the long run, which in itself comforts developers and brings them on board.
We could foresee a time where we set up a foundation (which we could invest in and help manage) and hire in (including the key devs @ MDG – everything is on the table).
As, considering the blaze-to-apollo news, blaze is obviously already an afterthought for them-- maybe MDG can play a more active role (both organizing and financing) this “organization/foundation” in the near term.
Even if they just help set up the structure, recruit the first few people, setup the patreon (or other) account, and donate the first thousand bucks… they could start by handing over the blaze library.
They could put one person on this task FT and have it set up in under a week if they really wanted to do it. Then that person can go back to whatever they were doing before.
It’s really not that much work. Two days picking the initial team. One day on setting up the organization (doesn’t even have to be formal I guess), a day setting up patreon. Boom. You’re done.
@sashko, is this something you can help us organise? If so, we could set up a call. The foundation could even help offset MDG’s costs and investment. Features can be financed and developed based on community needs, while you guys focus on what is core and essential for your near term. The foundation could also be an asset for MDG, as a direct arm into the community.
We’re putting in a lot of work, especially in the last few months, to empower meteor contributors and community, and we would certainly appreciate more help! That’s something @zol spends a lot of time thinking about.
Blaze will work just fine with Apollo. The current React bindings for Apollo were built and are being maintained by the community, I really hope someone will step up and do the same for Blaze!
Well, in fact, the reason for my question is that I’m starting a new project and I would like to use it in production, but I’d need it really soon, like in a next 2-3 weeks (for a pilot phase).
If you think it’s possible to do a usable version within said time frame, than I’d be willing to take that responsibility and would appreciate if you could help me out.
I think so - most of the complex stuff is inside the Apollo Client core, and the react/angular integrations are relatively thin. In fact, we’re actively trying to move more in this direction so that the integration layers are as small as possible.
I think you could get really far in 2-5 hours. The hard parts are (1) designing it to feel great to Blaze users, and (2) maintenance, bug fixes, and keeping up with new versions of Apollo Client.
How can we start? Perhaps I should create a repository for it, then we can discuss a design. Have you used Apollo or GraphQL before with React or Angular?
Please, anyone doing this integration, put much time and focus on this. I like this approach, but if this doesn’t work somehow, please have a smart interface, one that fits in with its current constructs.
I won’t be of any use, as I don’t know a thing about Apollo or what the calls would look like. But if you don’t mind, I wouldn’t be shy about discussing how we should be thinking about this.
Very rough and simple example (please provide a better one if you like):
But typically I have a subscription in the onCreated:
var instance = this;
var reactiveVar = Session.get('reactiveVar');
var sub = instance.subscribe("persons", reactiveVar);
if (sub.ready()) {
// do something
}
Then in my helpers:
return persons: function () {
var cursor = persons.find();
return cursor;
},
or sometimes I’ll just get one value from the record (in helpers):
return fullName: function () {
var person = persons.findOne(userId: Meteor.userId());
return person && person.fullName;
},
Then in the template:
<div>
{{#with persons}}
<p>Authored by {{fullName}}</p>
{{/with}}
</div>
<!-- or just the value -->
<div>
<p>Authored by {{fullName}}</p>
</div>
According to your example we’d had something like the following:
{
person (id: "5") {
title,
first,
last,
address {
street,
...
}
}
}
I don’t know where something like this query would live.
GraphQL lets us embody this idea much more directly. So instead of:
Meteor.subscribe('x');
x = X.find({ x: true });
You get to do:
x = client.query(`
x {
field1
field2
}
`)
This gives you a lot of great benefits:
No collisions between multiple subscriptions
Only get the fields you ask for
No need to ensure you are subscribed to data ahead of time, just ask for what you need and it shows up
None of the code snippets you posted are surprising - that’s exactly what we recommend in the Guide as well, and I think the best we can do is carry those recommendations over, and add some stuff that takes advantage of GraphQL’s unique features too.
- any news on Apollo/Blaze front?