I have a large project that I am pitching to a customer, planning to use Meteor. We’ve been talking about it for 12 months already, and now they are questioning choice of stack, and suggesting that NextJS might be a better choice. This is gut wrenching, but I have to deal with it.
I know we have discussed this before Replace Next.js with Meteor?, but I figured it doesn’t hurt to ask again and get fresh input.
I realise that I am completely biased towards Meteor, and can put together a case for it, but I should also be objective about it.
I am interested in hearing of comparisons between Next and Meteor (even if they favour Next, in fact especially so).
I would argue that your competencies are much bigger around Meteor. Experience is an argument imo. It will be reflected in so many things in the code. Besides that a direct comparison would require a bit more of their requirements to compare the frameworks along these requirements.
I no longer use meteor for new projects (still love its legacy) and do frontend-projects usually in nextjs.
But you cannot compare them directly. Nextjs does less then meteor, but does it better.
Nextjs is best for public frontends that require SEO and high performance, also its a good choice in general for react-apps (nearly 0 config)
You can easily add api-routes (rest or with some small boiler graphql) for data, or build a separate api project (recommend graphql!), but you don’t get these meteor subscriptions out-of-the-box (but you also don’t have to deal with its scaling problems). On the long run its still a good idea to separate the api layer a bit more from the frontend, but make sure to have a strong “contract” between, like graphql or a good swagger rest api.
You also don’t get authentication out-of-the-box (but there are good libraries for that, e.g. next-auth).
To me it sounds like … should I write this novel in British English or American English.
one deciding factor is your data structure - objective
I think it really comes down to what the large project is about and if you need SQL type of DB.
For e-commerce, invoicing, complex reports etc … I wouldn’t pick Meteor and pair it with Postgres or MySQL. I would only pick Meteor because it is already “specialized” in MongoDB.
another factor is client’s confidence in the future of the stack - subjective.
From a client’s perspective, code sustainability and continuity is also a very important factor. If you compare the 2 communities (Meteor and Next) it would be “natural” to pick Next.
What I would do, give Meteor cheaper and write it in a way that assures future migration to anything else (if confidence is the actual concern). For instance Redux (in both Meteor and Next) allows you to completely separate data from view and build a fetching API with a global store that can be then ported to any Node environment without affecting your font-end.
Why Meteor and why cheaper? Because Reactivity, Accounts, Email, Push, Mongo, comprehensive and relevant monitoring. You can still get these if you host Next with Amazon and integrate with AWS respective services, if you host with Google and integrate with the respective Firebase services… But in Meteor you don’t write a line of code. You just do … Email.send()
It really depends on your project. The right tool for the right job.
I worked a lot with NextJS, and I think it really shines on SSG and SEO, and I see it as a frontend framework and not full stack as Meteor.
I know you have the /api routes, but it is serverless.
Serverless is good for something that is not heavy, but if you start doing more complicated things, it will be slow as hell.
if you deploy nextjs outside vercel/netlify, be prepared to have many problems, especially with AWS. (I’ve been there before).
It does not provide you a good way to write your backend, and you have to do everything manually, eg, NestJS or Meteor does that for you. So less code, fewer bugs.
I think Meteor really shines on full stack apps that are dashboards or anything that doesn’t need to be public SSR (we need to improve that). It’s also blazing fast to build, and you write less code. So again, less code, fewer bugs.
I would argue that your competencies are much bigger around Meteor. Experience is an argument IMO.
i agree that, your team should decide what the right tool is. And this also depends on what you already know and love.
I know you have the /api routes, but it is serverless.
Serverless is good for something that is not heavy, but if you start doing more complicated things, it will be slow as hell.
if you deploy nextjs outside vercel/netlify, be prepared to have many problems, especially with AWS. (I’ve been there before).
I wanted to add something to the api routes in nextjs: they don’t need to be serverless, i think that is only when you deploy to vercel (never deployed there). We generally just build it (using next build) which outputs a ready-to-use node app, which then can be dockerized and hosted on container hosting (kubernetes or paas solutions), or classic vm hosting, identical to meteor, which also just bundles to a node app.
but if you have a more complicated backend, i would use nestjs or something like that anyway as a separate api application if you use a nextjs frontend
They look at the nextjs showcase site, and see lots of shiny things. Meteor.com isn’t shiny, even though it’s owned by Tiny.
We’ll use Mongo,as we need flexibility in the data, so it’s a good fit. We’ll use a mixture of subscriptions and methods for data fetching.
I can write a hundred reasons why Meteor is the best choice, due to massive bias, but I also don’t know enough about NextJS to say much about it. I know I am pretty much preaching to the choir here, but I appreciate more help if you don’t mind.
Here’s what I think are the most compelling reasons
Item
Details
Mobile
Meteor can provide a mobile app from the same code base
Speed
We can do it quicker/cheaper in Meteor
Starter app
I have a percentage of the code thy need already written. Using Next would mean starting again to some degree
Performance
Socket connection to server means it’s very snappy
Full stack
Better integration between front end and back end means less code to write. Services such as authentication are built in. Less code, fewer bugs
Monitoring
Monitoring tools available for the Meteor stack
Engineering
Meteor deployment is “out of the box”, Much work is required to manage and orchestrate serverless infrastructure
The serverless thing is a difficult one to fight. On the face of it, it’s very attractive, Amazon looks after scaling for you, and everyone is doing it, so why wouldn’t you?
I am unconvinced at serverless being “a solution”, and I’m not sure I can argue the case well. If you have a database with many collections, are there weaknesses? Is it easy to have shared code across services? Is there a problem with versioning, and orchestration? I’m sure these things can be solved, but how much engineering is required for that?
By the way, I would argue that serverless is also compatible with Meteor. It’s just another server to be called. In the end you can’t write your app entirely serverless unless you have very simple use cases so the whole serverless thing is anyway just an extension to the backend.
i think serverless is indeed not really a good reason, its partly a cost-reducing thing and partly something useful in a (micro-)service-architecture with cloud-native solutions. A serverless service architectures can have its benefits, but needs experience and more conceptual work.
However your table is a bit biased, i would take requirements of the actual app and then compare different solutions.
For example, do you need a mobile app in the store at all? (Be also aware that meteors mobile integration is not perfec)
Another thing is performance, that is a wide topic. If it has a lot of public accessible information and should be SEO optimized, time to first byte, time for largest contentful paint, etc. are important, you should definitly not use meteor for the frontend. SSR with meteor is possible (i did it with a older pub/sub app), but I cannot recommend that at all. Definitly use next for the frontend if you need SSR and SEO, everything else is just hacky.
Performance can also be scalability, which is another tricky topic in meteor. I recommend to check whether you need to scale the app to a very large audience.
Also the other topics are also true for many other platforms and architectures. Also i think the Fullstack aspect can also be negative in some aspects, in particular if you use pub/sub. Its hard to get that out later should you reconsider and want to (re)build a separate frontend.
In the end, i would recommend to consult with your team, that should not be a one-man decision, neither from you nor from any “boss”, it should be a team-commitment. If you are unsure, take the time to do some proof-of-concepts that show that you can fullfill the individual needs of your application and maybe compare different solutions. And as already mentioned, nextjs does not replace meteor by itself. You will need some other services and tools, that should be part of the comparison and the decision.
@macrozone You are correct, there is a need for a mobile app, which is probably a compelling argument for choosing Meteor.
I am hoping this isn’t a major U-turn, after all NextJS isn’t a replacement for Meteor. We will discuss it on Monday morning, so I don’t have to wait too long.
AWS is also scaling my Meteor app (which is run by AWS Fargate) automatically. So no difference there.
I also run 10+ AWS Lambda functions for more CPU heavy task, deploying them is pretty damn easy (easier than deploying Meteor to AWS Fargate, luckily CodePipeline is a big help once it’s setup properly).
Next.js can be easily deployed to a serverless stack which will make it sooooooo much cheaper at scale compared to Meteor but the questions is really dependent on your product’s requirements. I use both and I really enjoy Next.js for the things it’s good at. I also really like Meteor for some specific use cases.
If you need lots of real-time-ish subscription data Meteor might be a great choice. If you just need a back end with basic reads/writes at scale of tons of users Next.js might be a better choice and it will almost always be significantly cheaper especially at scale.
