I too am surprised that MDG did not make a big story. As I am somewhat involved I know some bits and pieces. First, MDG mentioned in the past that its core customers on Galaxy were not interested in scalable reactivity. Secondly, they offered the author to write a blog post. He’s been busy and so have i (i was supposed to review it).
To answer the point on Apollo, last I checked, scalable reactivity was not a main objective, but a potential by product. I think in itself redis-oplog is the solution as it uses redis (so that you can use mongo as a dB). As long as you like livequery and mondo, this solution is solid.
@manthony I’m the “creator” of redis-oplog (along with many awesome people from the community), and it’s not a temporary solution, it simply scales. But there are other problems with Meteor that made them search a new Data Layer: locked reactivity to MongoDB, every Meteor project’s API is different, not much support for different databases, no self-documentation tooling, complex to properly use Meteor’s client outside Meteor.
I’ve been studying Apollo & GraphQL in depth for the last month. Long story, if you believe it’s complicated it’s because it wasn’t explained properly, heck, we thought Meteor was explained badly so we created http://www.meteor-tuts.com. I’ve held a presentation this Saturday on Apollo & GraphQL, in 1 hour people were already super familiar with it, and they could start their own project from scratch and use it. I’ve been reluctant in the past to learn it in depth because I thought “it’s complicated” and “Meteor is so simple”, but I realised it’s actually not complicated at all, and no-one would stop me from using Meteor whatsoever.
Keep in mind that Apollo is a facade, it’s not the business logic/implementation layer, it’s an API language. Much like doing RPC, this is why going Apollo doesn’t mean switching away from Meteor, nor avoid using it’s great tools.
I am now playing with ideas to make a package that would make Apollo use Grapher’s sheer power, and make use of RedisOplog to have painless reactivity in Apollo & MongoDB, because currently, to do that, it’s a bit too much boilerplate.
I don’t think Graphql is difficult. We intend on using it going forward but not necessarily with Meteor. I thought I had read it would facilitate a different pub/sub system of its own and hence have its own solution to scalable reactivity. Perhaps I read that wrong.
Is Meteor -tuts up to date including best practices for rightnow? I guess one of my other frustrations is due to bad timing I always came to update my knowledge of where Meteor was at a time when the docs and tutorials were not up to date (as admitted on these forums).
Yes, meteor-tuts is up to date and we’re actually planning on releasing a new update for it soon. GraphQL has a solution to scaleable reactivity because it doesn’t rely on MongoDB oplog (which was the main pain point).
The name/concept “Meteor” seems to be overloaded and it’s meaning different thing for different people. I think there’re three concepts here:
Meteor as a Full Stack: if you started before 2015 or follow the Blaze tutorial, then you’re using it and it comes with Blaze, mini-mongo, tracker, DDP, many Atmosphere package etc. This stack is a league on it’s own in terms of speed and simplicity of development, great for starting quickly because you’ve all the layers of a web app integrated, perfect for learning, prototyping and small to medium size production apps.
Meteor as a Backend: if you started after 2015, switched blaze to other view layer and followed the guide with validated methods and minimal pub/sub usage, you’ll end up with this architecture. Here we’re using meteor build system and RPC methods powered with DDP but the client has been replaced with something like react, vue, angular, etc. If you don’t have complex API, integrating with only one client, and have few data sources and using mongo as a DB, yet you might change to something else in the future, then this is a great option to start with.
Meteor as a Build Bool: this is the closet you get to plain node.js project and this is how Vulcan.js and other frameworks are being built on top of meteor, they use meteor to primarily package and compile their files and maybe the accounting system. Most of development effort by MDG over the last years has been (in my opinion rightly) placed here, along with Apollo. The data layer can be rest, but who will go back to rest after DDP, so most likely it’s GraphQL and probably Apollo.
The fact that we’ve these options today, and that you can start with one and evolve to another is why I think “Meteor” as platform/ecosystem is much better now. These are not mutually exclusive options and I think they should all be embraced by the community since they really serve different segment of the market.
With regards to vue, again I think it should get the same level of love as react/angular and we’re not too far off. Better vue support willl surely increase meteor’s adoption as a backend and a build too along with Apollo.
I love your post, just have a beef with this for “Meteor as a Full Stack”:
We have a “large” production app and are still using Blaze. We haven’t faced issues yet, so the imperative to switch to Vue is not urgent (but remains important) as our focus is on adding new features and covering more use cases. But … we are not outsourcing our development (except for one project with @diaconutheodor) so are not suffering from lack of UI expertise (not to mention that it’s easy to pick up).
This is the main thing… At the end of the day, even vanilla node apps get stuck with something… vue vs angular vs react OR feather vs next vs express OR oauth vs passport vs firebase accounts vs whatever… if you use meteor + apollo, then really you can leave it pretty easily if you actually ever need to do that. You grab webpack and switch you accounts to something else… not fun but hardly not the end of the world.
Let’s be real, you are going to “need” to re-write your app in the new latest and greatest thing in a few years… it doesn’t matter what you choose.
Let’s be real, you are going to “need” to re-write your app in the new latest and greatest thing in a few years… it doesn’t matter what you choose.
Maybe the hope is, if your app’s tiers are properly abstracted and concerns isolated, then you can rewrite certain parts of your app without having to rewrite the entire thing. No?
@GeoffreyBooth 2 months later is the savior of CoffeeScript still trying to use Meteor with Vue? Using CoffeeScript perhaps? Last time I asked you how your debugged your meteor coffeescript code you answered using Chrome Dev Tool.
But I just can’t manage to have it let me put breakpoints where I want inside the <script lang=coffee> ... </script> section of my Vue components. Most line numbers in the CoffeeScript code are disabled and among the few that are abled most put the breakpoint at another line that the one I clicked on. sometimes in comments or blank lines, 10-15 lines away. This is profondly frustrating back to debug with console logs
Do you think it is:
an akryum:vue-coffee meteor package problem?
a coffeescript meteor package problem?
a Chrome dev tool problem?
Do you have a solution for that?
I must say that the number of transpilers between the source code and the code executed in the browser is becoming overwhelming:
Coffee -> ES6
ES6 -> ES5
Vue component build
Meteor build
how many source maps are needed for all this stuff and how to properly coordinate their interaction?
I think it’s a akryum:vue-coffee problem. I think the bug is that .vue files usually have a structure like this:
<template>
<!-- . . . say 20 lines of HTML here -->
</template>
<script lang="coffee">
# First line of CoffeeScript code, but line 25 of the .vue file
My hunch is that vue-coffee sends the CoffeeScript code through the transpilation pipeline without adjusting the sourcemaps for the fact that, in this example, the code starts at line 25 instead of line 1. That should be fairly easy to rectify, I just haven’t devoted the time to it. Please feel free to do so (and let me know if you do, so I don’t duplicate your effort).
My workaround has been to just throw debugger statements in my code:
<script lang="coffee">
import { mapState } from 'vuex'
export default
name: 'some-component'
data: ->
debugger # Chrome DevTools WILL stop here
You need to remember to remove them later, but they’re full-fledged breakpoints, not the limited printing you get from console.log. The debugger statement is core JavaScript, and has nothing to do with Vue or transpilation.
Solid point! I made this point in a post a while ago: that MDG was repositioning in the hope of getting acquired by Facebook, hence the official support of React, even when it seems obvious of Vue superiority.
Your hunch seems correct. After I externalized the <script> part of my Vue component to a separate .coffee file I can now not correctly set the breakpoints inside of it in Chrome Dev Tools.
Do you stick to manual debugger statements anyway to be able to put the breakpoints at the correct level of nesting and hence block scoping in the CoffeeScript code which is not possible by just choosing a line number in an IDE for those single CoffeeScript lines that exit multiple block scopes through multiple outdents?
I don’t have a one-size-fits-all solution. If I have the code open in my editor, I’ll add a debugger statement. If in DevTools, I’ll set a breakpoint (if it lets me). I do whatever’s most convenient in the moment.
Sorry but I am still waaaaayyyyy too closer to zero than to hero to try to fix any part of the quite overwhelming (to me) tech stack that I am currently still merely evaluating the viability/practicalilty:
recent ES6 and CSS stuff to understand the docs and examples,
VSCode + Chrome Dev Tools to understand how to debug this whole enchilada,
Visual Studio Team Service + Git + Github to control versions and collaborate,
and I haven’t yet looked at the all important testing stuff (Mocha, Chai, Sinon, Chimp and God knows what else I will need to learn when I dive into it)
nor at cloud deployment (Galaxy? Node Chef?)
nor at mobile (Cordova) and desktop deployment (Electron)
So now that Meteor is in some new leadership hands, we can probably start to spread the love again! I’ve been using @akryum’s packages for Meteor + Vue and it is an amazing combination. Please sponsor @akryum on Github if you use these packages and love them as much as I do. Let’s bring the Meteor & Vue communities together.
I created skeleton files awhile back but don’t have time to contribute right now. Here’s a link if anyone wants to open an issue and add them to the latest Meteor version for a PR.
for Meteor + Vue and it is an amazing combination. Please sponsor 