61–70 of 113 posts
Earlier quoted context omitted.
> custom execution module to translate a graphql request to a single sql query If I have a schema like this: users projects (many per user) blog_posts (many per user) What SQL do you generate to handle a request for everything in a single query?
take a look at PostgREST https://github.com/begriffs/postgrest simplified example query https://pastebin.com/7J2ZswRC
Earlier quoted context omitted.
Even if we don't use React on the client side, it can act as an excellent server-side view templating language. This is because React inverts the templating model on its head. A typical template is an HTML file (or some variation of it) within which the dynamic content is inserted using string interpolation. A React view on the other hand is a piece of Javascript code which can compose small snippets of view as JSX,…
The string building approach is the fastest, and it's the benchmark to beat. Any other abstraction is just piling more work on top and is generally just a more inefficient way to output HTML. The most lightweight pseudo-DOM implementations are still going to be significantly slower than string concatenation, and I have benchmarks to back up that claim [0]. Realistically, a server-side rendered JS app is also going to…
Earlier quoted context omitted.
The string building approach is the fastest, and it's the benchmark to beat. Any other abstraction is just piling more work on top and is generally just a more inefficient way to output HTML. The most lightweight pseudo-DOM implementations are still going to be significantly slower than string concatenation, and I have benchmarks to back up that claim [0]. Realistically, a server-side rendered JS app is also going to…
I don't know who downvoted you or why, but yes - performance could be a problem as you pointed out. I prefer the React model simply because it is more programmer friendly. I would hope that performance is something that can be fixed, or at least the 80-20 rule will come to help.
Earlier quoted context omitted.
You mean www.nytimes.com ? Is that already the new react powered version? As a sidenode, it does feel sludgy: - Scroll is not smooth. - It does not adapt well to different browser sizes - After a few seconds the page "jumps down" But the reason might simply be the overkill of JS,animations, overlapping elements (like the static header), ads, dynamically loaded stuff and other crap. When I turn off JS, some of the pro…
They're not using React right now. If you read the article it says they'll be introducing the new version over the next several months. A lot of this "JS is slow, what happened to good old HTML and CSS, get off my lawn" stuff is simply confirmation bias.
Earlier quoted context omitted.
You've hit a (pain) point. While graphql reduces the amount of trips to the backend for the browser, those round trips get pushed down to a lower level, between backend and db. The reference graphql-js implementation, while at first looks so easy, you just write a resolver for a field, makes it oh so easy to have terrible n+1 problems. dataloader helps a bit but it's not as optimal as it can be. You need to be very c…
Sometimes I worry whether GraphQL is analogous to ORMs: a theoretically elegant attempt to solve an impedance mismatch between a data source and its consumer, but one that ultimately just shifts or redistributes the impedance to different layers of the codebase...
I'm getting the impression that if nothing else though, I'm probably gonna need to wait a few years for this tech to stabilize more. Which I find very unfortunate, because the standard way of doings things these days feels very unpleasant to me (I hate writing boilerplate more than anything: have an overuse injury, so typing is the worst part of coding)—and the GraphQL queries do seem to make a lot of sense (although forcing clients to have explicit knowledge of schema structure seems a little dangerous...).
I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases? So instead of "we use GraphQL, much love" + basic example and how it looks on React - a "here's how we take that structure and resolve it and return it." Because that structure looks amazingly sweet - but if in the background it's requiring circles of work, work and rew…
You've hit a (pain) point. While graphql reduces the amount of trips to the backend for the browser, those round trips get pushed down to a lower level, between backend and db. The reference graphql-js implementation, while at first looks so easy, you just write a resolver for a field, makes it oh so easy to have terrible n+1 problems. dataloader helps a bit but it's not as optimal as it can be. You need to be very c…
I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases? So instead of "we use GraphQL, much love" + basic example and how it looks on React - a "here's how we take that structure and resolve it and return it." Because that structure looks amazingly sweet - but if in the background it's requiring circles of work, work and rew…
http://joelgriffith.net/lessons-learned-wrapping-a-rest-api-... For starters
I tried Relay but found it ridiculously stupid that I need to change the graphql API on my server in order to satisfy the relay concepts(universal id, connections) so we rejected the idea and decided to go with the good old fashioned redux
Take a look at Apollo. https://github.com/apollographql/apollo-client
Putting aside all of the technical fun, from a pure reader perspective of any website sometimes I miss just simple boring HTML with a bit of CSS to make it more pleasant and readable. I don't know about anyone else, but particularly from a consumption standpoint I miss the days of 100k webpages. I'm always stunned, but at the same time never surprised, when you discover a single webpage is 35+ MB, consuming 2GB of RA…
There is a lot of technology for technology sake to be found in American web sites. My favorite counter example is sankei news site. http://www.sankei.com/ All their pages end in .html. Do view source and vast majority if byte is used for actual text content, rather than javascript and markups. Mobile friendly too, but you wouldn't know it because they disabled responsive view unless it's visited from an actual phone…
Bug, not feature. If I'm viewing a site in a narrow window, I expect it to collapse responsively. That site doesn't.