The beginning of the end?

Planet Earth
1

Saw this on Hacker News - what will be the long term impact on Meteor?

2

Here is an excerpt from an interview with MongoDB CEO:

We didn’t open source it to get help from the community, to make the product better. We open sourced as a freemium strategy; to drive adoption.”

This might not be a popular opinion but frankly I think it’s a better business move, I’d rather see the companies managing those large code bases of semi open-source products profitable as oppose to going bankrupt (think RethinkDB), the DB space is very competitive and there is already large established open source projects. I personally would rather pay for my core tools and get better support and maintainability as oppose to getting something free and lower quality or unmaintained, the open source business model seems to work in some cases but fail in many.

As for Meteor, there has been desire to de-couple Meteor from Mongo forever. Perhaps it’s the beginning to start integrating Apollo and decouple Mongodb by default?

PS the gloom and doom, FUD, x is death, clickbait titles in this forum are getting really depressing and tiring.

6 Likes
3

Answer: this has no impact on Meteor whatsoever - It only concerns the standalone installation of MongoDB under Mac OSX.

Those who want a standalone installation of MongoDB on their Mac can install the .tgz tarball as per the official instructions instead of using the brew utility.

The Meteor bundle, which is self-contained, continues to work perfectly under Mac OSX.

I think someone needs to start an AA-like self-help group for people who get kicks out of spreading FUD.

8 Likes
4

Do you suffer from JS fatigue? Do you suspect your JS framework will die? Are you so hyped about the next JS front-end framework but have a real paying customers standing on your way? Do you’ve a “dead” script in your bundle.js? you don’t have to FUD alone, join us at www.antifud.js where we sit together and share our constant JS fears, uncertainty and doubts.

11 Likes
5

Hi Alawi,

As you know, my business has been using Meteor with MySQL since 2015 and I am the defacto maintainer of the Meteor MySQL integration.

On a technical note, we have not needed Apollo to make the integration work. We simply write the MySQL query results to a Mongo Collection, and select either one column, a combination of columns or the row index to be the unique Object ID for each row.

This simple mechanism has proven itself to be reliable, performant and compatible with all other Meteor client and server-side packages that read from Mongo Collection objects, e.g. Reactive Table.

In my view, this mechanism would work equally well for Meteor integrations with any other relational database or key-value store.

The only things for which we would desire MongoDB decoupling are the Meteor accounts packages.

7 Likes
6

Thanks for the clarification @vlasky.

I personally really enjoy your integration approach since it maintains the Meteor simplicity and doesn’t introduce any boilerplate.

I think your package Meteor MySQL integration is good enough for majority of the cases.

Thanks for sharing and maintaining it, is there something equivalent for postgres? how about redis-oplog integration?

7

For those who are interested in using Meteor with an SQL DB, I made a very simple example Meteor app having the following combination:

  • Meteor & Meteor accounts
  • SQL DB
  • Apollo
  • Apollo DataSources
  • Apollo Subscriptions
  • React-Apollo UI

There’s a lot of outdated example Apollo code on the internet, including official documentation that still hasn’t been updated.

Here’s an excerpt showing new syntax for initializing ApolloServer with dataSources and subscriptions:

const server = new ApolloServer({
    context: async ({ req, connection }) => {
      if (connection) { // check connection for metadata. Needed for Subscriptions to work.
        return { ...connection.context }
      }
      return { user: await getUser(req.headers.authorization) }
    },
    typeDefs,
    resolvers,
    dataSources: () => ({
      dsBooks: new DSBooks({ db })
    }),
    subscriptions: {
      path: "/subscriptions",
    }
  })

See it here:

1 Like
8

e.g. there’s outdated code about Subscriptions here: Introduction - Client (React) - Apollo GraphQL Docs

9

@vlasky’s MySQL package is amazing. Having played with it I can attest.
It’s funny to use mongo syntax client-side, but truth is, it works very well with JS
Anyone wanting something else can write their own driver easily or use Apollo

Has anyone tried DocumentDB yet? I am sick of us having to manage replicated instances of mongo ourselves (and Atlas and others’ hosting packages are cost prohibitive for our application)

10

FUD becomes the favorite weapon right now (though it has a long history) but with the spread of social media and internet usage it certainly has reached it’s all-time high.

As someone pointed out, FUD leads to higher clicks so the click-baiters use it a lot

3 Likes
11

How about an integration with Neo4j? Has anyone tried that? We do have quite some graph data that just fills out (costly) Atlas database and doesn’t allow us to run queries like we could do on Neo4j