Meteor Raises $20M to Build the One JavaScript Stack to Rule Them All

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by applecore on Friday June 12, 2015 @10:06AM (#9705923)

It seems like a lot of these real-time capabilties should be part of the database layer, à la RethinkDB and its model of continuously pushing query results as they're updated.

This way, you're not locked into one JavaScript-based application development framework.

[ Parent | on HN ]

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by Lazare on Friday June 12, 2015 @10:35AM (#9706118)

CouchDB is possibly a better example, as you actually can have single-page applications connecting directly to the DB for streaming updates.

That being said, I think you're right: Whatever DB, server, or client tech you use, the real-time synchronization stuff seems like a minor add on.

Meteor seems predicated on the idea that you can't do synchronization with whatever random stack you want, but need to use Mongo as the DB, Meteor as the server, and Meteor as the client. This is kinda nuts; you can trivially do it with any tech stack. Postges, Express, and Knockout.JS? Sure, will work great. Firebase and React? Super. MySQL, PHP, and some jQuery soup? Yep. (Hint: Don't do that. But it'll work.) And with all due respect to the Meteor team, I think React or Mithril are much better frameworks than what they're developing.

Honestly, I feel like the Meteor guys have such a bad case of NIH syndrome that I'm always slightly surprisd they're using Mongo, and didn't write their own DB too.

[ Parent | on HN ]

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by twerquie on Friday June 12, 2015 @10:19AM (#9706010)

But you can't have clients directly connecting to the database, their sockets still need to flow through an application layer where you have your business / application logic. Unless you start putting application logic into the db?

[ Parent | on HN ]

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by enos_feedler on Friday June 12, 2015 @10:52AM (#9706236)

Your right about this. Couchbase solves it by putting a sync gateway in front of a couchdb connection. But this makes things hard to manage for the reason you mention: business logic inside your DB. All your rules about access control and users are actually derived from values in your couchdb documents. Its not pleasant to design or maintain.

[ Parent | on HN ]

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by zippy786 on Friday June 12, 2015 @10:37AM (#9706130)

Shouldn't business logic reside in DB inside stored procedures ?

[ Parent | on HN ]

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by cristianpascu on Friday June 12, 2015 @10:50AM (#9706212)

Only if DB runs JS. ;)

[ Parent | on HN ]

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by jmakeig on Tuesday June 16, 2015 @02:21AM (#9724098)

http://developer.marklogic.com/features/javascript

(Full disclosure: I work at MarkLogic)

[ Parent | on HN ]