I’m currently in a position where I’m looking to use a stack that doesn’t include Meteor (crazy, right?!). We’re fortunate to have a lot more options for Node.js frameworks these days, and I’m evaluating the following:
Feathers
Hapi
Koa
Express
Adonis
Loopback
Sails
I wish I had more time to dive into these deeply, but I don’t… and so on their surface, a few of these look extremely similar (I’m sure there are big differences under the hood though). Does anyone have any strong opinions on these? My only requirements are:
real-time/reactive, but perhaps more on an opt-in basis than Meteor; not everything needs to be real-time
interfaces well with Apollo + GraphQL
should be super performant and scale really well
lightweight: fast build & deploy times
friendly to junior level devs
should be pretty mature/stable and well-supported (by community or otherwise)
definitely not looking for the next new and shiny thing
(optional but strongly desired) ability to use ES2015, including async/await
I’ll check it out, though I’m pretty strongly set on sticking to evaluating the list I gave above. It would be easy to run off the rails looking at all kinds of new frameworks. I have a tight deadline to pick something new.
We have quite long topic about it. I’ll link to the comment where I wrote my thoughts on the same matter when I was dealing with the same dilemma. I addressed there Feathers, Sails, Deepstream, Horizon and Socketcluster.
As for Hapi, Hapi days seem to be slowly getting to a closure with Walmart getting rid of main Hapi developer(s).
No idea. But my theory is that if Feathers or Sails got dropped by their recent teams, it would be the end of these frameworks unless a new company comes in like in the case of RethinkDB. The community wouldn’t handle the work.
It may not be a case for Hapi, dunno, I don’t have that much experience with that framework.
In these cases, maybe NPM downloads could be the best indicator of viability. Express is doing almost 12 million downloads a month while the other’s are barely breaking past a million.
Next.js is pretty new and shiny but seems nice for web, I’d consider it for future web projects. I’ve been doing mostly mobile recently and have been using an express rest api + react native. I like graphql and plan on using apollo for backend in the future now that it has subscriptions and is a bit more mature.
React + Apollo Client: this is not meteor dependent, or anything dependent for that matter. It would be future proof (as far as future goes these days). Your team would pick it up fairly easily.
Backend:
Apollo Server: You can port your graphql server code to any node-based backend by merely copying and pasting. Should you consider a stack change, say towards elixir, you would probably be able to keep at least your application structure which would then make it merely “code translation”.
Build tool:
Meteor, obviously. Because I’ve worked with various javascript environments and build tools and always find Meteor refreshingly problem-free. Yes you’ll miss hot reloads if you’re used to them, but hey, you can always separate out the client build onto webpack and build it as a separate app that connects to your graphql backend and meteor would still be a great build tool for backend development.
Accounts:
This is where it gets a little tricky, because in my opinion this is the part which is too coupled with Meteor. So you might want to consider implementing something based on JWT’s or give passport a try. After all, your apollo server on meteor is still an express app!
As far as developer frustration goes, that’s probably becuase they’ve seen the legacy app and now they think that’s how all Meteor apps are.
I’ve seen some legacy Meteor codebases, a few I’ve created myself and somehow got back to only find them exactly the same, without any “modernization” and believe me it hurts to even look at them. You might want to show your team how proper modern meteor apps look and plant the idea that meteor does not have to be a stack, it can be a good build tool and stay out of your way.
If in the end you do decide to keep afar from Meteor, express is probably your only option (perhaps except for Koa) that’s not a “framework”, because as far as frameworks go, you’ll eventually grow to dislike your choice. So something barebones like express is always something you can take with you when you abandon some “framework/stack/buildtool”.
For anyone curious, I decided to keep Meteor (but minimize its involvement) and add GraphQL & Apollo to the stack. And probably use Graphcool as our PaaS.
I’m currently very happy with SocketCluster (which comes with Express by default like many other node frameworks) + Mongo/Mongoose + Vue + Nuxt which is Vue version of Next. If Next is as good as Nuxt, I highly recommend it, but I’ve heard both projects have their differences.
I’m gonna look at Passport for account management. I’m not a fan of Meteor’s email verification/password management setup. It sends via SMTP and you have no way of hooking into that process and using an API, e.g. using Postmark’s API to send variables & specify an email template to use.
@a.com Meteor even with the most basic bundle is far from being lightweight. I hope it changes in the future though, once we are able to remove stuff like Minimongo from the bundle.
No, I agree with your list… which is why we’re keeping Meteor. Though I wouldn’t call it lightweight, at all. My biggest beef with Meteor is the lack of sourcemaps built for production builds. Debugging problems in production is a massive pain.
The greatest thing ever would be a npm package that you can add to a vanilla node/express/apollo app and get a meteor-esque account system tied into the apollo context. You provide the package a URL to a mongoDB somewhere, and boom you have an account system. If you want the rest of your app to be SQL and whatever, that is fine but the account system lives in mongo and it comes with all the relevant helpers.
Sorry, I misspoke. The issue is that if your email service only has a REST API, there’s no way to funnel Meteor’s account emails through that without just generating your own tokens and essentially manually handling password resets, etc.
I have a tight deadline to pick something new.
I’ll link to the comment where I wrote my thoughts on the same matter when I was dealing with the same dilemma. I addressed there Feathers, Sails, Deepstream, Horizon and Socketcluster.
But now I’ve narrowed it down to the above frameworks and am curious about those specifically.