True, Grapher does a nice job of packaging and documenting how to get set up. And to say it’s a wrapper was a huge overstatement on my part. If users like a graphql-like API that’s similar to Mongo’s query API (as I think of it), as well as relational support, and even an ecosystem of other tools around it, then that data stack is a good fit.
1 Like
Grapher is awesome, my only concern is that even its creator stopped using most of its features. Which means most likely we’ll never have updates for that parts. E.g. it’d be awesome to fetch documents from network only when they’re not fetched with the same params/body without having to use apollo.
2 Likes
Any ideas on the best way to change this? does it require installing a local version and modifying the source or are their any flags available?
1 Like
One idea that I would like to try on Meteor build system would be to not re-scan and re-evaluate dynamic modules if they are not changed.
I don’t think Meteor is doing this because I applied dynamic modules broadly in a huge app and the rebuild time still the same.
Would that be very hard? I think we could then cross the file watchers info with dynamic modules info and just re-evaluate the changed ones.
1 Like
We need a official DDP client include minimongo, so we can use any frontend framework with Meteor backend by DDP.
because it is still hard to integrate frontend framework. for example. nuxt. when set up a new project, I want to use meteor as backend. but when integrate the frontend, it always to get limitation and spend lots of time to make it work.
1 Like
What really worries me is how many different directions people want to take things.
In my opinion what made Meteor so awesome, and why it grew so fast at the beginning was that it was incredibly simple and made it ridiculously easy to get s**t done compared to other frameworks.
What killed it, was when people started overcomplicating things… breaking off bits of meteor to mix with other frameworks, pushing aside Blaze so they could hook up that shiny new React thing - even though React wasn’t designed to work in the same way and it needed a ton more boilerplate.
The community just got fragmented with people all doing things differently, none of it properly integrated or documented, but no-one really giving any love to what was there originally.
Personally I’d like to see meteor return to its roots. A very simple, clean framework with a very low on-ramp, where people don’t need to learn React or Vue or [insert latest front-end craze here] to get started. Blaze was awesome for that and is perfectly capable of making a solid UI. With a bit of TLC it could probably be a lot better too.
16 Likes
Agree… mostly. Meteor should be improved not change drastically how it works now. Improve the core technologies. Since it would be hard for people like myself who still are still learning and using the framework. Maintaining and making it easier to use react and other front-ends frameworks would be nice.Also keep support windows and perhaps improve speed on windows
2 Likes
My two cents,
I am first and foremost an entrepreneur, and I believe that is where Meteor shines. In being a tool that allows you to take an idea and turn it into a product. This has always been the appeal of Meteor, being a straightforward path from idea to execution.
However, an important benefit of being an entrepreneur in this industry, is having a solid backup plan. If my products don’t generate revenue, I can always go get contract work to pay the bills. This is the balance that I feel has kept me in the Meteor community. For me it’s not about the new shiny thing, as some suggest has become an issue here, it’s ensuring that I can use new technologies so my skills remain marketable, whether it’s React, Vue, or GraphQl.
A fundamental product belief of mine, is things don’t need to be simple, they need to be clear. So my Most-Wanted Feature for Meteor is to continue to become more clear, straightforward, yet adaptable.
9 Likes
Howdy, I’ve used meteor since version .5~. First off, I think that a lot of people are talking one of meteor’s best selling points was developer experience. I remember waiting for meteor day to watch the things that people were making with meteor. These sort of things don’t have much to do with features or that sort of thing in Meteor, but it improved the developer experience. Atmosphere is much more fun to use than npm and deploying a quick demo app to *.meteor.com brought joy to many developers. I remember when people in design started to focus more on UX/UI and it seems like meteor had brought some of the UX/UI thinking to developers… I think that’s why people mention that meteor is the “Apple” of frameworks. Ease of use is developer experience, but developer experience is not ease of use. As a company just initially getting involved with meteor, I think that tiny can come up with ideas on how to bolster and get back to the days of the great developer experience meteor once had. I think one of the biggest things that hurt the developer experience in meteor was integrating npm and opening up meteor to multiple front end frameworks too close together in the framework development; this fragemented the community and there was a lot of confusion about how to do things, ie no “Discover Meteor” for these type of changes.
I think @benjamn and alike know what to do for at least the next 6 months of meteor development, so I’m not going to suggest any features. However, since DX (developer experience) is one of the biggest selling points of meteor, different methodologies of creating the framework need to be put in place (your product is not your product). I think that vulcan by @sacha aims to hit at those notes of DX that meteor as a whole ecosystem once had.
5 Likes
I hope the new Meteor owners hear that. Entrepreneurs are almost clients for life, and will rarely, if ever, ask for disruptive changes - hardly a downside for the framework maintainers.
Meteor with its original stack is an amazing tool for 1) fast prototyping, 2) building an MVP, and 3) growing your product & business. And before I get rebuffed with ‘does not scale’ replies, I’d say, well, congrats if you got to that point. It means you must have clients. It’s a good problem to have, and one that is solvable. Just don’t forget how quickly you got there, and that’s in good part because of Meteor.
You can rely on it to always work. Countless product owners on this forum know that already. I challenge whoever thinks differently to show me their product, built with a comparable JavaScript stack (so client + server) that can claim the same level of stability.
15 Likes
THIS. I want to move my stuff to Galaxy, right now I am localhosting production to save costs… 
5 Likes
Auto-scale Galaxy! When I finally move off Galaxy, it won’t be b/c of the price. It will be b/c our hand-rolled scaley-bot is a weak point that is hard to live with.
Also. Separate ACLs for galaxy team members. I want some team members to view server health… and scale up, but never see the API keys on the “settings” tab.
+1 for Galaxy 2fa.
5 Likes
We would like to use Users from accounts-base with an ObjectID not with a string, following the Mongo standards to be able to create applications compatible with other databases.
1 Like
If you only need unidirectional realtime data flow, see
I can’t say that I understand your “security, network tuning and monitoring perspective”, but Meteor allows you to explicitly disable websockets and switch to HTTP long polling by setting the environment variable DISABLE_WEBSOCKETS=1.
From the official docs:
In the event that your own deployment platform does not support WebSockets, or you are confident that you will not benefit from them, setting this variable with
DISABLE_WEBSOCKETS=1will explicitly disable WebSockets and forcibly resort to the fallback polling-mechanism, instead of trying to detect this automatically.
1 Like
I’d very much want to see this happen:
We should revisit how we factor MongoDB support into (1) the
server-side node.js driver [which you might use independently of
livedata, after all], (2) minimongo [ditto], and (3) Collection,
which is the class that glues the two of them to Livedata, but also
is generally the “public interface for newbies” to Mongo in the
Meteor universe. We want to allow the components to be used
independently, but we don’t want to overwhelm the user with
minutiae.
I’m soon about to start figuring out how that can be done, or if it can’t.
2 Likes
Hi @vikr00001,
I maintain activitree:push. In max. a week, the packages will feature webpush and PWA notifications.
Otherwise, when you think PWA what exactly are you looking for? The PWA graphic experience which already exists or the offline files/experience? I have an implementation based on this: https://github.com/timothyarmes/ta-meteor-apollo-starter-kit. As my main business is around a social platform and living in Dubai with 5G deployed in 10-15% of the territory and a very speedy 4G, anything offline sounds counterproductive for me.
3 Likes
Fantastic. By all means please let me know when this is released. I’m looking forward to checking this out!
1 Like
Although having 20 years experience in the field of IT, I have never been much of a programmer until last year when I decided to dive into Javascript (self-taught) and found Meteor. And it was like the holy grail. Everything worked (well mostly). And the reason I wanted to learn programming was that (as a non-dev) I wanted to build line of business applications in corporate environments without having to depend on devs.
I could see on this thread many good ideas on how to take Meteor better on a technical level. My personal advice to Tiny would be “maybe there is a different market segment which they may need to consider” (if it make sense at all). Let me explain further.
As a non-dev, my objective was to build line of business applications with minimal efforts. That meant that I needed out-of-the box:
- An authentication system for user accounts
- Role based access control
- Routing (including access control on routing)
- Multi lingual support
- An easy way to create database structures to keep my data.
BlazeJS was amazing at that. I tried my hand at React and a little bit of Vue too with Meteor but found BlazeJS the most user friendly for a non-dev who had minimal to average knowledge of HTML5, CSS and Javascript. My advice to Tiny would be probably to keep Meteor development but think about packaging a model of Meteor for non-devs which they can commercialise to corporate entities. And it’s OK if they take an opinionated approach to what can be done and cannot be done. Remember decades ago when Microsoft came out with Access. We started seeing a proliferation of user-built database systems within organisations. Business users don’t do that anymore because of the amount of effort and knowledge required to build web apps (and securing these webapps). Maybe it’s time for someone to step up and provide the non-devs with a way of developing apps.
Some commercial platforms exist out there (https://superdevresources.com/web-app-frameworks-non-developers/) but I don’t believe they provide the same flexibility and power that Meteor provides. So please don’t kill BlazeJS as I find it super easy to use for a non-dev to work with. Well, that’s just my humble opinion.
7 Likes