I’m looking for a dev to help migrate my site http://leveluptutorials.com off of Meteor. I’ve taken care of large parts of it myself, but don’t have the time available.
I’ve already removed all methods in favor of Apollo server and most front end specific Meteor packges. The majority of the work will be migrating db calls to Node Mongo and writing our auth to not use Meteor Accounts. Please reach out via a dm here or you can email me at scott@leveluptuts.com
I’m curious to hear the reasoning to pull the trigger on this one? (genuinely interested, in a non-judgemental or defensive over Meteor kinda way)
I don’t think it was a quick pull of trigger, he has been planning migrating for more than a year based on this migrating of accounts post.
To migrate account, you’ll need to use npm crypto and bcryptjs to encode/decode the password string. You can use passport JS local strategy and use the following method to compare the supplied password against an existing Meteor account password.
checkPassword: function(inputPassword) {
const userInput = crypto
.Hash('sha256')
.update(inputPassword)
.digest('hex');
return bcrypt.compareSync(userInput, this.services.password.bcrypt);
},
For DB calls you’ll probably need something like mongoose and convert simpleSchme (if you’ve used) to mongoose schema.
With that said, when using something like Meteor you’ve a community of people helping you integrate, upgrade and maintain those tools together instead of maintaining a silos of packages yourself. Also, Meteor really opened up and it’s more of a modern build tool with a great packaging system as oppose to a full-stack framework, I tried other frameworks/stacks and I think NodeJS has many mirco-libraries which are suited for large enterprises. I see Meteor as the Ruby on Rails for node, perfect for entrepreneurs and startups.
But I understand to each his own and you clearly made up your mind and I think some folks want more control once they get things going, there’re many options with the NodeJS ecosystem and some tech stack are more suited for certain use cases, but make sure you budget for more contracting jobs going forward, good luck.
p.s. really nice site, well done on level up tutorials!
@alawi has a solid point. So many times, on other forums/chats/stackoverflows, I’ve seen different variations of these posts over and over again:
“How can I get my build to… [insert tricky modern web dev problem here, like handling CSS and dynamic imports]”
…followed by a dozen different verbose suggestions for configuring Webpack, Rollup or some other tool, requiring hours or days of familiarization with the issue at hand, learning about all sorts of plugins and libraries, trying to figure out the tricky bits of the actual problem, finally landing on a sub-optimal solution that kinda works.
When I come across these posts, I usually put my hands together, close my eyes, nod gracefully, and chant “thank you Loooooooord for giving us Meteor” 
Yeah exactly, at this stage (since he is using React & GraphQL) all is he doing is swapping the build system to webpack (I assume) which is infamous for the configuration hell, most folks just copy/paste configurations or use boilerplate to get going, again I think webpack is more suited for larger enterprises in my opinion, I’d opt for something like Parcel instead, but that doesn’t have the maturity, features and ecosystem of Meteor.
Meteor build tool is packed with so many goodies out of the box (dynamic imports, code splitting and modern bundle, etc.) in addition to the unique packaging system that allows isomorphic packaging. Also, given Meteor philosophy of minimum configuration and backward compatibility, you’re assured to get latest node and other updates with minimum effort/configuration from your end going forward, something that many time tight entrepreneurs would surely appreciate. Also, Apollo/Meteor are managed by the same team, so I’d expect more synergies between the two projects going forward.
His site is currently blazing fast and part of it has to do with the modern bundle of the site that meteor is shipping to my chrome browser, something that will be lost going to webpack, take a look of how hard it is to implement and maintain this feature using webpack.
But maybe the author got funded and can afford larger team of contractors/devs dedicated to webpack (among other things), who knows, again to each his own.
It is a little strange, since you can easily use meteor as the build tool for an apollo/react project.
I suppose typescript support isn’t quite there yet.
Can you clarify this? Typescript has been supported for while for developers. The latest effort is to refactor the Meteor build tools to Typescript in order to make it easier for contributors.
I’ll add my opinion about typescript, I came from Java background and I personally found JS without types to be liberating and much less verbose. Java was designed for large teams/enterprises in mind, and as your code base gets larger and more developers collaborate on it, certain parts might benefit from having much stricter rules and more clear type definitions (such as the case of Meteor build tools) and this is the nice thing about typescript that it can be adopted incrementally and as needed (as oppose to Java which forces its weight on you from the get go).
However, I’d personally avoid jumping on the typescript hype if you’re just solo entrepreneur just starting things, at least that is my opinion. Meteor and its ecosystem system is all about speed and getting things out there quickly, yet the beauty is that you can incrementally adopt typescript/Apollo for the parts of the app which are more complex or you can completely refactor out of it should you even want more control (such as the case of the author here).
Can’t say for sure as I’m not using Typescript in our Meteor app, but besides the existing solutions from the community, I think an official TypeScript package was just recently released: The trusted source for JavaScript packages, Meteor resources and tools | Atmosphere
Oh, geez. I thought that was an upcoming feature, not an already here feature.
Thanks for letting me know, this is great.
I hope something like typegoose shows up for meteor.
Instead of trying to respond to each thing individually I’ll try and just give the general vibe. Level Up has been on Meteor for a very long time now, originally built with Blaze. I’ve been super happy with Meteor for most of the time using it, but I’m worried about its longevity and worried about its current situation. I also find myself using less of what makes Meteor special (ddp, blaze, ect) and because of that, I feel like the moving my platform off Meteor would be best for its long term goals. For instance, there is a TON of overhead I’m loading and pushing out to clients just because I’m on Meteor even though I’m not using the features. So my users are getting more JS to dl than they need and myself and devs working on LUT are paying the price of slower rebuilds and less available tools and community for not much benefit.
As far as finding a contractor to take me the last bit, I’m constantly recording tutorials, designing new features and working on the front end features to spend time with a project that is ultimately not going to change the site that much, so I’d be looking for someone who can just take care of those aspects and I’ll come in and write the webpack config and figure out plans to host after.
Another aspect that troubles me is hosting. I’ve hosted LUT on Digital Ocean (MUP), Heroku and now Galaxy over its long life. Galaxy has been the only Meteor deploy that’s been reliable enough for my business, but the pricing is high and it hasn’t seen any updates in terms of features or improvements in a very long time. I just don’t see MDG caring about Meteor outside of what Ben is doing with his work and even then, his time is split with Apollo. I don’t see this platform lasting without more of an effort by its creators. If this was a for fun project, I’d have a different opinion, but I can’t take the risk.
Thanks for sharing your thoughts.
The concern about longevity has been here since 2015, and MDG has stated several times they’re committed to Meteor long-term. I think people underestimate how resilient the tech is, as long as there is some folks deriving economical value from the tech I think it’ll last. My gut feeling tells me that Meteor (the build tool) will be here for long time. With that said, I do hope MDG and the community can work more on easing the FUD around Meteor.
For the rebuild times, we always want faster but for me it’s decent enough (around 4 seconds) which is acceptable unless you’re constantly doing monkey patching. But if dev time is a primary concern, then it’s surprising that you opting for webpack which need contractors just to config, deploy it and implement accounts.
The above two concerns have been echoed several times. However, I honestly can’t relate to your other concerns.
What overhead is that, can you please elaborate?
How is that true? You’ve access to all the npm packages in addition the specialized Meteor packages.
There is nothing really special about the Meteor server, it’s just another node js server but you also have MUP and Galaxy as an additional option.
Anyway, I think your site is heavy on content (which is great by the way, thanks for sharing) but not on features, thus it can be migrated relatively easily to other frameworks but frankly I don’t see the value in that other than the emotional assurance to address the FUD. End-user doesn’t give care how the site is built.
It seems like you are taking a defensive stance referring to my experience as FUD and requiring emotional assurance rather than taking an unbiased look at what I’m saying.
The concern about Meteor’s longevity has been largely proven true as we see time and time again companies leave Meteor and community members abandon it. MDG is not going to do anything to change this if they haven’t already.
If you have a site with SSR and some size to it, Meteor’s build tool will take a very long time regardless of my dev process. Regardless, it’s not nearly as fast as many other build tools I’ve used in different, but similar setups. I’m no huge fan of webpack itself, but at least if you want to find people with experience in it, you can find them.
Overhead referred to is shipping Meteor code that I’m not using. This was the case for many package requiring Underscore, jQuery and so, on in the past but just to use Meteor’s mongo package you are roped into a bunch of everything else. Just to use Accounts you are roped into DDP. I’m not using it, so I’d like to not ship it.
Tools. I had to hire the very awesome @captainn to make a custom version of https://github.com/jamiebuilds/react-loadable just to support SSR with Code splitting in Meteor. There are lots of other examples of this, things like the Stylus package being deprecated or atmosphere packages that haven’t even been glanced at in years. Or source maps in production, a feature that’s been requested and ignored for years before being taken up by a community member. That’s how that’s true.
Hosting. I’m very aware that Meteor is just a node server, but MUP is constantly breaking and I’m not interested in maintaining or managing my own server config.
My long experience with Meteor is far from FUD, it’s informed and experienced.
I love Meteor for what it is, but at scale there are things that are frustrating and better solved by other tools.
I’ve had the same experience as @stolinski regarding hosting. Galaxy is the only thing close to zero config, but it’s expensive, deploys are slow and hard to troubleshoot, scaling is tricky to reason about, etc., which makes it a tough sell when it’s just a layer on top of AWS.
I also think what makes Meteor great is what makes it painful: magic, isomorphism, speciailized Meteor packages, etc.
Magical things are hard to debug and reason about. Isomorphism sets a hard requirement on an agreed upon API between front and back ends. Specialized Meteor packages come with their own maintenance hurdles and lack of support by way of a smaller community of users.
I think it’s easy to look at a team like @veered’s and say: Look at the amazing, large scale thing they built with Meteor. But if you follow their involvement, you’ll also know that their team are Meteor experts. They have custom tooling and solutions built around Meteor. I think that they were able to build something so scalable with Meteor is more of a testament to their team than anything, especially considering they did so much of that before people like @diaconutheodor were making meaningful contributions to the scalability of Meteor.
I think an overarching theme of this community is that the flow of individuals and organizations is now probably at a net negative, if you’re looking at month over month numbers. Meteor is great for small scale and medium scale projects, but I feel like it can’t really compete at large or enterprise scale applications without Meteor experts on board.
MDG doesn’t do much marketing on behalf of Meteor now, so the influx of people using Meteor as a springboard is pretty much gone now. I think that this is the general vibe that contributes to FUD, not lack of faith in the project. Anyone who follows Meteor knows that @benjamn is a genius and has pretty much singlehandledly built Meteor into a tool that is superior to things like webpack in many ways. His work has obviously influenced other tool-driven devs for quite a while.
I’d love to see a Meteor renaissance as that springboard/MVP tool that gets you some $$ and allows you to transition your project over time to more mature and scalable tech, but it doesn’t seem like that’s the position people want it to take.
Exactly. I’m not insulting Meteor as a platform or any of the work done. @benjamn is amazing. Meteor has served me very well for a long time, but to act like Meteor as a platform is as strong in 2019 as everything else out there is ignoring quite a bit.
Sorry I didn’t mean you were causing the FUD, I said repeatedly that I appreciate your perspective. When I said FUD, I meant the general FUD surrounding it.
Anyway, anything I’d add here it’ll make me sound more defensive so I’ll leave it here, good luck with migration :).
I agree with a lot of what’s said here, but I’ll also say that there is a lot of activity (3 of us just busted our butts to make a new react hooks implementation - and it’s really stinkin’ cool), but it’s hard to figure out what the latest stuff is. One example is that there is a newer fast-render version which is actively maintained, but I still mostly find all arrows pointing at the abandoned kadira version. There are also newer versions (or alternatives) to the lightly maintained ground:db - these are just two examples. There’s an alternative to Slingshot even though I still use that, etc. I find I end up forking some packages locally just to update some dependencies, and PRs are often ignored (but not always).
I have been thinking about trying to form a group of community developers to jump in and maintain a group of these. I’ve already set up a number of packages with the npdev: prefix, and would love to produce some more. For example, I’d love to have something like a user auth package that simply patches SSR to make it work like it does in kadira:fast-render - transparently make user account APIs like Meteor.user() work in SSR contexts. I’d LOVE to produce a proper React Loadable specifically for Meteor, instead of requiring the use of my fork of react-loadable (I haven’t prioritized that because the version I have already works, and I suck at figuring out to get these types of projects funded). If anyone is interested in helping maintain some packages like that, hit me up in a private message.
(BTW, one thing I don’t agree with is the need to move off Meteor - I do wish some of the build system was as easy to get in and modify as webpack, but webpack is no picnic either - and it’s fragile as heck - but there are plenty of advantages to using Meteor that I haven’t even duplicated with my webpack based projects.)
I’m not sure migration is a “need” so to say, or that the app’s life depends on it, but def thinking about the next 2 to 3 years of its life and where this community will be then. Not to say that it will be gone definitively, but I don’t see things turning around from their previous trends without some major injection of support.
Things I’d like to see in Meteor (besides the things I’ve already figured out):
appcache.underscore, and reduce eager loading (to decrease initial bundle size) - I’m willing to help with this.I’d also like to see:
One more - I’d love to have a way to define code blocks that are removed from production the bundle altogether, to avoid bundling large strings of development warnings and the like. The broader js ecosystem could use some standard for this.
I wonder if MDG is hiring, heh
Meteor is king for backend (with Apollo and React). Our flow is like this:
We use it in large-scale and mission-critical places. For resource intensive stuff we delegate to lambda or outsource someone to write in Go or C and use it as an API.
We have easy to add SSR, easy to have reactivity with Apollo (scale-able reactivity via redis-oplog), extremely fast speeds with MongoDB and Grapher. We are engineering at an incredible scale and we are extremely happy with Meteor.
PS: We have a project running Blaze and old-school Meteor package architecture and pub/sub. That still works super fine, it’s still a nice project that’s growing. As long as you respect engineering principles and code doesn’t rot. You can grow. Otherwise, you blame it on the stack.
The use of storybook to develop the components is interesting and I’m curious how those components are ported to the Meteor projects.
It looks to me that an implementation of HMR (although its effectiveness and reliability are arguable) needs to be considered in Meteor because after the assurance of longevity, HMR seems to be the second most wanted feature, indeed it is a big selling point to developers (but for me Meteor is a better selling point to your client, since you truly can do (and not just feel) that you’re getting more using less however DX experience is important and why not having both. Qualia engineers managed to get near instance refresh with Blaze back in 2017 which seems even faster than react HMR.
I recall Ben stance on this is that it might require some custom code for React and he would rather focus on making the refresh faster (which he did). However (and frankly I’m not aware of the inner workings of HMR) it seems webpack is capable of having generic implementation for both Vue/React, perhaps some action hooks can be added to Meteor watchlists? the issue is that front-end development pipeline got really complex in the last 4 years that saving a file and refreshing the client is not fast enough (for some) and thus a more granular and complex module replacement is desired.
I took a look at the HMR code and it’s really complex. Every solution breeds new set of problems, and to simplify a complex systems one will probably need to implement an even more complex system, the cycle and joy of engineering.
My apologies for getting off on a tangent and distracted from the author enquiry but I think it is useful to have a conversation around the root causes of it in the first place.