31–40 of 350 posts
EDIT: oh yeah, Backlift! (http://www.backlift.com) This is definitely an interesting trend.
Seems to have a minor glitch with unicode characters? When you do Colors.remove() everything goes away, but the entries with unicode all come back? Somewhat strange...
Interesting tech, but db access from the client scares me to no end, call me a curmudgeon I guess.
"You can use the database api on the client!" Does that freak anyone else out? Where are they doing permissions checking? Who can run what database commands under what circumstances?
Shared scratch databases with no thought to security seem to be the hot new thing these days ;P. CloudMine, Firebase, Parse, StackMob... people seriously seem to think it is perfectly normal to throw their public /and/ private API keys into their projects... I mean, check out this tutorial from StackMob: https://stackmob.com/platform/help/tutorials/ios_sdk
See https://parse.com/docs/data#security for more details.
Hey everyone! The four of us have been working very hard on this for the last six months, and we're excited to finally take the wraps off. Can't wait to hear what you think! We've got a lot more stuff coming over the next few months, and if there are particular things you'd like us to do/prioritize, I'd love to hear about them!
Interesting (and smart) that they post to Hacker News a couple of days prior to the launch of Firebase (which provided the realtime functionality used by MMO Asteroids and has been active at hackathons.)
We know the Meteor guys well and are really excited about what they're building. It's very complementary.
We're both advocating a new paradigm in software development and the faster it comes the better.
meteor
- Is a: webframework
- Depends on: node.js
- Comparable to: backbone.js knockout.js rails django
- Connects: ....Earlier quoted context omitted.
From the docs ( http://docs.meteor.com/#meteor_collection ): "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." So just for toys for the moment. Still, very cool...
Right. But as soon as you have this ability, don't you quickly turn off insert/update? then you throttle/contain reads... So in the end, do we benefit from having a client side database connection? I'm struggling to put together a real-world use case for one that isn't irresponsible.
The rationale is that clients typically end up doing sorting and filtering on subsets of the database anyway, as they get more sophisticated and start caching data. For example, Gmail starts to need a notion of an email message on the client, to avoid going back to the server for the same message. When I worked on Google Wave I saw firsthand the complicated plumbing you need in order to do this in an ad hoc way. (They used GWT to share the model objects, but synchronized the data manually.)
You can also separate this facility from your database completely, and use it as a way of sending "data feeds" to clients; then use methods as RPCs.