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 rework...
Anyhow, maybe I just don't understand it enough.
[0] http://sangria-graphql.org [1] https://www.playframework.com [2] http://sangria-graphql.org/learn/#schema-definition
You can also see a lot of examples of GraphQL server code for JS here: https://github.com/apollographql/launchpad
It includes connecting to DBs, APIs, etc.
You need to be very careful. To be optimal, you'll basically need to write very complex resolvers that inspect the AST themselves and fetch the data optimally which at that point is almost as writing your custom execution module.
That is basically what i did, custom execution module to translate a graphql request to a single sql query (https://subzero.cloud/)
If I have a schema like this:
users
projects (many per user)
blog_posts (many per user)
IMHO Relay doesn't make a lot of sense. Apollo Client [1] has a much better feature set for most use cases, doesn't need React and is better documented.
[0] http://dev.apollodata.com/tools/graphql-tools/resolvers.html [1] http://dev.apollodata.com/core/
I've been sticking with it though, and I am enjoying it. I feel like I have a greater grasp of what's going to be executed and when than I ever did with Relay Classic, and the file size + performance improvements are worth the cost of admission in my mind.
Plus bonuses if you have more than one database or are mixing data from your database and external APIs in your backend responses.
Please try it for a small project, it is unbelievable, but you'll probably enjoy it.
(For the record: I've just used https://github.com/graphql-go/graphql and Lokka on the client, because it is simple and does nothing fancy, it's a thin wrapper over XHR, I think.)
You can easily do that with a RESTful API too.
https://dev-blog.apollodata.com/optimizing-your-graphql-requ...
Examples more specific to a particular backend technology feel redundant because my assumption is that once you're in the land of calling functions, we don't need to hold your hands anymore.
The most important thing is to be aware of the different batching strategies that are available to you in each GraphQL implementation because I believe this is the most critical part of getting a GraphQL server to perform well with anything other than a graph database.
https://github.com/rmosolgo/graphql-ruby
Ryan supports development with a pro version that has a bunch of neat features, including built-in support for a handful of common authorization frameworks. I highly recommend it.
For example you have a Product type, and then write the resolver function that queries the database and/or another API. When you have the data, you pass it back to the client via Apollo or Relay.
The big advantage over REST is that the client can define what data it wants and how it wants it. If you are full stack dev this isn't such a great advantage, but for bigger projects where front/back are spread among many engineers this can be an advantage. Also, since the schema defines the types, your API is almost self documented so to speak.
The big disadvantage is authentication and authorization. We kept using REST for authentication, and we couldn't find any ready made solution for role based authorization like you have in Express, Hapi, etc.
I think a combination of REST and GraphQL is the better approach.
http://joelgriffith.net/lessons-learned-wrapping-a-rest-api-... For starters
A good GraphQL backend resolves the graph into query results efficiently, rather than just field by field. But that does take a but of getting used to....
I'm always stunned, but at the same time never surprised, when you discover a single webpage is 35+ MB, consuming 2GB of RAM, and consuming CPU as if it were a midrange video game.
News sites are also more complex than you would assume. I went from building products at Facebook to a large news site. What shocked me was the surface area of the user facing products. There were so many little one-off pieces of functionality and randomly integrated services. Tools like React and Relay make it much easier to manage this complexity and promote code reuse.
What's the advantage of server rendered React app over server rendered anything e.g. php jsp etc?
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. No premature mobile view with hamburger kicking in when viewing it on desktop.
Comparison of View source between two sites is quite amusing.
view-source:http://www.sankei.com/smp/
view-source:https://mobile.nytimes.com/
Bug, not feature. If I'm viewing a site in a narrow window, I expect it to collapse responsively. That site doesn't.
Do you not understand how URL rewriting works?
For NY Times, it's about 1:10.
Sankei.com, it's about 1:4.
I would think React might make sense for realtime dashboards and similar webapps.
But does it make sense for displaying articles, navigation and ads?
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, use programming constructs like loops and conditionals and finally return the assembled result.
Basically, React views are pure functions that return a validated HTML snippet. Normal templates are big blobs of strings with logic mixed in.
Realistically, a server-side rendered JS app is also going to run most of the code that runs in the client per page load, so you would also have to consider initialization costs as well. I've had to work on one that took 100+ ms to render a static page (without accounting for network latency), which a static file server could render the same page orders of magnitude faster.
Long story short, most of the newer, non-string based JS server-side rendering does not consider performance a factor and consequently, perform pretty terribly. There are band-aid fixes such as putting a reverse proxy in front or running on super fast hardware, but it's like putting a band-aid on a bullet wound.
[0] https://github.com/daliwali/simulacra/blob/master/benchmark/...
How does a server side React app look like? Is it basically a node application then?
I would argue it's the perfect candidate for this purpose. What does a news site need? Articles? Ads? Basic nav? Angular or Ember would be overkill. And with Redux, it's very easy to think about complex UI state.
My only complaint with React is how large it is given what it actually does. Loading 100kb of JS (not Gzipped) seems very heavy.
It's a 3kb React alternative with the same API.
Why not?
This might be a worthwile tradeoff to quickly build a highly interactive realtime interface. But for a newspaper? As a user I would be very much turned off to endure all that just to read an article.
No it doesn't. We (as a marketing tech company) deal with major publishers all the time and come across all kinds of ridiculous and complicated tech used to show a basic article when a simple static website would be easier and faster at this point.
It's a lack of good talent, resume-led motivations for choosing technology and overall poor vision in execution by CTOs and management.
As far as the criticism, would you be kind enough to explain what you mean by "relay concepts", and how GraphQL failed to satisfy those needs?
My interpretation is that they are now using a GraphQL API but fetching from it with regular HTTP fetches and managing data with Redux on the frontend.
GraphQL has helped us make an api that is easy to understand, easy to change and and easy to use. We love it.
The caching section in GraphQL docs is cringe worthy, and, as evidenced by the article, that's exactly what Times are going to do: try to slap global ids everywhere and pretend it's ok
IMO coupling the data layer with the presentation layer is a terrible idea.
I think I would just still be more attracted by Appollo framework which is more a redux-like syntax, so more consistent with all the workflow of the apps I used to develop. But maybe Relay has better benchmarks?
Also, if I want to stay REST but with optimist transactions between the backend and frontend, I prefer lighter lib like https://github.com/tonyhb/tectonic or even I just write some fast redux-saga watchers that helps to make my frontend always synchronized when my app calls a mutating db request.