> Unfortunately now those 250K people who reserved a Model 3 could be driving a EV right now and making an impact instead of waiting for 3 more years.
This is a false dichotomy. As an anecdote, I started a 3 year lease on an EV two weeks before the Model 3 was announced and still put in a reservation.
Who cares if I can get a Volt for 33k right now? It still burns dinosaurs and has a terrible electric range.
Tesla is the press "darling" because it's doing something that the other manufactures aren't: Good looking, All Electric, High Range, Affordable Price. These are things people clearly want.
Every other vehicle sacrifices at least one of those.
I do realize that the Silicon Valley types don't care about this issue, with iPhones behind walled gardens and all that jazz (or at least, SV doesn't seem to care about it anymore... what ever happened to the vision of open source and true ownership?)... but I know plenty of people who are still interested in vehicle with open standards.
Or hell, just a vehicle that can be taken from a junkyard and then repaired in a garage. You're not allowed to take a Tesla from a junkyard and salvage it, not unless you take it to a dealership and have it "reactivated" by Tesla.
May I ask, why this was downvoted? Isn't the idea of vbox's shared folders to provide a convenient data exchange with the host OS? If one puts ssh into the docker container, the host may mount a container's directory into its tree.
By targeting DEX, which happens to be documented, there is at least the hope that for the Android tooling that Google cares about, it is just like Java running and there are less hurdles.
So, you get the same benefits of the languages that target other VMs like JVM, CLR, BEAM and so on.
As long as, the language semantics can map into the VM semantics, all the libraries and platform tooling are available without the need of writing wrappers.
True, that is a big "as long as", but it still is less problematic than going through the current state of the NDK.
You totally can. One restriction (that you might be confused with) is that Relay currently only supports root fields with a single argument (which would typically be an ID).
But arbitrary arguments on any other field are totally supported.
It's important to realize that you're essentially defining an API for your product. If something is expensive to access, you should either not expose it directly through your API, or add appropriate levels of caching to mitigate the costs.
Anecdote: when Relay/GraphQL were first announced, we tried to get Relay without GraphQL by writing JSON. This had some advantages (a query was a valid/renderable response!)
...but we had some really ugly JSON. It was worth it for us to get the readable syntax to just use GraphQL.
With client tooling like GraphiQL and editor plugins, it should just get better.
Every time there's a new post about GraphQL, I become even more concerned that "GraphQL" was the wrong name to use publicly. It seems like most people assume it's just another combination of two buzzwords, Graph and QL, and incorrectly pattern match it.
In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead.
It's not a storage layer. It's not really a query language. It's an alternative way to define an API that more closely matches the typical mental and product domains than REST.
It's critical to realize that you're implementing an API. GraphQL does not concern itself with sorting or fetching data as the name might lead you to initially believe. It has little to actually do with graphs (except they are more easily expressed). It is designed to be added on top of your application layer and business logic to provide a single, well defined API for your product and tools.
It primarily targets product developers. From the scheme/API side, it is up to the server developer to decide what to expose and how, based on the product and any technical considerations that need to be made.
No, I disagree.
GraphQL is definitely a query language,
since it allows to specify pieces of data to be extracted from a whole data set.
Compared to SQL,
this is done using an unusual manner,
giving a shape of the data we want around some seed,
but the approach is both expressive and efficient.
In light of this query principle,
it is perhaps unfortunate that GraphQL use a different syntax for the query and the response.
To this regard, freebase's MQL is more pure
(http://wiki.freebase.com/wiki/MQL).
About graph, I think the term applies too.
Indeed, a GraphQL defines a subgraph to be extracted from a whole graph,
even if the tree shape of the response forces to resort to ids to tie the loop.
Compared to a graph traversal query language like Gremlin
(https://en.wikipedia.org/wiki/Gremlin_%28programming_languag...),
I find the pattern approach of GraphQL simpler to grasp;
and even easier to implement efficiently in a distributed setting.
I implemented years ago a distributed graph database for Yahoo!;
and the query language, based on shapes to be extracted around seeds,
was a key design choice for an efficient architecture and short query delays.
Let me clarify a little: I think the name GraphQL for sure makes sense from a technical point of view. But from a marketing point of view, it has been a nightmare and makes it _unusually_ difficult for others to initially grasp.
So what you mean is that name of GraphQL minimizes one of its important aspect:
the ability to query a service/product/app whatever are the actual persistence mechanisms
and even so if part of the response is computed on the fly.
Now, I better understand, why you would prefer a name like ProductQL
or even ProductAPI in order to emphasise the will for this tool
to be the single point of interaction from the outside with a product.
In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead.
It's not a storage layer. It's not really a query language. It's an alternative way to define an API that more closely matches the typical mental and product domains than REST.
I think "ObjectQL" or "NestedRPC" might be more appropriate: it's an IDL and protocol for a nested RPC facility for object-oriented systems.
You start with a root query object and then call a bunch of methods on it of the client's choice and put the results in a dictionary.
Then you do that recursively on the resulting objects until you have data consisting of nested dictionaries and lists containing only primitives, which is finally serialized as JSON and returned.
1) Give me data in the right shape for my problem please server.
2) Server responds with data in a shape that matches what it was asked for.
3) Update the store of your frontend and trigger any updates to UI (react does this automatically).
Save countless hours of writing fine grained rest APIs to support various different ways of requesting data or munging data into the right format on the client.
And by the way we've made it super easy to bundle requests together in a nice way saving trips to the server.
I'd have to disagree in that it's not a query language, there is definitely ability to query different parts of the data. I'm just unsure where the Graph part of the name came from. I was under the impression it was some play on the words sounding like "graphical" since the appearance of the query language in code is a very close depiction of the actual data returned.
> I'd have to disagree in that it's not a query language, there is definitely ability to query different parts of the data
For sure. If I could still edit the post, I would probably change it to be something closer to "it's not really a general purpose query language like the name might imply"
It's definitely a query language, but folks start looking for the sorting/filtering/etc and get confused.
And with good reason. I work on graph data structures and have had four people suggest I check out "GraphQL" for my work. Alas it has almost nothing to do with graphs. Every time I read about it I feel that Facebook tech has jumped the shark. I'll go back to my terascale rank/select dictionaries now...
> Every time I read about it I feel that Facebook tech has jumped the shark
No, Facebook does it on purpose, just like React has nothing to do with functional reactive programming. They are talented , not idiots , they know that a catchy name is useful to promote their tech even if it is misleading.
This is a false dichotomy. As an anecdote, I started a 3 year lease on an EV two weeks before the Model 3 was announced and still put in a reservation.
Who cares if I can get a Volt for 33k right now? It still burns dinosaurs and has a terrible electric range.
Tesla is the press "darling" because it's doing something that the other manufactures aren't: Good looking, All Electric, High Range, Affordable Price. These are things people clearly want.
Every other vehicle sacrifices at least one of those.