Just like you after Blaze was deprecated I switched to webpack:webpack in order to use Vue. It is a great combo, and I am still enjoying Meteor features.
We’re also very happy when people do this - at the end of the day, the main benefit of releasing a technology in this decoupled way is that more people can try it out, report bugs and contribute without having to buy into all of Meteor.
I hope eventually more parts of Meteor can be independent in this way, because then each part will become a great technology in its own right.
The real trick is, we are working hard on a way to monetize Apollo and GraphQL usage so that we can still deliver services like Galaxy to people who are using only that part of the platform.
5 Likes
Absolutely agree. A commercially viable mdg pumping out excellent foss is exactly what we need.
5 Likes
I would gladly pay $5 per month to have a framework that was reliable, did 80% of whtat I needed, moved with the times and provided string career advancement.
Developers have come to expect things for free - it’s just not going to work. Free = commercially non-viable = abandonware.
2 Likes
Having great database support in 1.5 is going to be huge for dev shops/freelancers. No longer do you have to turn away customers if full-time reactivity and Mongo are not a good fit. Also no need to use multiple stacks.
@sashko will 1.5 provide a pre-setup Apollo and basic redux config? Or even a boilerplate example app flag with a hello world would be great 
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)
7 Likes
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!
4 Likes
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: []
});
1 Like
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.
Have a look here. It’s a bit old but still useful and works Meteor CI CD
Above is a non-docker version. I’m currently working to make builds using Docker container.
1 Like
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!
8 Likes
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.
1 Like
You mean “achieve”, right ?
Scaphold hits a sweetspot MDG could explore around
(There are other great offerings around the react space - I’m not promoting)
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!
Hi @dinos, I’m agree, but rethinkdb is shutdown and horizon.io will to…what’s your opinion ? I hope meteor will not face the same problem in Future…
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