Apollo + Meteor: which features exactly are coming in 1.5?

[aadams]

It’d be like a cracked out transpiler.

What is a transpiler?

[sashko]

Please elaborate.

Which one makes it clearer what will be fetched from the server?

{
  post(id: "5") {
    title
    content
    author {
      name
    }
  }
}

Or

<div>
  {{#let post=post(id: "5") }}
    <h1>{{post.title}}</h1>
    <p>{{post.content}}</p>
    <p>Posted by {{post.author.name}}</p>
  {{/let}}
</div>

Of course, you could write a tool that would take the second and show you the first when you ask. We should perhaps try both and see what we like. But then, what do you do with:

<div>
  {{#let post=post(id: "5") }}
    <h1>{{post.title}}</h1>
    <p>{{post.content}}</p>
    <p>Posted by {{fullName(post.author)}}</p>
  {{/let}}
</div>

I guess we now need to go look at the implementation of fullName, or disallow custom transformations.

Anyway, I think it’s good to dream - that’s how I started this! So let’s see how far we can get with template analysis. You could imagine a runtime system that would simply detect property accesses on objects, and dynamically add them to the original query, until all of the accesses are fulfilled!

In fact that would probably be the easiest way to try it out - no static analysis needed.

[msavin]

I don’t think I’m the right guy for the job

So, a transgender operation converts a male to a female or vice versa. Similarly, a transpiler can convert one kind of code to another. That’s how we can write ES6 in Meteor and have it work with environments that only work with ES5.

[aadams]

Anyway, I think it’s good to dream - that’s how I started this!

That’s a very humble comment, you’re a good man.

[aadams]

If you don’t mind @msavin, please speak to @sashko’s points in order to fully flush out your ideas?

[msavin]

I’m going to pass on this rabbit hole, but thanks for trying to faciliate a discussion!

[aadams]

I’m going to pass on this rabbit hole

I was simply trying to get you to elaborate on the argument you put forward:

The build tool can parse the template file, extract all the data fields necessary, and then bundle a query into the app code files. It’d be like a cracked out transpiler.

And about speaking to @sashko’s replies, I’m not suggesting anything off-handed I can assure you. I just wanted to flush out your ideas (which seemed reasonable). I’m very sorry if you feel I called you out somehow.

Note: I have a lot of respect for you. I use your brilliant Meteor Toys Pro tool and use it often.

[sashko]

I think the stuff Max is suggesting is 100% doable! Didn’t mean to shut it down.

[msavin]

I think we developed a layer of miscommunication here, but given the build up here’s my take on it:

When you write code in Meteor, the actual code you write doesn’t necessarily become your application code. The build tool takes what you wrote and then compiles it into an application. So it doesn’t even have to be a ‘real language’ under the hood, it just has to be something that the build tool can take in and then generate the app with.

You can see a case of this with Vue; they went on to create their own file type: https://vuejs.org/guide/application.html#Single-File-Components

Their .vue files are not usable in real world environments. When you write your file, the build tool will take it and then convert it into something the browser can read. So, implementation specifics aside, we know we can do ‘magic’ here as long as its logical.

You can also see the case with something like JSX; it takes your HTML template stuff and then converts it to a JavaScript implementation (IIRC). So the idea here would be to add one more step to the process and basically figure out what data of the component needs by inference. In this context, code is just a string of text, and you can do virtually anything you want to it.

Whether you infer the query or specify it up front, a lot of it has to do with preference and execution.

[msavin]

I was simply trying to get you to elaborate on the argument you put forward:

For the record, what you said was actually quite different:

If you don’t mind @msavin, please speak to @sashko’s points in order to fully flush out your ideas?

I don’t mind going back-and-forth over ideas, but I also don’t want to provoke a competition over something trivial. I hope you understand.

[aadams]

I don’t mind going back-and-forth over ideas, but I also don’t want to provoke a competition over something trivial.

Sorry, the miscommunication was my fault.

Your ideas around this snippet of code is what I was hoping you’d flush out with @sashko, not if it is possible or not to convert this code with a transpiler.

Not a fan of mixing logic and views to that degree… however, I think this can be even easier:

<template name="stuff">
  <div>
    **{{#each post in allPosts via GraphQL}}** <!-- focus is here -->
      <h1>{{post.title}}</h1>
      <p>By {{post.author.firstName}} {{post.author.lastName}}</p>
    {{/each}}
    <button onClick={{addPost(id = post.author.id)}}>Add post</button>
  </div>
</template>

The application should be able to infer how to construct the query.

It would be great for Blaze to have smart interface into GraphQL, one that fits in with its current constructs. I think a discussion like this is important and timely considering we’re on the cusp of the GraphQL age.

If you are the maintainer of the Blaze-Apollo integration, you can make it look however you like

And if I might add, I think you’re just the right guy to build the bridge between Blaze & GraphQL.

[msavin]

Well, if this is serious, I’m always reachable I’d have to study a bit first. Thanks for clarifying!

[marbemac]

Yes, this! We’re moving a huge chunk of our subscriptions over to plain old HTTP calls to a simple read-only API. Upon receiving the data back from the API, we upsert everything into local meteor collections, so that the rest of the app (which relies on the minimongo reactivity) still works, and we can still take advantage of the nice query API in minimongo. In order to make that work with allow/deny, we had to do something like this:

export const Workspaces = new Mongo.Collection(Meteor.isClient ? null : 'workspaces');
export const Projects = new Mongo.Collection(Meteor.isClient ? null : 'projects');
... etc

We still use redux for local, ui-related state. Re-branding minimongo as a reactive local cache with a nice query api is very interesting.

[suhaila]

MDG whatever you bring with 1.5 please for god sakes make meteor stable and changes incremental not whole sale changes. I couldn’t care less about graphql or node 6. What we as product development company need is that the system should not become unstable after just a single release or the whole way of writing apps become totally new. There need to be some sort of standards which are evolved not whole sale changes to how we write apps.

JavaScript is evolving rapidly but as a company we cannot sustain a roller coaster ride with every release. We have customers who already have our product and we cannot just keep upgrading the application at their sites every 2 months because a new freaking framework came out.

We came from Java world and now sometimes I regret our decision as a lead to move to JavaScript. We thought that we would gain productivity but what we are seeing is that with every release we have to retrain our developers as if they are in some college and taking a new course every trimester.

You need to create standards that are supported for a while and evolved as required not a freaking chaotic environment where every now and then whole stack is thrown out of the window.

Today it is isobuild then next month webpack, then DDP and now graphql, blaze than react, atmosphere than npm. I mean how are we suppose to train people and keep in sync with the new changes in meteor.

Companies like us who are product developers and have to support our customers for a long time are having nightmares with this chaos.

There is going to be a serious burn out if this chaos is not reigned in. I understand that JavaScript world is chaotic but Meteor as a platform should provide us stability that will allow us to grow otherwise we are just going to keep on refactoring for which our customers do not give a shit and won’t pay. They could care less about react or whatever, they want features that we develop. They do not give a crap if we move from DDP to graphql and burn 2 months of our time.

We have a product written in Java which has evolved in last 4 years but we did not make such amount of wholesale changes to it. It is very stable and is generating decent revenues. We only make incremental changes to it and that too when we ship our product with some new features not like now when we have to freaking change the whole application within few months because the framework below was changed to suit new flavor of the month.

Sorry for a long rant.

[sashko]

What makes the changes not incremental? It’s been as incremental as humanly possible.

[suhaila]

Well for one let’s consider DDP which has been left with no evolution rather we are now seeing Apollo as the answer to the problem. I know DDP is going to stay but all the changes are going to happen in Apollo and thus DDP will be left to die peacefully.

[akryum]

DDP gained query batching recently if I recall correctly.

[SkinnyGeek1010]

@suhaila

What we as product development company need is that the system should not become unstable after just a single release or the whole way of writing apps become totally new.

As a fellow product dev company I can totally relate.

If stability and project churn is a concern I would not choose JavaScript. The language itself has evolved a ton over the last 2 years. Development style has also developed significantly, switching to a more functional and declarative paradigm and away from (poorly implemented) OO/imperative. JavaScript 4 years ago was much much different.

If you want frontend stability in a framework I would suggest something like Backbone or Ember. Both of these are stable and get the job done and have not changed much.

To get stability in transmitting data I would recommend REST. It’s been around for a long time and mostly has a convention to follow. Pub/Sub over websockets or GraphQL is rather new and going to change as people figure out how not to do things.

Node/JS is one of the least stable backend languages i’ve used. While Express has been the go to framework there are lots of others. Java and C# are both some of the most mature and most likely the best choice for a stable backend (depending on project reqs. of course).

JavaScript is evolving rapidly but as a company we cannot sustain a roller coaster ride with every release. We have customers who already have our product and we cannot just keep upgrading the application at their sites every 2 months because a new freaking framework came out.

It sounds like your team may benefit from hanging back on updates. I have client apps that are on 1.1, 1.2, and I finally updated one to 1.3 today, way after the initial 1.3 release. Unless there’s a security risk or a feature that’s useful I wouldn’t update. I’ve found it useful mitigate risk by tinkering on side project to test out up and coming features/frameworks and then once vetted consider using them in client projects.

¯_(ツ)_/¯

[aadams]

If you are the maintainer of the Blaze-Apollo integration, you can make it look however you like

Sorry if this is unorthodox,

@sashko, I think it’s a good Idea for you to create a repo for the sole purpose of “semi-official” Blaze-Apollo integration. I’m requesting you to put @msavin in charge of this repo or state otherwise, and maybe @mitar as second in command.

I request this because, this repo type is needed, @msavin is a proven Meteor and Blaze advocate with equally proven skill level and “taste”. Further, I think he genuinely cares and is passionate about Blaze and Meteor based on his record.

What’s your opinion on this?

[sashko]

If someone commits to building an integration I’ll happily make a repo wherever they want!