Trying to figure out how it works. And saw this in one of the paragraphs: > No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database So you don't manage a database, but what happens to the data. Can anyone trace an example, I don't, order or cart update from client code to persisting it on the back-end somehow? Does it use flat files...?
Meteor hits 1.0
41–50 of 250 posts
Re: Meteor hits 1.0
#42Trying to figure out how it works. And saw this in one of the paragraphs: > No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database So you don't manage a database, but what happens to the data. Can anyone trace an example, I don't, order or cart update from client code to persisting it on the back-end somehow? Does it use flat files...?
Re: Meteor hits 1.0
#43I'm still a bit unclear on what the target market for Meteor is. Is this just for small to medium sized projects, or is it intended to be used for large-scale projects as well? Since it seems like everyone wants to think of themselves as doing something huge, I'm sure the answer can't be 'no' to the second question — but I don't see any examples of significant projects being built on the platform. Actually, with that…
If you look at the main website there are 6 featured videos of real companies using Meteor in production.
Re: Meteor hits 1.0
#44I'm still a bit unclear on what the target market for Meteor is. Is this just for small to medium sized projects, or is it intended to be used for large-scale projects as well? Since it seems like everyone wants to think of themselves as doing something huge, I'm sure the answer can't be 'no' to the second question — but I don't see any examples of significant projects being built on the platform. Actually, with that…
You really have to build a meteor app from the ground up, so it is hard for established tech companies to get into Meteor when they already have spent years coding on another stack.
As new startups who use Meteor grow you will see those large-scale projects come about.
Re: Meteor hits 1.0
#45I'm still a bit unclear on what the target market for Meteor is. Is this just for small to medium sized projects, or is it intended to be used for large-scale projects as well? Since it seems like everyone wants to think of themselves as doing something huge, I'm sure the answer can't be 'no' to the second question — but I don't see any examples of significant projects being built on the platform. Actually, with that…
It's definitely a win for hackathons and getting a MVP out there that needs real time features. I can't speak much for large scale projects since I haven't had the fortune of reaching that scale yet with meteor, but I'd imagine it will be ideal for that eventually simply by extrapolating the current growth and improvement trends of the framework.
Re: Meteor hits 1.0
#46Re: Meteor hits 1.0
#47Trying to figure out how it works. And saw this in one of the paragraphs: > No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database So you don't manage a database, but what happens to the data. Can anyone trace an example, I don't, order or cart update from client code to persisting it on the back-end somehow? Does it use flat files...?
Currently it uses MongoDB, though (last I heard) there are plans for Postgres and possibly more, but it will have to work like MiniMongo on the client (i.e., no ORM, and mostly the same on server and client).
It's pretty much hassle-free though, especially with some of the community packages, such as collection2 and simple-schema.
Re: Meteor hits 1.0
#48I'm still a bit unclear on what the target market for Meteor is. Is this just for small to medium sized projects, or is it intended to be used for large-scale projects as well? Since it seems like everyone wants to think of themselves as doing something huge, I'm sure the answer can't be 'no' to the second question — but I don't see any examples of significant projects being built on the platform. Actually, with that…
It's definitely a win for hackathons and getting a MVP out there that needs real time features. I can't speak much for large scale projects since I haven't had the fortune of reaching that scale yet with meteor, but I'd imagine it will be ideal for that eventually simply by extrapolating the current growth and improvement trends of the framework.
https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s
Hundreds isn't really exactly "webscale", but I'm sure they'll iron it out, or it could have just been the application that was at fault. It's one data point however on how meteor scales.
Re: Meteor hits 1.0
#49Earlier quoted context omitted.
It's definitely a win for hackathons and getting a MVP out there that needs real time features. I can't speak much for large scale projects since I haven't had the fortune of reaching that scale yet with meteor, but I'd imagine it will be ideal for that eventually simply by extrapolating the current growth and improvement trends of the framework.
At last months devshop in SF a speaker discussed straining the system and reaching the limits of Meteor with just hundreds of simultaneous connections: https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s Hundreds isn't really exactly "webscale", but I'm sure they'll iron it out, or it could have just been the application that was at fault. It's one data point however on how meteor scales.
Scaling low-latency data synchronization is a challenge for scalability for sure! We are gradually building better and better drivers with persistence to MongoDB.
The scalability can vary greatly depending on your application's data schema, usage patterns and amount of writes.
If you watch the mentioned talk carefully, the speaker describes a collaboration tool with log replay with a lot of actions and running from a single box.
Re: Meteor hits 1.0
#50Trying to figure out how it works. And saw this in one of the paragraphs: > No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database So you don't manage a database, but what happens to the data. Can anyone trace an example, I don't, order or cart update from client code to persisting it on the back-end somehow? Does it use flat files...?
It's super-webscale MongoDB, of course!