I have vented my frustration on many occasions in various threads about the issue. Here are some of them:
The Sad State of Web Development
Meteor for corporate developers
Getting results from aggregation
Do you recommend meteor for financial service…?
That looks interesting. So there would no longer be any need to write all those tedious import statements at the top of each file. Have you tried it?
Correct. You will need to define how undefined variables will be imported via the config. Haven’t tried it myself though. And you will need to run eslint --fix to make esllint add the missing import statements. Which is a bit tedious perhaps…
Hm, we might be able to create a default config for all Meteor core packages. That would save a lot of people time when transitioning from 1.2 to 1.3+…
The funny thing about this is that some random guy has already created a solution for this called DEC64 (repo), and he’s also on TC39 …
1 Like
I know about dec64 but it didn’t go anywhere, though I sure wish it did. Maybe benjamn and doug can team up and push for it to be implemented into ES.
3 Likes
Tossing in my 2 cents.
I would really love to see built in support for AWS dynamo. I know you have just recently started to enable other databases, I think dynamo should be top of list.
Other lower priorities:
Could meteor interact with AWS Lambda?
Create a simplified webhook interface for subscribed webhooks and creating webhooks.
Definitely been stated above, but:
- ability to turn off reactivity (make it easier. pub/sub is CPU intensive and not necessary most of the time.)
- support for more databases.
- fuller mongodb support. e.g. aggregate, findAndModify, batchUpdate (the first two at least are addon packages.)
- ability to not use certain files depending on the meteor settings or env vars.
- ability not to use it as a single page app at all times
Rock solid documentation!
No commits that add any change/enhancement to the way something existing works or that add any new feature without rock-solid documentation of the change! And I’m not talking about a mention in HISTORY.md. If it is not a bug fix and it is significant enough to bother making the change in the first place, then the feature deserves documentation at docs.meteor.com.
Who told you that? Not true. Many of us use reactivity.
And if you don’t want reactivity, just get the data instead of the cursor.
Apollo?
What does that mean? During build time exclude your files since env vars are used at build.
Did you check out the the WebApp module? You can send your HTML manually.
Yes. Apollo will help with points 1 and 2. But it doesn’t exist yet.
Who told me that? Using Meteor apps for the last two years, I can tell you most people don’t need full reactivity most of the time. But that’s not even the point. Yes, there are other ways around it, but they’re not always the easiest to use.
If you ever try scale a Meteor project, you will see the need to make things unreactive and remove some of Meteor’s power. And yes, Apollo really will help with that.
Point 3 - how do you exclude files from the build?
@elie, thanks for your reply.
Reactivity is only available in your app if you use it. If you don’t use reactive variables or cursors, you are dealing with raw data. It’s like saying I don’t want an AC in my car. Well, then, turn it off and enjoy the heat / cold 
You an also remove a few packages if you don’t use reactivity ALL the time.
Our App is scaled with 4 workers on 4 cores and 8GB of RAM. So we have experienced first hand the challenges of reactivity. We use server observers for server-side reactivity and are loving it (and we can always get the raw data if we don’t need reactivity). On client-side, we use reactivity on most things, and raw data when we know the input is fixed.
To answer the excluding files bit, I can’t know your scenario. But let’s say you don’t want a certain file, in your build script, you simply move it out (or rename it to something else), build, then restore. This means you are building multiple apps from the same code, which is highly unusual and can’t expect it to be supported as mainstream.
Hope that helps.
Actually, Apollo exists and is already quite usable. It’s still considered to be in Technical Preview phase, but everything has been maturing nicely. Give it a shot - you’ll be impressed!
3 Likes
4 instances is small scale. Yes… You won’t need to turn off reactivity ever at that scale. And if you ever run into issues, you just stick up another instance.
And again I wasn’t saying it’s not possible to send data through Meteor methods. It is. It’s just not as easy.
And yes, I’m happy Apollo is coming along because it does set out to solve a lot of the issues.
Having a look now @hwillson.
You can use methods to get unreactive data.
I have been envolved in many different projects for big companies and the reason why they declined the offer to build their websites on meteor is because meteor just works with no-sql databases. And for example you will not tell them that all database infrastructure needs to be changed just to use meteor.
Will be awesome if we can create the compatibility of meteor with SQL lenguage and be able to use Oracle, sql server and many others SGBDs.
I think that we can improve the image and participation of meteor in many development ideas for big companies increasing in a stupid but big amount the requeriments of meteor developers.
1 Like
-
build-in file system (upload them to public file, compression, resize, crop and more for images, all in one)
-
cordova -> react native
-
build-in seo (easy way to seo, like changing meta tags and more)
-
build-in testing (automate testing without time from developer and depended on third-party packages will be cool)
-
build-in rest apis (easy way to create rest apis)
-
Galaxy some other subscription model or system? i like to have all my apps, websites and maybe some can be static all host them in galaxy but a way to not paying app/container. Like paying 25/month for a static website its not ideal
-
Database host on galaxy too? I know there are a lot of options to host a database but i like all in one platform