4 ms·

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 t

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.

twerquie 11y ago
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?
- deleted 11y ago
  [deleted]
- zippy786 11y ago
  Shouldn't business logic reside in DB inside stored procedures ?
  - cristianpascu 11y ago
    Only if DB runs JS. ;)
    - jmakeig 11y ago
      http://developer.marklogic.com/features/javascript http://developer.marklogic.com/features/javascript (Full disclosure: I work at MarkLogic)
- enos_feedler 11y ago
  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.
Lazare 11y ago
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.

twerquie 11y ago

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?

deleted 11y ago
[deleted]
zippy786 11y ago
Shouldn't business logic reside in DB inside stored procedures ?
- cristianpascu 11y ago
  Only if DB runs JS. ;)
  - jmakeig 11y ago
    http://developer.marklogic.com/features/javascript http://developer.marklogic.com/features/javascript (Full disclosure: I work at MarkLogic)
enos_feedler 11y ago
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.

Lazare 11y ago

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.