@efrancis thanks for sharing the article. Unfortunately it allows to run with jest unit tests only. Integration tests are way more useful with meteor IMO.
Chimp is the best option for Meteor integration tests and let’s you use mocha so it’s the same syntax as Jest. 2.0 is being worked on but 1.0 is still great
SQL is a must. Being able to have a product within a week is another must. Especially true for large corporations I’ve worked for.
3 Likes
There are a few things that are different -
Agreed, SQL support would be great
Problem of SQL support is how to achieve reactivity. I have played with this quite a bit, but it is at the “polling level” currently. Getting to reactivity like oplog (or redis-oplog) would require more work because you have to know how SQL statements impact results.
See this package and this issue for more info.
1 Like
I vote for new shiny tutorials and Meteor Guide revision.
8 Likes
I would love to have a better development experience in Windows, because of my work I swift around MacOS and Windows a lot and the reload times in windows are 10times higher than in Mac (which makes things a little annoying).
3 Likes
Apollo can be very helpful here. It supports client-side data cache, so data need not be refetched, optimistic UI, reactivity, etc. and is very easy to use with React.
2 Likes
Support for microservice.
2 Likes
Is there something preventing you from using blaze now?
Genuinely curious, did one of the recent update break it?
4 Likes
While i wrote this post, i noticed, there are two directions meteor could take:
the apollo route (probably what mdg wanted)
Embrace the ecosystem around react or vue and apollo: I think meteor’s biggest contender in this is next.js and nuxt.js. I never tried nuxt.js but i guess it’s similar to next.js. Both lack a data-layer however, which is usually fullfilled with apollo and any db (mongodb, sql, whatever). What’s also missing is reactivity, which made meteor really unique, but its also a not needed in many projects.
So to seperate it from next.js I would:
- deep and seamless apollo integration. Seriously, this was promised by mdg, but never done properly
- out-of-the-box authentification&authorization through graphql and meteor’s account system
- out-of-the-box reactivity using graphql-subscriptions, websocket-channel and some pub/sub like redis for cloud-environments
- client-libs if needed to help with these features for react and vue, building upon apollo-client
- out-of-the-box integration of apollo-platform (optional, but mdg could be interested in a deeper integration)
and maybe:
- give a good migration path from ddp-pub-sub to apollo so that we can deprecate ddp-pub-sub, because it is holding meteor back.
Having said that, here is the other path:
2. back to the roots
You can create a stack like described above without meteor using current best practices. This is initially more effort, but gives you a flexible stack.
However, meteor was great, because you could setup a project so fast and it needed nearly 0 configuration. So tiny could just add some missing pieces to meteor:
- focus on ddp-pub-sub, add missing features, make it scale using https://github.com/cult-of-coders/redis-oplog
- focus on one view layer, maybe even go back to blaze or settle on one of the others
- first-class router and server-side-rendering
Personal thoughts
I guess mdg themself had the same thoughts about which direction meteor could take. This resulted in a split of the community. Some prefered to stay with the original way, others migrated to react (or vue) and graphql. Arunoda, who contributed a lot to meteor also did not believe anymore in the original, monolythic nature of meteor. I also share many of his thoughts. Meteor in its original form (blaze, mongodb and pub/sub) is a dead-end. It’s great in the beginning, but its hard to scale it application-wise, e.g. add more clients like native clients, split the backend in services, integrated other services, etc. (of course its possible, but not without a lot of research, experience and effort).
So i personally would love to see it going in a direction like these create-xxx-app:
They create an (opinionated) setup using best practices, but hide the configuration until you “eject” it. So if you need to diverge from the original setup, you can eject a part of it, and customize it. This could give the best of both worlds.
Some words for mdg/apollo
I think giving meteor to tiny was the right decision, but i would love to see you guys give us some of this sweet meteor magic in our apollo-stacks. E.g. build a library for next.js that adds easy authorization/authentification through apollo. Or a library for 0-config graphql-subscriptions. Or a nice orm-layer, a 0-config prisma2/photon integration would be awesome.
6 Likes
It’s no longer maintained and updated. No new features.
That scared people away from it.
1 Like
There’s such a thing as a library being “done”. If it’s not mired with security vulnerabilities due to neglect, it could just be the case that it’s “done”.
It could also be the case that MDG got pulled off onto apollo before they finished it, and now it’s “good enough”.
Hopefully with the Tiny aquisition, it gets some more support. I’ve never used it myself, but a lot of the meteor projects around the web use Blaze, and it always looked like a nice option.
1 Like
Any official support for solving the scalability issue?
back to the roots of Meteor.
- super easy to use and low barrier of entry, no tooling. does all the things for you, so you dont have to worry or know
- so much fun with reactivity (find solution how it could work with scaling)
- multi platform, iphone android electron etc
- bring back “meteor deploy”, which was so ahead of its time. See now.js from Zeit or netlify…
become the cool kid of all frameworks on the block again. bring back blaze like simple UI library without the tooling of React or other frameworks.
make it just work and as easy as possible to do stuff.
4 Likes
My thoughts are from the perspective of someone who has to “onboard” about 90 students to Meteor every semester in my software engineering class. After about 4 years, here are some things that in my experience will help new people come up to speed with Meteor more quickly:
-
Some sort of free tier in Galaxy, so that new users can go all the way to deployment without having to lay down a credit card. Galaxy is a very easy to use deployment environment with excellent application monitoring capabilities. It can be a major selling point for Meteor; a free tier would be great marketing for the platform as a whole.
-
Improved testing, supported by Tiny. Testing is not easy in Meteor, and relying on third parties (like Xolvio) to provide excellent, up-to-date, well documented testing is not feasible or even appropriate. Excellent support for testing should be a core feature of the platform, not something left for the community to supply.
-
A revised and up-to-date “Discover Meteor”. Hire somebody to update Discover Meteor and republish it next year as “Discover Meteor 2020”. Then, each year, release a new version: Discover Meteor 2021, Discover Meteor 2022. I can guarantee at least 90 copies will be bought each semester.
-
Blaze vs. React. I now have a LOT of experience teaching both Blaze and React to newcomers to web application development. I can tell you that it is NOT significantly harder to teach a newcomer React, and 100% of my students like learning React since it gives them a useful line item on the resume (everyone knows about React, no one knows about Blaze). For marketing Meteor, it’s counter-productive to argue that “Blaze is simpler and so you should use that”.
Here’s a blog post I wrote for MDG that touches on some of these topics: Teaching software engineering with Meteor | by Philip Johnson | Meteor Blog
To give you a sense for how I approach teaching Meteor, you can take a look at the three Meteor modules from my software engineering course this semester:
http://courses.ics.hawaii.edu/ics314f19/modules/
Obviously, “newcomers to Meteor” is just one of many stakeholder groups that Tiny has to worry about, but it’s a significant one.
21 Likes
Just some small thoughts.
- All packages off atmosphere. - A separate package eco system scares people off.
- 100% stop official support of Blaze - It doesn’t have enough marketshare and It isn’t gaining in popularity. IMO is never going to be competing on those levels and we should just embrace what’s being used.
- Features of a modern webpack setup - HMR, faster rebuilds. 0 Config style, or something to the effect of Next.js levels of config is key.
- Make Apollo/GraphQL a highly integrated aspect of the platform. - Official accounts packages, less config.
These are just some things I would like to see personally. I’m sure I could think of more.
8 Likes
That is not at all the case:
These are milestones for the 3 most recent releases (the latter two are still in progress)
2 Likes
One thing I am realizing reading all this is that it seems accounts packages are really the most wanted feature of Meteor. Everybody seems to like them and use them and would like to continue to use them (without DDP, Mongo, etc.).
Does this mean that there is really no good alternative existing in the NPM ecosystem for the good accounts package which would support OAuth and everything else?
2 Likes