TheMakeA

> 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.

PropType checking is compiled out of the production version of React.

Does anyone know if Docker Toolbox supports NFS (or something faster than VBox Shared Folders) yet?

> Yep, it is easier to make languages target DEX than suffer the pain of the NDK.

So what does this look like in practice? Genuinely curious :-)

So you're saying it costs as much as a down payment on a house in the Bay Area to own my own airplane?

I'd rather do that and then live nearly anywhere in the 400 mile range that it provides, and probably be happier.

> 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.

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.

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.

To expand on lgas' answer, you can certainly over fetch with Relay/GraphQL if your product needs to.

The intent is to prevent accidental/unintentional over or under fetching that leads to bugs or poor experiences.

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.

It sounds like what you're looking for is Business Intelligence. There are a couple of cloud tools like Chartio, Tableau, Looker, etc that provide similar functionality.

This seems really close to what YC started as. Why the spinoff?

Joe Savona says August.