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
Not yet. There is js-accounts, which cites Meteor accounts for the creation of the package. In essence it is suppose to be what accounts would look like without Meteor. There is also Passport for third-party authentication.
RedisOplog just needs to know what fields you modify, and it can achieve reactivity with ANY database. It’s actually quite easy to do this, we just did not have motivation to do it yet, as all our relational needs are satisfied by Grapher.
2 Likes
Yep. A plug and play accounts system that you can trust, and that integrates with Methods, Publications etc is still the biggest pull of Meteor for me. Along with the build tool, which, apart from speed, is a work of art.
I think the ‘plug and play’-ness is a core property of Meteor. It reminds me of Apple; you may not be able to do everything (Windows), but what is included just works. Like accounts, and dynamic imports when it was added.
In the future, regardless of what features or direction is chosen, I think it is key to preserve this.
5 Likes
You have to have a parser for SQL update queries. Then you can know which fields are modified in base tables. And then you have to be able to propagate changes to those fields through joins, aggregations, views, materialized views, and custom functions which can be used in SQL queries. Not to mention that updates can come from triggers, so you also have side-effects your SQL update queries can make.
So, unless you want to require users to manually specify how their SQL update queries propagate, it is not so easy. But would love to discuss this more somewhere else, if you are interested (to keep this thread on topic). I have been looking into this recently quite a lot.
You can limit SQL to just a subset, to make it more or less allow only what MongoDB allows, but I think one of main reasons why people want SQL support is to integrate with legacy apps, and to have features MongoDB does not have, and not just to have a different query language for MongoDB-like database.
2 Likes
If we have SQL functions and hooks at db level, it is much more complicated to do agreed. Let’s continue this discussion in https://github.com/cult-of-coders/redis-oplog/issues/341 so we’re on topic here as you said.
1 Like
Official package for Leaflet, I think it could really awesome!
@htchd7 @digitalx778 @mitar and @diaconutheodor
For several years already, vlasky:mysql has provided a reactive MySQL integration with Meteor. It is stable, perfomant and has been used in a number of enterprise Webapps.
Reactive queries are triggered by following the MySQL binary log. I have posted extensively about it on the forums.
6 Likes
@awilkinson Tiny should also feel free to let us all know how we can help during the transition and beyond to help make Meteor a successful investment for you guys and an amazing free to use tool for all of us. I am pretty new to the scene but I really enjoy spending my time in the forums, building hobby apps and growing my knowledge of Meteor, Vue, Node, Mongo as well as what is trending in the web development world. It would be sad to see that all disappear and I am sure I am not alone in feeling that way
5 Likes
Where I work, there’s concern about ecosystem lock-in. Using Meteor feels like building a Meteor app, not a Node app that uses Meteor as its framework. We already use Vue as our frontend, so Meteor is really only supplying the data layer and build tool; I tell people that it’s more appropriate to say it’s a Vue/Node app as Meteor-specific code makes up < 10% of the app. But still, the perception persists.
I think Meteor is an excellent choice for companies building internal apps, and I suspect that that’s a large segment of its usage. There’s no concern about scaling (though I disagree with the folks who still argue that Meteor can’t scale) and speed of development is often much more important than limitless flexibility. What would make Meteor an easier sell where I work would be:
-
Finish the job of splitting out all of Meteor’s parts into NPM packages that can be used with or without the monolith. This was already started with accounts-js, I think the next biggest target is LiveQuery, possibly depending on Apollo (discussed here). Then I truly can say I’m building a Vue/Node app, just adding LiveQuery the same way today I could just add Apollo.
-
Decouple the data layer from the databases, and support multiple databases with reactivity. So just as the client-side has a primary framework (Blaze) but other supported frameworks (React, Angular, Vue), the data layer could have a primary database (Mongo) but other supported databases (MySQL via binlog tailing, as shown by vlasky:mysql; Redis via oplog tailing, as shown by cultofcoders:redis-oplog; Postgres via triggers/listeners/other magic as shown by tozd/node-reactive-postgres). Supporting SQL databases is important for enterprise customers not just because of the mindshare that SQL still commands but also because hosting SQL databases is cheap and maintenance-free via Amazon’s RDS (Relational Database Service). Amazon supports RDS-like Mongo 3.6 via a service they call DocumentDB, but it’s very expensive (at least $200/mo) and therefore inappropriate for internal apps with only a handful of users.
Both of these suggestions have been on the Meteor roadmap for years. SQL support has been on the to-do list since the earliest days of development, back when it was a Trello board. Moving away from Atmosphere into NPM has been in progress for the last few years but progress has slowed as resources have dwindled. But both efforts are still good ideas, and completing them would breathe new life into the framework by making Meteor an option for those who currently wouldn’t consider it, and by making Meteor (or parts of it) an option for adding onto an existing Node app.
12 Likes
I find Mongo, DDP, Pub/Sub to be sleek and modern, whereas SQL DBs to be overly bloated and archaic. Reactivity was the principal feature to embrace Meteor. If I wanted to make a static site with MySQL or PostgreSQL, I would choose PHP or RoR. Or .NET for the “true Enterprise” (meh). Reading all this hype about Apollo is disappointing. Maybe instead it would be better to support more NoSQL DBs and/or better integration with alternative reactivity functionality like Redis oplog?
6 Likes
The hype around apollo blows my mind too. It’s nice, but compared to ddp? It’s like comparing ruby to java. It’s so verbose.
8 Likes
I agree, but sometimes other considerations dictate the architecture. Note that both MySQL and Postgres now support a json field type, so they’re inching closer to the conveniences of Mongo; and both can be made reactive. There’s a great opportunity here for a library to smooth over the rough edges.
2 Likes
From my observation dealing with Postgres at work (including all the tools available) and having own Mongo-based projects, it is like comparing Linux to Mac. While I respect Linux a lot, sometimes (most times?) I just want to be efficient and do not have time to build the binary from sources. This is exactly why I like DDP and Pub/Sub - it works, great, out of the box, and is heavily configurable. What else is needed? I would rather prefer to build great apps than port existing ones to every new hyped framework every 4 years…
8 Likes
Is there any SQL package MDG ever officially supported/validated?
1 Like
No, unfortunately. The closest ones that I’m are of are the ones I cited in my post. The MySQL and Redis ones have been used in production for years by various people.
1 Like
for now typescript support!
Already is in Meteor 1.8.2.
It is Relase Candidate version. and can not set tsconfig.json, right.
because I have tried 1.8.2 beta. my project need depend on another ts project. if unable to use tsconfig.json, it won’t work.
1 Like