Meteor 1.4 import syntax

[sean-stanley]

import { Neo4jDB } from 'meteor/ccorcos:neo4j';
console.log(Neo4jDB);

import { Neo4jDb } from 'meteor/ccorcos:neo4j';
console.log(Neo4jDb);

both of these return undefined in version 0.1.1

Your package.js says it exports Neo4jDB on the server. Is this actually what's going on? Are you able to update your package to support meteor 1.3+?

[ccorcos]

This package was definitely built pre-1.3 On Tue, Nov 22, 2016 at 15:02 Sean Stanley notifications@github.com wrote:

import { Neo4jDB } from 'meteor/ccorcos:neo4j'; console.log(Neo4jDB);

import { Neo4jDb } from 'meteor/ccorcos:neo4j'; console.log(Neo4jDb);

both of these return undefined in version 0.1.1

Your package.js says it exports Neo4jDB on the server. Is this actually what's going on? Are you able to update your package to support meteor 1.3+?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ccorcos/meteor-neo4j/issues/10, or mute the thread https://github.com/notifications/unsubscribe-auth/ABth32BpX-S_cgJ7Y0pUj4bdIJLoS_5Dks5rA3R-gaJpZM4K6DAR .

[sean-stanley]

Thanks for the quick reply. In your opinion, if I have a Meteor 1.4 project would I be better off using ostrio:neo4jreactivity or your solution? I know yours was made over a year ago now and ostrio seems pretty maintained.

[ccorcos]

depends what you're doing. ostrio:neo4jreactivity is most likely a terrible solution unless you only ever care about one single query because it copies all of the results into mongo. I would use feather.js

[sean-stanley]

Thanks for the advice, I've had a quick look at feather.js and it looks really promising but I can't really see how it lets you use neo4j reactively as neo4J isn't one of their main supported databases it's only edge supported with waterline. Have you used feather.js and neo4j with Socket.IO before? using neo4J over REST looks simple enough but it would be nice to have something close to real-time.

We would have maybe between 2-8 queries in our app with different dynamic properties fed in from search bars, and queries about relationships of nodes (the whole point of using neo4j instead of mongodb in my opinion).

On Wed, 23 Nov 2016 at 13:12 Chet Corcos notifications@github.com wrote:

depends what you're doing. ostrio:neo4jreactivity is most likely a terrible solution unless you only ever care about one single query because it copies all of the results into mongo. I would use feather.js

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ccorcos/meteor-neo4j/issues/10#issuecomment-262404338, or mute the thread https://github.com/notifications/unsubscribe-auth/ADoP7OuX4mrB_oq84pxvbMQ4KNB6Cxuqks5rA4UHgaJpZM4K6DAR .

[ccorcos]

The problem with Meteor is it gives developers the wrong idea about what "reactivity" is and the way its built with oplog tailing is not scalable. The way Feathers.js works is a cleaner way of doing exactly what I built with any-db.

Basically, you just have Feathers.js services that write to your Neo4j database (or any database for that matter) and you can use hooks to listen to events on those services which can trigger updates over web sockets to any clients that are subscribed. Its a bit more manual, but it allows the developer to determine what data should be reactive and fine-tune any performance considerations. You can scale your backend horizontally with a distributed messaging queue, and its just the right way to do it.