I don’t see how you figured that. The idea here is the build tool will magically construct the query from the handlebars and then embed the code into the application.
Hmm, I think magic opens a lot of opportunities here 
Sure, but not relevant in the context of a goal to build a hyper framework.
Anyways, just a wild idea. Not sure how much effort its worth yet.
Yeah, I guess in my mind there are some things that improve code clarity, and IMO GraphQL query strings are really clear where HTML and property accesses aren’t, especially if you add custom expressions, helpers, etc.
Please explain this more.
Please elaborate.
Basically, magic is…
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.
What is a transpiler?
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.
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.
That’s a very humble comment, you’re a good man.
I’m going to pass on this rabbit hole, but thanks for trying to faciliate a discussion!
I was simply trying to get you to elaborate on the argument you put forward:
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.
I think the stuff Max is suggesting is 100% doable! Didn’t mean to shut it down.
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.
For the record, what you said was actually quite different:
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.
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.
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.
And if I might add, I think you’re just the right guy to build the bridge between Blaze & GraphQL.
Well, if this is serious, I’m always reachable I’d have to study a bit first. Thanks for clarifying!
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.
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.
What makes the changes not incremental? It’s been as incremental as humanly possible.
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.