If you want to keep all the reactivity goodness from Meteor I'd suggest taking a look at Firebase. Their new Cloud Firestore is very impressive and basically gives you all the features Meteor offers when you combined with a front-end framework like react or angular. Or you could take a more low-level approach and use something like Elixir/Phoenix and PostgreSQL's LISTEN/NOTIFY to create your own reactive push streams, and subscribe to them in the front-end using a reactive library like RxJS.

https://github.com/pubkey/rxdb

Tangent here, but I see this combo a lot and I don't understand what RxJS is adding to the equation on the front-end. What were/are your motivations for using RxJS?

I haven't come across a project using only React and RxJS though. There is redux-observable [1] if you haven't seen yet that combines Redux and RxJS.

[0]: http://redux.js.org/docs/introduction/PriorArt.html#rxjs

[1]: https://github.com/redux-observable/redux-observable

But since I now have you, you mention that "make reactive all the things" on the server caused newer developers pain? I've certainly had my fair share of developers initially being confused about reactive systems, but generally once they play with it, it "clicks" and they are mind-blown about the possibilities.

Would you mind sharing your experiences? So that way I can indirectly learn from your interactions and try to make things better, since I work on related systems.

e.g. can't query with age > 10 and have it sorted by age <-- (wrong example)

edit: see benjaminl's comment on the wrong example

CORRECT example: can't query with age > 10 and have it sorted by total_spent

It can do accomplish that query. From the docs a similar query:

  citiesRef
    .where("population", ">", 100000)
    .orderBy("population")
    .limit(2)

citiesRef.where("population", ">", 100000).orderBy("country")

is invalid...

EDIT: sorry got confused & posted wrong example (population/population vs population / country)

> Invalid: Range filter and first orderBy on different fields

But I can’t find any documentation on what exactly the limitations on orderBy are.

The reference docs on queries don’t mention any limitations on order_by: https://cloud.google.com/firestore/docs/reference/rpc/google...

Note that Meteor is much more than a data layer. Even though you won't find any easier system to deal with reactive data than their livequery system, I get that you don't want to be bound to Mongo or even need reactivity.

But it's also a server and build tool that has given our application:

- A stable upgrade path for almost 4 years where we could keep up with new ES features incrementally, with full backwards compatibility. In Javascript-framework land this is really unique. We've been able to keep adding features, expanding our product and building for our customers. While at the same time continuously update our codebase to the latest and greatest.

- By far the best easiest way to do code splitting (since 1.5) without any configuration or overlap in bundles. I don't know about any other tool that offers something similar. Webpack doesn't even come close in this area.

- Because they had node-fibers to get synchronous code from the start, now it's really easy to adopt to async/await.

- They have good integrations for React, Angular 1 & 2, Blaze and there are third-party integrations for Vue (haven't used that one myself)

- They're also the same people behind Apollo which people do seem to like for their data layer. And they announced Meteor will focus on full Apollo integration.

But yeah, their current data layer requires you to buy in to Mongo. And yes, there's no good separation of concerns in their data layer. And yes, the oplog tailing can't handle "facebook-scale" and I know you believe you need this. But picking this allowed our application (that needs a reactive data layer) to be delivered fast, gain customers and grow. Without Meteor, I'm pretty sure I would have ended up 2 years later with a nicer codebase and no customers.

TL;DR Have a look at their latest release (1.6), build a small application and chances are you might really like it.

I'm sure React webpack templates have the same features but I don't have experience there.

The meteor docs in general need more examples and best practices. The udemy course on meteor/react is extremely well done as a starting point.

[0]: https://github.com/zodern/meteor-up

The main motivator was that Meteor's big sell — the "zero-latency" data sync — wasn't enough to outweigh the overhead of having to keep up with the constantly shifting landscape of which libraries were now deprecated, which were suddenly "anti-patterns", which were suddenly insecure...

That being said, I still prototype all new projects with Meteor. It's by far the fastest to go from 0 to 60, and it's extremely pleasant to ignore data transit and focus on the Big Ideas.

tldr; Prototype things in Meteor because it's a great platform. Your production stack may or may not need the same things your prototype stack needs.

I inherited a vendor-built website that was Craft CMS (a Yii framework) sitting atop a Laravel application that was integrated with Google Maps and indexed by Solr -- debugging even a minor issue could take days.

Meteor is fast and full-stack, no more knitting together 13 different frameworks. It's integrated with Apache Cordova, so you can easily port your website to mobile apps. It supports importing of node packages. Is Meteor the answer for everything? Of course not. But for a fast, data-driven app it's still great, IMHO.

The alternatives recommended in this thread so far are:

1. Firebase + React/Angular

2. Elixir/Phoenix + PostgreSQL's LISTEN/NOTIFY

3. Deepstream.io

4. Kotlin

5. .NET Core

6. Vue and Rails

If those things work for you, great, but I'm not sure they're 10x better than Meteor or that MDG is in some kind of death spiral -- it's still a viable solution for fast NodeJS apps.

It sure does claim to be.

Promotion/marketing speak is promotion/marketing speak.

You might like Elm. If you also control the backend you may want to look into PostgREST (there's an Elm lib for it iirc). See also `elm-mtl`.

You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things.

Just build a react app, and add a websocket layer wherever possible.

Still, I wouldn't use Meteor for any kind of traditional website. It's way too easy to introduce state on the server, but there shouldn't be state on the server, and it's way too easy to abuse reactivity and end up with a toy that tanks with trivial traffic.

I think polling is ultimately a better model because it allows each component to throttle itself at whatever pace is necessary. I can see Meteor being useful for applications that require a shared state on the server (or in Redis or something) like in online games, chat, or any other online multi-user real-time application.

But then Meteor became a tool for common websites that didn't actually need reactivity, and people started abusing server state, reactivity, etc. I think at some point, the community was begging for options to turn reactivity off by default or in certain cases.

Meteor apps consume less data but take up a ton of server resources. Overall, the problems introduced by polling were just traded for DDP's own problems. The problem of "sending data to the client in real time" might not even be an important problem. If the client looks at a page every 20 seconds, then there's no reason for the page to be updating for an empty audience.

I think Meteor is building something called Apollo now which uses some sort of intermediary caching server to keep track of data versions, which the client then polls for updates to the data it depends on. At a first glance, it looks like they just took the problem with DDP and moved it into an independent system. I could be wrong, maybe their polling solution would end up fixing the issues.

Apollo is a library for GraphQL, primarily client side but there's also a server component (sort of like ExpressJS for GraphQL). While GraphQL also includes real-time web-socket based subscriptions, they are an extension rather than the core, and, in practice, most clients/servers (including Apollo) use polling to fetch updates because it requires a much simpler server architecture.

Which backend framework should I use?

I need to implement OAuth Gitlab auth -_- Do I have to implement Implicit OAuth2 Flow?

It sounds like you have no specific requirements for the backend, so don’t waste time thinking about it, just pick something and go.

They are updating it like all the time with new features.

The biggest problem with it is that the data layer does not scale well for large apps, and that has tainted the reputation of Meteor as a whole.

However, there are community packages on the way to fix it, and hopefully Meteor will implement MongoDB's new Change Streams feature, which essentially puts the reactivity on to the database.

I'm still holding my bet on Meteor, having recently launched an admin panel tool for it: http://meteorcandy.com

* WeKan - FOSS Trello clone https://github.com/wekan/wekan

* Rocket.Chat - FOSS Slack clone https://github.com/RocketChat/Rocket.Chat

* Vulcan - React, GraphQL & Meteor toolkit https://github.com/vulcanjs/vulcan

* 4Minitz - FOSS Collaborative Meeting Minutes and Protocols WebApp https://github.com/4minitz/4minitz & https://www.4minitz.com/

Disclaimer: I'm one of the contributors of 4Minitz. ;-)

This sounds like a huge advertisment but I simply thoroughly enjoyed using meteor. If it fits your use case I'd say go for it. You can build the frontend in react and re-use it should you decide to move away from meteor. The amount of backend code you need to write to make all the realtime stuff work is significantly less than with other frameworks, so not much in terms of sunk cost there.

Over the years, I've built the equivalent of those real-time systems using postgres, redis, rabbitmq and node that can scale horizontally. It's obviously longer than using firebase, but at least I know what's going on under the hood, I can easily optimize and debug it, I can add any missing features or switch any tools (I.e. can easily switch off postgres to something else if I needed it).

It's for the same reasons that I use React on the front-end. It's great for the view layer, but I still get to pick and use great libraries for the rest of the app (in-memory database, state management, routing, etc etc.) I can easily switch off React to something else because the surface API that I'm using is extremely small.

I would still use meteor or any of the competitors for a hackathon or prototype, but never for a long-term project. YMMV

I've considered a lot of things, but I couldn't find a setup as simple as Meteor with database integration. I ended up going back to Meteor and I'm very happy with it.

The tooling keeps getting better (recent 1.6 release), server-side rendering is almost there (already possible but no clear best practices yet), and scaling seems like it will be getting better soon (MongoDB upade + a path toward GraphQL with Apollo).

I had my doubts but I'm back on board. I recommend every JS developer give Meteor a good look.

Meteor, today, is still a good match for small to medium applications that provide real-time features in more than 50% components/pages. For most applications Meteor becomes a real pain in the ass. I wrote several applications for multiple clients, in 4 years I haven't wrote a single one that used the real-time features properly. A tradicional stack is simply much more flexible when compared to Meteor.

The problem today is that Meteor is not a component that you can't easily plug and play like Angular, React, Express, etc. Example: You would like provided a real-time widget on another website? Open an iframe and load the entire application and waste more than 300 megabytes on the browser. Or use a non-official package and hack the shit out of it.

MDG (Company who developed and maintains Meteor) went too greedy. In order to use Meteor you have to be fully committed to the stack. Although the project is open source, you will waste several hours trying to modify Meteor to be make it more modular. Event today if you want to use the DDP protocol outside of Meteor, you've to use 3rd party non official packages. Meteor was great in the beginning but failed to play nicely with the rest of the JS ecosystem even although some work was done in that direction. Arunoda played a HUGE role by building and writing a lot.

As a prototype tool Meteor is excellent, it's very hard to find a framework/tool that provides what Meteor provides. Building a real-time application with modular components isn't trivial, Meteor just offers a lot for free: LiveQuery, Authentication, Server-Client shared code, Consistent API, client side implementation of MongoDB (minimongo), painless build system, easy deployment, etc. You can build a prototype in record time.

Play with Meteor, you won't regret it. Scaling applications is always hard, requires in depth knowledge and time. Meteor is websocket based, there is not need to compare with an HTTP based API since it is unfair. Scaling a real-time application is hard on any language/framework. For most projects FireBase will do the trick if you've a small number of real-time components.

My advice: Pick the right tool for the right job. Most of the complains typically come from project that are not a decent match for real-time applications. I worked on many project because someone decided to use Meteor regardless of their technical knowledge to decide so.

I have, at a high level, looked at the Apollo project and I think they are beginning to become more modular. So the direction is good, but it no longer has the selling points that it once had: it's no a longer a one-size-fits-all solution.

I just couldn't get onboard with something I couldn't plug SQL into. A psql adapter never came.

https://github.com/wekan/wekan-postgresql

https://github.com/torodb/stampede/issues/203

IMHO Meteor is not a thing, as it builds on a wrong assumption: At the heart of Meteor is modeling your data, and it basically builds upon a CRUD approach. This is perfectly fine for very simple use cases, but it doesn't work well for more complex things, because limiting yourself to create, read, update and delete limits your expressive power dramatically.

In contrast, when we designed and developed wolkenkit, we put the verbs into the center of the development process. With wolkenkit, you model processes that describe what your application does. This way, wolkenkit is a pretty good fit if you do domain-driven design (DDD), but you do not need to do DDD to use wolkenkit.

wolkenkit gives you the option to focus on your domain expertise, and provides all the technical stuff below, such as persistence, authentication, real-time updates, and so on…

We built it based upon CQRS and event-sourcing, so you have a pretty good foundation for scaling and reporting / analyzing data. As it's only for the backend, you are free to use any UI framework you want to use, but we have a client-side SDK for JavaScript to assist you.

You can find more information at https://www.wolkenkit.io/ and in its documentation https://docs.wolkenkit.io/1.1.0/

If you just want to get started with the concepts, have a look at our 68-pages brochure on DDD, CQRS, event-sourcing and wolkenkit: https://docs.wolkenkit.io/1.1.0/downloads/brochure/

wolkenkit is available as open-source and under a commercial license. If you have any questions, feel free to contact us.

PS: At first, wolkenkit feels somewhat strange, if you are not used to CQRS, event-sourcing & co., but once you get it, I think it is a pretty good approach to developing software.

I think most of the value you’re describing through correctly modeling behavior to language is only important at the level with which most teams deal with data—and this isn’t necessarily the DB level. Just like our brain may use (relatively crude) bio mechanical processes to encode & recall information, yet at a higher level of abstraction relies on the flexibility of natural language, to codify and transmit meaning between idea storage systems (people), I think a similar process is at place with programming. Let the low level stuff stay low level and optimize for performance/throughout and not meaning, then in the higher order aspects of code make sure the abstractions that are most used by teams map data to constructs which humans use to communicate meaning.

I think this approach can be found in any framework, including meteor through effective abstractions, as nearly all frameworks give you the necessary mechanisms to map data. I think the issue with ineffective language systems is mostly the same reason people hate poetry. Most people have a difficult time adequately mapping ideas to language, because it is extremely difficult to do it correctly to the satisfaction of others.

This pretty much shows how Meteor sees data: It's a "thing" that can be created, edited, deleted. That's it. It does not live on its own.

E.g., when you design a shopping cart, you can create a shopping cart, you can update it (which means adding items to it, or removing items from it, or changing the numbers of items in it, …), and you can finally delete it (when the user submits their order, or when they cancel their shopping tour).

What you can NOT do is to access your data using the verbs that are relevant for your domain:

- Put an item to the shopping cart - Increase the count of a specific item - Decrease the count of a specific item - Remove an item from the shopping cart - Discard the shopping card

For the domain "shopping", all these actions are relevant, and if you have to map them to CRUD actions, you lose semantics. What's even worse, update and delete are destructive actions, so you don't have any historical data. Of course you can implement all this, but you have to do it on your own.

wolkenkit, in contrast, uses event-sourcing, which works more like Git: Changes are collected, and you can replay them (either all to get the current state, or some of them for arbitrary analytics).

That's IMHO a major difference on whether you are using a CRUD-like foundation, or another approach.

We have also blogged about this: https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co... and https://www.thenativeweb.io/blog/2017-11-01-11-13-ddd-and-co...

However - isn't that essentially creating another layer on top of MongoDB? It looks like this could be implemented as a library for Meteor.

I'm only saying that to clarify that I do not think it's Meteor CRUD versus this. I think of Meteor more as a boilerplate than an application framework.

The releases since 1.3 have definitely pushed it in the right direction:

* NPM instead of atmosphere

* React/Vue/whatever instead of Blaze

* ES Modules (import/export syntax) in place of global variables everywhere and a dependency loading system that i-shit-you-not came down to loading things in alphabetical order

* ESNext support

* Getting Node and NPM up to current LTS versions

Next stop on their roadmap is integrating Apollo, at which point it'll basically be a turnkey system for building React/Vue apps on top of GraphQL. Most of what originally made Meteor what it was will have been removed in place of sensible best practices that everybody else in the JS world has since moved on to.

But for me the sticking point is that Meteor is built on a couple of assumptions that, in my humble opinion, are fundamentally incorrect.

1. Focusing on writing code that runs on both the server and the client is a useful idea.

2. MiniMongo is a sensible way to handle the data layer and reactivity everywhere is helpful.

I personally reckon these are both crappy ideas, and combined with the "magic" parts of the framework, they encourage people who are new to full stack JS to develop bad habits and skip learning some of the real fundamentals that every developer should know in relation to security, performance and scalability.

No matter what poeple say about Meteor, the fact remains that having the ability to live push data to the frontend, and share code between client and server, with absolutely no extra work is supper appealing.

Meteor projects are quick to ramp up but the second something goes wrong it's just a nightmare. Code is not structured at all, strange packages to do things that fall by to the sides, performance issues that are hard to track/debug.

Testing is still a third-class citizen in Meteor for some reason. The official guide mentions testing, but in the four times I've tried to follow it over the course of a year, I could never get it to work properly.

On the flipside, using Elixir and Phoenix you know exactly what's going on and why, you have real control over your DB queries. You can benchmark properly. Your tests are 100% real and accurate, and run properly. It's much better. You sleep better at night that's for sure.

I say this as someone who has used Meteor for multiple projects and used to love it!

Here is my humble opinion: If you aren't writing business logic, and will do mostly network programming, try Go. If you are doing something enterprise-y, use Kotlin or (IMHO even better) .NET Core. If you want to like writing code, try Elixir with (on?) Phoenix (or Django/Rails depending on your love affair with Python/Ruby).

Huh? :)

I actually like JavaScript more than many typed languages but I don't like writing a server that runs on an event loop. Again, preference.

ps. You seem to be downvoted, I tried to compensate by upvoting. It is just a tease with a smiley at the end. Relax, people.

Thanks..

> It is just a tease with a smiley at the end. Relax, people.

Indeed, what's wrong with these people! :-P

(I was a dynamic typer myself, but changed sides when learning about strong typing, especially in FP langugaes)

    ▪Clojure backend
    ▪Clojurescript frontend page
    ▪Rum (react cljs lib)

you can just use react+node js. works great together and will be lot easier to solve platform issues when they come

What do you use for forms and other items that have packages in the blaze ecosystem?

- Meteor uses MongoDB as a data store

- You write queries on the server called "publications", that make documents available to the client

- The client implements "MiniMongo", which basically lets you query the documents that have been published via your publications using Mongo queries as if you were writing them straight from the server

- The publications are (by default) reactive, so whenever any of the documents in your queries is added/removed/modified, the changes propagate instantly to your client.

- The original view library (Blaze) would seamlessly update with these changes in your UI.

From memory, the performance bottlenecks here are:

- It uses the Mongo OpLog to determine when changes have been made to the collections, which makes the queries themselves quite slow.

- For every dataset published to the client, Mongo keeps a cache of that dataset on the server so it knows when it needs to send deltas over the wire.

So for both of these reasons, once your queries get big, they get SLOW.

The other thing that is costly (but not fundamentally a fault of Meteor itself), is that most people building web apps model their data in relational terms. If you try and apply that to Mongo, (ie, treating collections as tables and "joining" across them instead of nesting data hierarchically inside your documents), you'll end up writing slow queries.

* It's a project with a strong community (364 contributors) that still has traction among developers (+ 8 stars by day on average over the last month, check the numbers here https://bestof.js.org/projects/meteor)

* They keep moving in the right direction: moving away from their own package manager (https://atmospherejs.com/) to NPM, accepting ES6 syntax everywhere, client and server-side without config, enabling AngularJS or React for the front-end layer... Since Meteor 1.6 version, they use under the hood one of the latest versions of node.js.

* Other contenders with such a combination "no config / real time / full-stack JS" features out of the box have less traction (check some contenders here https://bestof.js.org/tags/fullstack)

Some great projects on GitHub are built on top of Meteor:

- https://rocket.chat/ a clone of Slack chat app

- https://wekan.github.io/ a clone of Trello app

- http://vulcanjs.org/ "The full-stack React+GraphQL framework"

The drawback is that the Meteor is quite opinionated about a lot of things, it's a monster of its own, blurring the boundary between client and server-side code. It can be difficult to debug, test, deploy and scale.

So there is no definitive answer about the question "Should I use it in production?".

The team behind Meteor is really committed to keep on moving forward, GraphQL and Apollo support are coming soon, the post about the latest release gives interesting insight about their vision: https://blog.meteor.com/announcing-meteor-1-6-abf30f29e2c6 The author said that, at the end of the process, "Meteor may look less like a framework and more like a library of middleware that can be used in any existing application, JavaScript or otherwise".

One important thing is that they move forward steadily, without breaking things, which is important when you run applications in production.

I think it's important to know it's application and use-case. I use it for a hybrid iOS/Android app, and Meteor + Cordova has been fantastic in terms of developer productivity for a small/medium-sized app. As a startup, I wouldn't consider anything else right now for new projects. React Native has a higher learning overhead, and with other architectures you always have to deal with user registration & authentication, something Meteor supplies out of the box.

In terms of performance, it is important to understand the core concepts of Meteor. This is not easy. The reactivity layer and publish concepts make it extremely easy to overpublish data, reckoning your Meteor app completely useless. Afaik, something like Kadira is required for Meteor apps, as it will quickly tell you when something is wrong. If a Meteor app is correctly designed, it should rarely have performance issues.

I've wanted to integrate Redux into my Meteor app, however there are a lot of moving parts getting both working together, so I'm opting for smaller container components. React performance is tricky in any case, and Meteor + React is no exception. This combo makes it a bit difficult to diagnose performance issues on the rendering layer. I would love to migrate to VueJS, however the it would require a complete re-write, just as I'm getting comfy with React. I would highly recommend VueJS + Meteor + Vuex over Meteor + React for new projects, so you don't deal with diagnosing rendering performance problems with Meteor's reactivity layer.

You can definitely run your own React stack that is decoupled. For a larger app, I would recommend going this route, due to the big build system of Meteor. Once your app gets a bit too large, the builds still take forever. You can offset it by using something like React Storybook with hot module reloads, but if you have a high number of users or a requirement to not use Mongo, you are better moving the other way. Meteor Development Group is moving out of the built-in reactivity layer that it is known for, and into GraphQL. I'm not planning to move to this new architecture anytime soon, and will run with Meteor's reactivity layer for the foreseeable future. I'm concerned once the reactivity layer loses focus and development, that Meteor may start to fade away. GraphQL has a high learning overhead IMO and presents it's own sets of issues. Perhaps those will be worked out over time.

My 2c. Without Meteor I wouldn't have a real-time web app as nice as I do now with both iOS and Android builds, up and running as quickly and easily as I have. It's been a godsend.

It's is easier to find developer for Rails and Vue.js

Regardless, deepstream seems pretty awesome.