131–140 of 250 posts
I see this in example code: if (Meteor.isClient) { I don't get it. Are we shipping server side code to the client?
Relevant section of the docs: https://docs.meteor.com/#/basic/filestructure
We've built an enterprise/b2b app on meteor, and even through all of the hard yards, it's been a success & the right choice for us.
When I first heard about meteor, back at v0.5 or v0.6 - I watched the video from their home page, and thought it was full of buzzword bullshit. I didn't have a clue what it did.
I then ended up reading about how their latency-compensation API system worked [Meteor Methods]; And instantly knew that it was for me.
Having an API that simulates itself on the client, while simultaneously performing the same work on the server, is freaking awesome. (And then rolls back automatically if they don't agree).
If you are building a real-time, collaborative tool. Meteor is the framework.
That being said, there are a few questions about integration & scalability.
Opportunities to use Meteor:
* If you can make something small, eg. an internal tool [Free mobile app with cordova!]
* If it matches a certain feature of your app - and you can segment it based on URL (eg, it's a separate app)
* You're a sadist, and you're going to port your whole app to meteor...
* You're writing an MVP and you're going to scrap it later
* You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment].
Scalability:
* Client are always connected via websocket. Great for realtime data (no polling), crap for a website.
* As meteor instances are single threads, you can run multiple instances on the one server. Design you code for this (eg, don't store state in regular JS variables on the server - all has to be in the database). Load balance between them.
* Once the "client" has booted up. You can then connect to as many other DDP servers [backed by their own mongo instance, or the same mongo instance] as you like. This gives you the ability to segment your application based on your core feature. EG; if you're a monitoring app, shard your data by client, if you're a document app, shard by project. Have a central listing which tells them which server to connect to.
* Perform heavy lifting somewhere else. Plenty of "web workers" out there, or roll your own using Celery & Meteor-Celery package [shameless plug].
All in all. Meteor is great at what it does; and what it does, is going to be the next generation of web apps.
Congratulations on 1.0 but these kinds of buzzwordy lines Accomplish in 10 lines what would otherwise take 1000, thanks to a reactive programming model that extends all the way from the database to the user's screen. Really bother me. Show me where you eliminated 1000 lines of code and how it was beneficial. Each line of code, to me, is placed with purpose and intent. Are you eliminating thousands of lines of boilerp…
(Disclaimer: I work at Meteor) That box is referring to the data syncing, event handling, and view rendering code that you don't have to write when you use Meteor, compared to some of the previous generation frameworks. If you put together the right list of cutting-edge components like React, Firebase, Bootstrap, and some build tools, you might get a similar improvement in code simplicity. Our goal at Meteor is to gi…
(Not that that is the only requirement you might have.)
I just went through the tutorial on meteor.com, and I'm impressed with the speed of getting results.
When I were to build another online app, I'd split that in building the frontend and the API composed from microservices, so that I'd be able to offer access through the UI and the web API. Is Meteor a good choice for this approach?
seems like their selling point is data binding + client syncing. Considering I can do that with Ractive/React + Firebase, what's the advantage of using Meteor?
The way they handle client syncing is a bit different though. Meteor actually hosts a mini-mongo instance on the client allowing for better offline support.
Earlier quoted context omitted.
Okay, I'll bite: who is "We"?
"We" are providing a large scale application in the education space, with more details to follow. I am not able to give much more now, but I can say that given the contractual nature of our application, we've been fortunate to start out with a HUGE user base that has taxed Meteor and exposed its scalability issues more than most typical Meteor apps at this time. It's still young, and there are some significant advanc…
Earlier quoted context omitted.
"We" are providing a large scale application in the education space, with more details to follow. I am not able to give much more now, but I can say that given the contractual nature of our application, we've been fortunate to start out with a HUGE user base that has taxed Meteor and exposed its scalability issues more than most typical Meteor apps at this time. It's still young, and there are some significant advanc…
By “goads” do you mean “gods” (in, like, the Battlestar Galactica sense) or is that supposed to be “gonads”, as in junk? Just askin.
Src: http://www.jesus.org/early-church-history/the-apostle-paul/h...
In other words, if you believe that the Flux design pattern (which involves a central dispatcher as the only entity capable of updating the data) is sound, shouldn't you stay away from Meteor's model when building large applications? Or am I missing something?
The main concerns we had was scalability and reliability.
How does 1.0 address the previous concerns that was enough to abandon meteor.js altogether?