State of Meteor?

[fillipefeitosa]

Friend,

Actually is not that hard to use both.

You can check this docs and package to use with ostrio:files, https://github.com/VeliovGroup/meteor-autoform-file

And if you need to see an example, check my public repo Urbanus.

fillipefeitosa/urbanus

Make sure you check both Team and Image Api’s.

If you need anything just ask! Good work.

[felbrasil]

Thanks Fillipe, seems like this is just what I needed as an example!
This is another amazing thing about meteor: the community is awesome too.

[raphaelarias]

EducationLink has been running smoothly for 3 years now. We use Vue.js. (geteducation.link).
We have three different Meteor apps for three different types of users, all connecting to the same MongoDB Atlas instance. For background functions we use AWS Lambda. We also have some special APIs on API Gateway.

[jkuester]

Since it is also related to this post, I would like to encourage everyone to participate in the community survey.

[johnwhitney87]

We have a growing Meteor app in production for 3 or 4 years now. Pre-Galaxy using MUP on AWS EC2, then switched to Galaxy. We’re behind a few versions on Meteor. Still on Blaze. We’re more focused on the app than the version of the framework - so we haven’t fixed it since it hasn’t broke (yet).

Our app handles huge bursts of users (often thousands) at live events all descending on the app at the time time. Also, I wrote a research about this at https://uk.edubirdie.com/plagiarism-checker. So it’s had some unique challenges. A couple of notes:

• We learned very quickly to deliver the app-bundle through a CDN and not the Meteor server - doh! I have a really long post about figuring that one out.
• The micro-service that handles all those user bursts had to be stripped of all pub-sub. All client-consumed data is delivered using cached Meteor Methods and thus heavily debounced off the database (this was a huge breakthrough). Anything real-time is updated with laser-focus for bare minimum overhead via redis-oplog’s manual Vent tool.
• All client responses are also handled very carefully using caches and special update techniques to the database to minimize pressure. We basically “round up” groups of responses versus sending them one-for-one to the database (another huge breakthrough)
• On the admin UI’s we use pub-sub with redis-oplog. Any graphical element (e.g. a chart, graph, etc.) that is representing all that response data in real-time using Blaze and Meteor’s default real-time “magic” will grind a user’s browser to a smoking halt as thousands of responses flood in within seconds of each other. I think this is more Blaze than anything. Had to turn all that off and switch to publishes with polling and/or more intelligent updating in certain situations.
• We use redis-oplog. Every now and then there seems to be some quirks we’re still working on but for the most part it’s solid. And can handle a lot of traffic.

Have to say that it’s making a point.

[cormip]

I’d been a long-time ColdFusion developer (yikes! since 1996) and loved how quickly you could develop multi-featured apps with not a lot of code. I switched to Meteor around 3 years ago and have 7 Meteor apps built of various complexity and features. Like ColdFusion, it’s easy to build things “incorrectly” that can impact the performance or reliability of the application. i.e. both platforms give you enough rope for you to completely strangle yourself with.

The hardest part is optimizing Meteor’s pub-sub and memory consumption. One thing that doesn’t get mentioned much is the performance of the underlying database provider. After switching some of my apps to fast-network, SSD-based MongoDB instances, I could see much faster performance in several parts of my apps.

As previously mentioned, I do sometimes rely on methods to retrieve data, since the awesome reactivity pub/sub provides isn’t always necessary, or worth the penalty.

I’m currently working with Vue, Vuetify and Vuex for the front-end (no Blaze at all), and must admit it’s been tougher than expected to get started because there seems to be MANY ways Vue can be integrated with Meteor without really seeing a “Best Practice” obvious path. The online examples are all over the place, but the single file components truly are sweet!

I have no short-term plans to switch away from Meteor, but there’s also the thing about using the right tool for the right job, and I can see where Meteor might not be the best fit in all cases.

[ni-ko-o-kin]

I’m developing software in meteor since 4+ year. Solo and in teams. Clients in public and private sector. And I’m very happy with meteor and will continue using it in future projects!

[maxhodges]

nodeJs (zeit now)
[ more characters.]