Has anyone seen DDP used outside of Meteor? https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP...
Although, there are various DDP clients for other languages as you can see here: http://meteorpedia.com/read/DDP_Clients
81–90 of 163 posts
Has anyone seen DDP used outside of Meteor? https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP...
Although, there are various DDP clients for other languages as you can see here: http://meteorpedia.com/read/DDP_Clients
I think the primary focus on further development in Meteor should be supporting additional databases officially, and after that, supporting operational transformation and conflict resolution strategies come to mind. In my opinion, they are the biggest hurdles towards creating reliable real-time applications. Official React or Angular support isn't a game-changer. They can already be integrated easily with the reactiv…
Has anyone seen DDP used outside of Meteor? https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP...
Not trying to sound like a jerk, but I'm just wondering is it really a good thing to put on your homepage that there are nearly 12K questions posted on StackOverflow about Meteor? Seeing a number like that makes me wonder if maybe the documentation and or APIs are not very well done if it's generated that kind of activity on SO.
It means the community is very at it and its a place to go if you have a question and don't want to dive into the docs
Alot of people do prefer personalised answers over the effort of finding it in docs, sad reality.
Earlier quoted context omitted.
Do yourself a favor and set aside a weekend to go through this book: https://www.discovermeteor.com/ All of your questions are answered there.
It's not cheap and I can't even find a table of content for it. I've also read excerpts that dealt with autopublish etc, and they didn't really address the point I'm making. Is there a benefit to using meteor beyond the fast prototyping? I'm not saying that's not potentially a huge benefit, but once you're done with your prototype, I still feel like you have to rewrite the whole thing.
What I don't understand with Meteor is how you can build secure applications if you actually write your database queries in the front-end. Can someone enlighten me? How do you hide logic or prevent people from manipulating however they want?
1. You can write allow/deny permissions rules to allow only certain modifications: http://docs.meteor.com/#/basic/Mongo-Collection-allow
2. You can not use client-side modifications at all and instead write all of your database code inside Methods, which are basically supercharged RPCs that give you automatic optimistic UI updates: https://www.meteor.com/try/10
I think this issue comes up a lot because new Meteor apps come with the "insecure" package by default to enable faster initial development and debugging, but most or all production apps will remove this package.
(I work at Meteor)
Earlier quoted context omitted.
https://github.com/meteor/meteor is open source, so the community will be tasked with maintenance in the case of MDG running out of money.
When Meteor is no longer commercially viable and runs out of venture capital brewed hype-juice everyone will jump to the Next Big Thing and companies that listened to their Meteor evangelist will have to furiously find someone to port from Meteor to ANYTHING so they can continue to build features and support new services. Bless me with your downvotes Meteor zealots! I'll still be here when Meteor is has gone the way…
Beginner question: how does Meteor handle storing server-side web socket connections in a scalable way? Are they kept in ram? Redis? Mongo's ram? The complexity of this is why I always end up reaching for hosted WS solutions like pusher or fanout.io.
Why is this complex? There are so many ways for pub/sub implementations. However I always ended up using Playframework for WS, since it's really really easy to set this up in a scalable way.
It's not something you need to worry about for small applications, but for a scalable architecture, it's important to know the details of how this works. What happens to Meteor (or Play) with 100k simultaneous connections? How much ram and how many servers will I need? How do I load balance WS data between them? Will another datastore like redis be required? If so, how does it integrate with the framework? What if I outgrow a single instance of that datastore?
If I use pusher, I don't have to think about any of this.
I looked into Meteor and it's amazing how everything clicks together. It's just such a drastic change in complexity and feels like a breath of fresh air. The one thing that made me drop it as the choice for a primary stack was the fact that it's tied so heavily into MongoDB. Meteor has a mongodb 'server' replicated client side, that's how they can actually make Meteor so god damn snappy, it's latancy compensation. If…
I've heard the sales pitch for ember and ember-cli and I've seriously begun developing with Ember for the past 2 weeks. So far, I really like the tooling around Ember but am not a huge fan of the actual framework itself. I mean, you have routers, routes, controllers, views, templates, and components - how many concepts do you need to display a ui? Maybe it's just that I can't see the forest through the trees. Perhaps…