We’re not yet sure exactly what integration will be most valuable! It’s already possible to use Apollo Client alongside Minimongo in your frontend, so we just need to come up with ways to make that feel more natural.
One thing for sure is that we’ll make it a bit easier to set up a GraphQL server on top of your Meteor MongoDB database (so that you can easily migrate parts of your frontend to Apollo as you feel like it).
Other options include:
Better accounts integration
Livequery integration so that you can opt-in to some reactivity where you need it
A starter boilerplate, perhaps with Redux?
There’s also the question of how many people would want to use Apollo with Blaze, in which case we need some integration there as well, ideally community driven (as the react/angular libraries are)
I for one would really love to know what ideas you’re looking at here. We’re currently integrating data from MongoDB, MySQL, MSSQL, SAP HANA, Redis and REST in our app. Our trials with Apollo look like making this a no-brainer, but some hints as to what this might look like in Meteor would be awesome!
Hmm interesting! Yeah I agree that it’s pretty easy to get Apollo working today as is. However, I think the secret sauce Meteor provides is a seamless/frictionless experience. Great to hear those are on the table!
I’m also creating a boilerplate as well for tinkering (and for an upcoming Apollo video):
It’ll prob. use the simple-react-react module to make it a bit cleaner to use redux (though maybe not if it redux/react-router has more breaking changes lol):
import {registerRedux} from 'simple-react-redux'
export const {dispatch, store} = registerRedux({
routes: require('./routes'), // optional if using react-router
renderToElementId: 'react-root',
reducers: {
app: require('./reducers/app'),
posts: require('./reducers/posts'),
},
middleware: []
});
I’m on Meteor 1.2.2 and use mup to deploy to an EC2 instance. When I upgrade to 1.3.5.1 and use mup, the setup passes but the deployment fails. I haven’t tried mup, but here that devs are having issues using that when moving to 1.3.
I haven’t tried mupx, but the only success I’ve had was using vanilla docker 1.2 for mac and following these instructions.
Now I’m trying to learn about docker and deploying that to an EC2 instance – but this is a real pain and I’m not sure this is the right route for me yet.
It was so simple when everyone was using mup, and it just worked.
I’ve opened threads about this, but no one seems to have the answers (or is talking) when it comes to deployment.
All this has side tracked my upgrade efforts to 1.3 and my migration to React/Apollo. I hope the community can get the upgrade path and deployment story straight in this new NPM/Apollo era.
Galaxy is too expensive for my needs at this time. So what does a guy have to do in order migrate to React/Apollo?
I’d suggest getting together with some other people who have deployment issues on 1.3 and figuring out how to make mup work, or building a new tool. I’ve seen some other deployment tools floating around here, perhaps mup is just not the best choice anymore if it’s falling out of maintenance.
Have you tried doing something more manual using meteor build? If you are just deploying one server, it shouldn’t really be hard to just upload a Node app bundle and run it.
This is what I’ve done so far with meteor build. I know it works because I can create a Docker image using this build and it runs. But Docker seems like extra overhead to my deployment story.
And after posting this, I didn’t really get a answer that helped. I’m willing to start on a brand new EC2 instance, and I can get a meteor build over there, but I don’t know how to set up the environment manually.
Out of curiosity, how can you monetize Apollo? A platform like Meteor, I get, you provide best-in-class hosting. But a ‘middleware’ between app and db?
Also, shouldn’t this be something that management has already figured out before they embarked on this? (Services can bring some money in, but it’s not easily scalable).
I am really not trying to be hasty, just thinking and brainstorming so MDG can continue to thrive.
Open source is all about shipping cool stuff as soon as possible and collaborating openly. The business side is not usually as open, it’s important to have the right timing, pricing, product fit, marketing, sales, and support for paid products. We’re putting a lot of thought into this whole Apollo thing, so we want to make sure we build and launch things right!
If you think about it, you can imagine a lot of ways to monetize a data layer:
Software that gives you insights into what’s happening with your data - this is what we’re actually doing first, and you’ll see some demos of it soon
Services that provide performance and security optimizations specific to this data layer, including caching, rate limiting/DoS protection, and more
High-performance reactive distributed data via hosted services that are hard to operate yourself
Easier integrations with various enterprise backends that require lots of maintenance and specific machinery (think automatic Salesforce integration)
These are just the ones anyone could come up with off the top of their head.
I’m confident that having a more specific focus on the data aspect of things, and making that a next-generation experience that’s available to the widest possible audience of developers, will bring lots of opportunities to build really exciting commercial services that will help us keep the lights on and grow the company and the community!
Very nice! So essentially running value-add services and tools around the data itself, and no longer (just) the platform. I think (1),(2) and (4) are probably the low-hanging fruits.
(3) scaled reactive data is likely, from the meteor experience with reactivity, focused on high volume niche players, who may themselves have internal expertise and devs, so I don’t (at first glance) expect much there.
Take away: Have the community take over as much as possible from Meteor ASAP and complete NPM integration so the load on your devs is reduced.
Yeah, Scaphold is great as a backend as a service. But we’re not looking to get into that industry, I’m sure they will do a great job with it. We’re working with them on a lot of Apollo/GraphQL stuff already!
will mongo be removed so everything related to db is up to apollo? right now I have a major issue with mongo being the default db, I need to connect to dynamo db
RethinkDB died because they made the move to monetize and experiment with different monetization strategies too late.
MDG is not making that same mistake, as far as I can tell. Hence why they’re not interested in relying on Meteor and Galaxy as their sole provider of income. They’re building Apollo and Optics.
And eventually they’ll build other services. The more income streams they’ve got coming in, the better off they are (especially in their industry).
Right now, we’re focusing on things that Meteor developers have asked for, especially performance and better community involvement. That’s come at the cost of being able to spend a lot of time on better Apollo integration, but we’re happily using the two together in both of our commercial products so using Meteor + Apollo is pretty great already.
The biggest problem as I see for meteor right now is stagnation of it’s ecosystem. I think from business perspective it’s very important to finish this transition asap so people would know exactly how to create packages and plugins (apolo, npm, react I guess, or maybe something different) and how it all works in a coherent whole.
Have you ran into many issues with users of Meteor upgrading to 1.4 with Apollo? I had a horrible time trying to get Apollo to not throw errors and with 5 npm packages and the Meteor apollo package it’s really hard to tell where to even start debugging. Also does 1.5 integration look more like a 1 line package install? Currently using Apollo outside of Meteor seems to be a lot easier than using both.
and complete NPM integration so the load on your devs is reduced.