281–290 of 350 posts
1. Running complex DB queries on the client
2. The in-memory database cache described in the documentation using a lot of memory
3. Having little control over how often the client hits the server and vice versa.
It seems as though it has combined automatic polling and asynchronous updating together, and has removed traditional controllers and models. Yeah, it's cool out of the box and yeah, it's great for scaffolding and rapid development.
But really, it seems like another stack to learn and completely depend upon, and with codebase that 'liquid' it seems like it's much riskier than doing things traditionally. I'd be worried that it auto-injects into the running app.
Don't get me wrong — it's amazing. But what's the real, actual benefit here?
Does it scale to really heavy javascript pages? Do you have any benchmarks on when it starts to breakdown in terms of performance? Also have you built a "solid" production app with it?
Is GPL really viable for a web framework? The Free Software Foundation has consistently held that linking to GPL code (not LGPL) is derived work.
Earlier quoted context omitted.
> I now need to buy-in to the entire (framework) mindset to progress which slows things down That's interesting, that idea could be folded into the technical debt metaphor. So, by taking on a library or framework, I get a head start by just using it, but take on the knowledge-debt of not really knowing how it works. And when you get to the edge of what it can do, you either pay off the knowledge debt by learning how…
Yeah, said much better than I could. I don't regret any of the time spent with these frameworks because it really broadens your horizons and makes you think in new ways. Lots of the techniques I've seen now make regular appearances in the versions I roll myself. Other ideas I've completely rejected. Eg. ORMs. A few years ago they seemed like a godsend. In reality they simply shielded me from the basics of SQL and wer…
An ORM also seems to lower the amount of configuration it takes to get development databases synced. It's not as much of an issue for an experienced dev, but a designer or new team member would need help.
I have had to learn AREL, the relational algebra used by ActiveRecord, in order to do more advanced queries. That's analogous to learning SQL in more detail, but I'd still take that in a heartbeat over writing raw SQL. The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.
Earlier quoted context omitted.
Such a great question. I spent a lot of time working with ExtJS having been lured in by all those great, straight out of the box components which had their own healthy dose of added magic. Fast forward a year or two and suddenly when I need to do anything that is non standard then reality kicks in. I now need to buy-in to the entire (framework) mindset to progress which slows things down (because it doesn't necessari…
> I now need to buy-in to the entire (framework) mindset to progress which slows things down That's interesting, that idea could be folded into the technical debt metaphor. So, by taking on a library or framework, I get a head start by just using it, but take on the knowledge-debt of not really knowing how it works. And when you get to the edge of what it can do, you either pay off the knowledge debt by learning how…
With client-side DB access, and eventual consistency baked into the platform as a core feature, you can't just throw "if current_user == object.owner" in your controller and call it a day. I'd love to know what they're thinking here.
Certainly you could go with a row-level security scheme like CouchDB has, where you attach little javascript snippets to your database that check security. But then how does the client verify? Maybe you can just assume that only malicious users will ever bump into security problems and so client-side verification is unnecessary.
If auth is baked into the framework, then maybe they can give you basic row-level security for free by maintaining a user table with auth tokens that's only accessible on the server side, and passing the auth token along with every database request, and maintaining a meteor-controlled owner key on objects. But that doesn't help if your security checks are more involved. I.e.: "if object.owner.friends.includes?(current_user)".
I'd love to hear what they're planning for this.
I'm surprised no one is talking about the glaring hole, which is security. It's apparently on the developers' short list of high priority features ( http://stackoverflow.com/questions/10100813/data-validation-... ) but it doesn't seem like a trivial addition. With client-side DB access, and eventual consistency baked into the platform as a core feature, you can't just throw "if current_user == object.owner" in your c…
I'm surprised no one is talking about the glaring hole, which is security. It's apparently on the developers' short list of high priority features ( http://stackoverflow.com/questions/10100813/data-validation-... ) but it doesn't seem like a trivial addition. With client-side DB access, and eventual consistency baked into the platform as a core feature, you can't just throw "if current_user == object.owner" in your c…
From the doc: "Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality."
I'm surprised no one is talking about the glaring hole, which is security. It's apparently on the developers' short list of high priority features ( http://stackoverflow.com/questions/10100813/data-validation-... ) but it doesn't seem like a trivial addition. With client-side DB access, and eventual consistency baked into the platform as a core feature, you can't just throw "if current_user == object.owner" in your c…
Anything can be made to look easy if you're ignoring real-life issues. Heck, you can do seamless client updates by refreshing all the pages on my website every second. It will be inefficient, but it is easily doable.