CODEWITHSUNDEEP
javascriptpostgresqlmeteor
veingrow
veingrow

Reputation: 15

Meteor JS + PostgreSQL

I have a PostgreSQL 9.5 & meteor 1.4. I want to select data from db and show it in the browser console.

For meteor & SQL I use this package https://github.com/storeness/meteor-postgres.

I want to show data of db in the browser console in the real time. e.g my db is [9, 5, ..., 5]. After user came to site we add some data [9, 5, ..., 5, 6,7].

So in the console we have [6,7] I'm newbie, how can I do that?

Many thanks.

Upvotes: 1

Views: 1562

Answers (1)

CodeChimp
CodeChimp

Reputation: 8154

I assume the question is "how do I get reactivity using Postgres"? I will try my best to answer this based on the knowledge I have, but please keep in mind:

  1. I do not work for MDG so the depth of my knowledge on what they are working on is limited to what they have publicized.
  2. I am basing this on MY knowledge, which comes from hands-on experience with a few Meteor-based projects.
  3. Things in the JS frameworks world have been changing SUPER fast, so there may be things out there that I just didn't know about. I am relying on others to fill in here where I may have a lack of knowledge.

So, the short answer: Under current Meteor, as far as I am aware, it is not possible to have reactivity out-of-the-box with anything other than MongoDB.

Now, long answer is a little more complicated. You can write your own code to monitor the SQL server's operations and setups up the pub/sub through DDP yourself. I have some demo code in git that I did for a Meteor Meet-Up in Tampa that dove into how to hack at DDP through Pub/Sub. It's really not super-hard to do the DDP part. The hard part would be to get the reactivity setup on your SQL server of choice...in this case Postgres.

To map things out, here is the basics of what you would need to do:

  1. Implement some sort of custom code that gets events triggered when Postgres gets updated. This code should be intelligent enough to know what tables are updated and which ones are being used in your pub/sub, so that it will update only when needed.
  2. Use the events from #1 to drive your publication. Here is where you could either get nifty and track the data rows OR simply send all rows upon each update. If you choose the first option you will need to somehow reconcile the changes to what's been sent so you can publish the deltas. If you choose the second option then you will still need to track what results you sent to remove them all through DDP. Either way, it seems daunting. Joins and sub-queries might be near impossible to handle
  3. From the client, we would need to simply subscribe to the publication. The client would use mini-Mongo same as before.

No matter how you slice it, it's a tough process to code. MongoDB was used in Meteor mostly because it's Oplog made tracking changes very easy, and since it's not a relational DB they didn't have to worry about the joins/subqueries issues.

The big complication comes in the form of Apollo, which is a HUGE project from MDG to re-vamp how Meteor does reactivity. Apollo is said to decouple Meteor from DDP and MongoDB, and be less pub/sub-ie and rely on GraphQL. I haven't really looked into it much, so I can't really give you details as to what any of that really means in the grand scheme of things, but the big take-away is that if you can wait it might be able to solve some, if not all, of your problems. On the flip-side, many people would say "don't count your chickens before they hatch", i.e. don't expect something that hasn't been released/delivered to solve real problems you have now.

Upvotes: 6

Related Questions