Doesn't work with Meteor 1.4.1.2

[csillag]

Doesn't work with Meteor 1.4.1.2

[clayne11]

Well I don't have any issue with Meteor because I have completely side-stepped the Meteor build tool.

I bundle the front-end with webpack, then copy the client bundle into the Meteor /public folder. Then I intercept the client requests and serve my own page using express middleware. I'm now only using Meteor for the data layer and to serve static assets, but it doesn't serve any code to the front-end or bundle front-end code at all.

[clayne11]

@csillag I don't have an exhaustive list but here's a quick one from memory:

Deficiencies of asteroid:

• OAuth doesn't work with Meteor
• no batching of DDP subscriptions (causes big performance problems)
• doesn't handle unsubscribe / resubscribe without receiving a callback from the server
• doesn't handle multiple subscriptions to the same subscription with the same params
  • you need to count subscribes / unsubscribes and only unsubscribe when all of the subs has unsubscribed. The asteroid implementation expects only one subscriptions with the same params will be active at a time
• doesn't handle any of the accounts calls except login (changePassword, resetPassword, verifyEmail)

If I get around to open-sourcing my client I'll post it here.

[menelike]

slick and valid solution!

[csillag]

I uses graphql subscriptions. Compared to Meteor live data with mongo, it's a nightmare.

You can think of it as a hammer, compared to a brush-less rotary drill.

[clayne11]

Unfortunately this project is pretty much abandoned. There haven't been any commit in 4 months.

[csillag]

Unfortunately this project is pretty much abandoned.

Are you aware of a replacement?

[clayne11]

I personally just finished migrating my app to webpack.

I'm still using Meteor for the backend / data-layer but I've completely migrated my front-end to webpack. I started off using the asteroid client but I ended up essentially rewriting it and adding a lot of missing features.

I hope to be able to open source my DDP client at some point because asteroid lacks a lot of necessary features.

My front-end now has absolutely no requirements on any Meteor packages so that I can build using webpack and completely avoid the Meteor build tool for front-end code.

[menelike]

Last time we used webpack we had a lot mambo jambo with babel as Meteor uses it's own babel libs which also needed to be added per npm (great overhead, great npm folder footprint). After all, server restarts went crazy and we switched to HMR (for now).

[csillag]

@clayne11 wrote:

I hope to be able to open source my DDP client at some point because asteroid lacks a lot of necessary features.

I would be interested about that. Two questions:

1. Do you have a writeup somewhere about what are those missing necessary features?
2. Where do I watch for the release of your DDP client?

[jadus]

@menelike are you still using hmr with latest meteor version ?
I get the same errors as @csillag
Did you find a workaround ?

[mattblackdev]

@clayne11 I'm curious what stack you're using these days?

[clayne11]

webpack / GraphQL / React. We completely finished migrating off of Meteor a couple months ago.

[mattblackdev]

@csillag Did you go with apollo? I'm also looking into migrating off meteor. I test drove building the whole stack with Apollo v2 and now I'm looking at apollo-link-state for replacing redux/mobx client side state. It seems the more experienced meteor community is going this route, following MDG's lead. What do you think?

[clayne11]

We are using apollo, yes. I'm looking at starting to move towards using apollo-link-state as well.

[yorrd]

Has everyone transitioned away from Meteor here? I'm wondering,

1. is reactive data not worth enough to stay with Meteor? I haven't found any real alternatives. What about (almost) hassle free mobile app building?
2. What solution are you guys using for those two features? I'd love some input 😃

Also, we as a team have the resources to theoretically get this moving again. Are there still people who would help test this or even support us if there's somebody who knows the code well?

@gadicc are you still available to answer basic questions about the structure of the code, the way it works and some simple pointers where to start looking for changes? Do you recommend updating this incrementally through all Meteor versions since two years ago or just update the project to 1.8, see what breaks and fix it?

This repo really feels like honest and true open source. I love it. I love what has happened here and it really makes me sad that it has slipped away.

[mattblackdev]

Peanut gallery here, I would test it! I think the folks using Meteor today don’t mind Meteor’s current rebuild speed so much anymore. But I still wish for proper HMR sometimes. Thanks, Matt

…

On Jan 8, 2019, 5:02 AM -0500, Yorrd ***@***.***>, wrote: Has everyone transitioned away from Meteor here? I'm wondering, 1. is reactive data not worth enough to stay with Meteor? I haven't found any real alternatives. What about (almost) hassle free mobile app building? 2. What solution are you guys using for those two features? I'd love some input 😃 Also, we as a team have the resources to theoretically get this moving again. Are there still people who would help test this or even support us if there's somebody who knows the code well? @gadicc are you still available to answer basic questions about the structure of the code, the way it works and some simple pointers where to start looking for changes? Do you recommend updating this incrementally through all Meteor versions since two years ago or just update the project to 1.8, see what breaks and fix it? This repo really feels like honest and true open source. I love it. I love what has happened here and it really makes me sad that it has slipped away. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[gadicc]

Hey @yorrd, will be happy to help however I can (and thanks for all the kind words!), but quite a lot of time has passed... concerned about what could have changed in meteor's internals and also how much of my memory has faded since then. But let's see :D

Look first at the scripts directory. In theory you can update the last-upstream-commit file (to the commit sha in Meteor repo of the last stable release) and run diff-upstream to see what's changed in the packages that meteor-hmr is based on and replaces - it's what I'd do between meteor releases to see what I'd need to update to keep working. That would be where I'd start first, but additional work may be required if other parts of the Meteor build system have changed which this project relies on / assumes.

Note also this only works for client-only code. Any changes in server / shared code will cause a complete Meteor reload. That was kind of an end point for me, because at the time Meteor reloads were super super slow. I believe they're much much better now.

To answer your other questions, I'm mostly using create-react-app these days. I miss Meteor every day to this day, but felt things went down hill when they started catering to "everyone" (angular, react) and stopped developing blaze, minimongo and all their original stuff that just worked so magically together. Wanting an active ecosystem I went with react + graphql, noting also that majority of MDG's investment (in time and staff) was moving to Apollo (and away from Meteor).

I have to also make special mention that although (as far as I know) MDG only has 1 person still working on Meteor itself, benjamn is easily equal to a full team; his code and work is exceptional and he really is the only reason why I was never able to write off Meteor completely.

Oh and lastly, even though it doesn't compare to the original Meteor experience at all, the new React Hooks make a lot of things in React a lot less painful now.

[mattblackdev]

Wow I couldn’t agree with @gadicc more!! Well said about everything! Thanks, Matt

…

On Jan 8, 2019, 8:25 AM -0500, Gadi Cohen ***@***.***>, wrote: Hey @yorrd, will be happy to help however I can (and thanks for all the kind words!), but quite a lot of time has passed... concerned about what could have changed in meteor's internals and also how much of my memory has faded since then. But let's see :D Look first at the scripts directory. In theory you can update the last-upstream-commit file (to the commit sha in Meteor repo of the last stable release) and run diff-upstream to see what's changed in the packages that meteor-hmr is based on and replaces - it's what I'd do between meteor releases to see what I'd need to update to keep working. That would be where I'd start first, but additional work may be required if other parts of the Meteor build system have changed which this project relies on / assumes. Note also this only works for client-only code. Any changes in server / shared code will cause a complete Meteor reload. That was kind of an end point for me, because at the time Meteor reloads were super super slow. I believe they're much much better now. To answer your other questions, I'm mostly using create-react-app these days. I miss Meteor every day to this day, but felt things went down hill when they started catering to "everyone" (angular, react) and stopped developing blaze, minimongo and all their original stuff that just worked so magically together. Wanting an active ecosystem I went with react + graphql, noting also that majority of MDG's investment (in time and staff) was moving to Apollo (and away from Meteor). I have to also make special mention that although (as far as I know) MDG only has 1 person still working on Meteor itself, benjamn is easily equal to a full team; his code and work is exceptional and he really is the only reason why I was never able to write off Meteor completely. Oh and lastly, even though it doesn't compare to the original Meteor experience at all, the new React Hooks make a lot of things in React a lot less painful now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[yorrd]

Thanks guys for taking the time out of your day to respond.

@mattblackdev lovely, thank you. I'll cc you if and when we have something workable.

@gadicc

thanks. I'll try sorting out the differences for now and play around a bit at first. Client only is a big improvement over no HMR. Rebuild times are ~30 seconds for us. That's completely unacceptable for reasonable development. So we have to do something. This looks like a valid option.

You are right, benjamn is a beast. I'd just wish MDG made some clearer statements when it comes to which direction they're heading. I see their resources are invested in Apollo, but I don't know what will happen to live data. Will there be an Apollo replacement or not? If so, I would switch, if not, I won't. Will Apollo replace Meteor or be a data solution within Meteor (as it is right now)? 1.5 brought a lot of performance improvements, but (in my humble opinion) only made things so-so from being horrible. So many questions that could easily destroy a lot of the commitment we're putting in setting up our own ecosystem for the team... Oh well, you're not the guys to cry to about so let's focus on what we have 😃

Anyways, I'm glad you're still responding to this issue and will report back when I have something interesting to show :)

[gadicc]

Great stuff! 👏

Re live data via Apollo, yes, you can do it via "graphql subscriptions". Haven't done it personally but it's part of the spec, Facebook use it for their live updates, and I'm pretty sure Apollo supports it. Amazon App Sync, which uses Apollo under the hood, supports realtime queries (and offline support!!!!) through AWS cloud. So yeah, it's totally possible, not sure how it will fit into Meteor though.

(Disclaimer: haven't used any of it myself, about to start an AppSync project this year so we'll see how it goes. As far as I know, it's still not a "live query" though. You do your initial query and then subscribe to a "subscription", which is event based -- you need to manually do something in your update queries to tell the API which subscriptions are affected, as I understood it. It's a pain but it scales well on normal databases).

Good luck and thanks for your enthusiasm to breathe life into an old dear project.

[gadicc]

oh and ps i actually quite appreciate your report back from someone within the Meteor community, which is still quite dear to me :)

[gadicc]

@csillag, would the eventual @live (instead of @subscribe) solve these issues for you? (hope I got that right) i.e. other than subscriptions, do you like working with graphql?

It looks like mongodb are launching their own version of "minimongo", complete with scalable cloud backing. At least that's what it sounds like here. https://www.mongodb.com/products/mobile Haven't played.

[yorrd]

@gadicc @LiVe sounds like a good idea, but it's still SUPER verbose to do a @LiVe query compared to Meteor's DDP.

The mongodb minimongo thingy seemed like it's not going to be a self-hosted solution or did I read something wrong?

[gadicc]

@csillag, @yorrd so what is the ideal here, something like this?

import React from 'react';
import gongo from 'gongo-client';
import { useGongoLive, useGongoSub } from 'gongo-react';

const todos = window.todos = gongo.collection('todos');
todos.insert({ title: 'client' });

function submitTodo(e) {
  e.preventDefault();
  const form = e.target, input = form.children[0];
  todos.insert({ title: input.value });
  input.value = '';
}

function TodoList() {
  // Reactive realtime live query (of local db / subscription) using React Hooks
  const todos = useGongoLive( todos.find() );

  // Tell the server to keep us up to date as long as component is rendered
  useGongoSub('todos');

  return (
    <div>
      <form onSubmit={submitTodo}>
        Title: <input type="text" />
        <button type="submit">Add</button>
      </form>

      <ol>
        {
          todos.map(todo => (
            <li key={todo._id}>{todo.title}</li>
          ))
        }
      </ol>
    </div>
  )
}

export default TodoList;

[yorrd]

@gadicc uhh wow. So is gongo internally creating a mini-mongo instance? I presume gongo is your private project at the moment since I can't find it anywhere? Is it really a live query or is that logic hidden behind this API?

This is looking exciting!

[gadicc]

heh, "project" might be an overstatement. really missed this part of meteor and found the alternatives frustrating, but promised myself I'd stop doing so much open source and do more real work, and use just what everyone else has been using successfully. but just the few comments above were enough to break the camel's back, felt I had to at least to play around a bit and see what came out.

so it's mostly just a bunch of different experiments at the different layers, mostly super basic code to test the flow, and still deciding if it's then re-use existing meteor code or do things a bit differently. but yeah the model will probably land up very similar, mongo stype API on the client, pub/sub, etc. what do you mean real live query or hidden logic? it uses mongo change streams on the server side.

i'll public the repo when i've done a bit more work. but trying to pace myself and not get carried away :) probably most helpful is to know your best and worst parts of the meteor experience. from what I recall, the developer experience was awesome and it was scaling that was the biggest problem. client performance, which I felt was from things being reactive-by-default and people not having a good understanding of that (gongo would be very easy to opt-in to live queries, but it would be clear that that's what you were doing). somethings that would still remain would be lack of easy way to do joins, lack of other databases.

open to better names too :) i was like "mkdir what". hehe. gongo = gadi mongo. working name :)

[gadicc]

actually i guess we can move this to gongojs/project#1 and stop polluting this issue. it will be a while until this is really usable but i put another fun screenshot up on the README :)