> 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'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.
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.
There seems to be an awful lot of gratuitous negativity going on here.
The site was on Reddit yesterday, now it's on the front page of HN. Maybe the author can't throw a lot of resources at it, or they used the project as an excuse to learn a new stack. Who knows.
Maybe it was slow for you. Maybe it's not a mathematically sound idea. Maybe the questions aren't ideal. The CAPTCHA isn't ideal.
> they haven't really offered any strategies I can implement
I think I made two mistakes the first time I sought help:
* I stayed on the first medication I tried for far too long
* I stayed with my first therapist/psychiatrist for far too long
My new doctors are far more helpful and push me further than my old team ever did. If it's not clicking, don't give up, but maybe see if there's someone else that might be better for you.
If you write most of your code in JS, you technically don't even need to build this on a Mac. For development, you could get away with just updating the bundle and re-signing the app locally.
Absolutely. My primary concern is with the controls feeling native. Reimplementing controls with UIViews doesn't seem much better than reimplementing them with HTML/CSS (save for performance). There's still surface area to break the illusion.
Some food for thought: what if you kept HTML and CSS but instead of using a WebView to render it, you rendered the DOM manually using UIViews? You could even make overflow: scroll; turn into UIScrollViews automatically.
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.