My personal experience with Meteor and it’s growing pains…
I used Meteor for 18 months to develop a product, but I then switched to webpack / react after blaze was essentially deprecated. At that time (1.3x), meteor build times were horrible, so switching to webpack was a blessing, my productivity and enjoyment returned. Since that point, build times have not improved so I’ve not developed on Meteor since, I won’t until it is npm compatible (so that I can continue using webpack).
I do feel this is most important at this point. I can understand why Apollo is attractive (taking the best of Relay / GraphQL and extending Redux) but it’s not going to bring me back to Meteor anytime soon. Especially when I can use Apollo without Meteor.
Despite the present growing pain, I do feel Meteor is evolving into a better framework release by release. Once the above are both resolved it’s future will look a lot more positive.
npm integration will make Meteor accessible to more developers as well as fix build and integration issues, which are both important. But it doesn’t change Meteor’s feature set or power.
GraphQL/Apollo integration is going to fundamentally make Meteor more powerful - no more dependence on Mongo, DDP may be deprecated in favor of something better, freedom to choose any DB/GraphQL backend, and better scalabilty/compliance with emerging standards are huge wins.
Right now Meteor is very opinionated and prescriptive - these are both its biggest strengths and weaknesses. We need a finer balance of integrating with the JS community while still preserving the ease of use, power and completeness that makes Meteor unique.
completely agree, and I think that solidifies the argument for doing apollo first. While NPM brings access, it’s apollo that will actually give the community flexibility and ease the ‘lock-in’.
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.
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.
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)
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.
Absolutely agree. A commercially viable mdg pumping out excellent foss is exactly what we need.
and complete NPM integration so the load on your devs is reduced.