171–180 of 187 posts
Earlier quoted context omitted.
> Everything is MIT Licensed Besides GraphQL you mean
Facebook switched it over to MIT last week (along with React): https://github.com/graphql/graphql-js/blob/master/LICENSE
Earlier quoted context omitted.
Apollo manages your data store automatically. It uses Redux internally. Because Apollo wraps the queries and mutations, it smartly caches data and only fetches the minimal amount necessary to build the page. Apollo reduces the amount of Redux CRUD boiler plate dramatically (by as much as 2/3 or more). There are no traps there, everything is configurable. The documentation is really clean. Highly recommend Apollo. Onc…
> everything is configurable Arguably that's it's own trap. Convention over configuration has saved millions of man hours in e.g. Rails projects, but a lot of JS land involves sinking a lot of time into the opposite.
GraphQL is a very nice spec for building APIs that have many sources of data and then building a modern frontend with proper caching etc. on top of it. The ugliest part of it, or one requiring most hacky solutions, is optimising queries. For example, there are some nasty N+1 traps or "oops-I-joined-your-entire-database" problems when using SQL. JoinMonster helps with this, but it is a bit too much of a "full solution…
Don't have tones of experience with GraphQL, but doesn't one write resolve methods himself? GraphQL just works with the data you've fetched, and as always it's up to the developer to know how to use the tool properly
I feel a little mixed about projects like this. It's fantastic to see people share their knowledge, and turn theory into practice. It's very easy to spout on about best practices and good ideas without demonstrating how they can be implemented in the real world. And this application does demonstrate some good ideas. ...But some bad ideas also. I think one problem we have in the frontend world is that developers of ve…
This is exactly what I feel. I get heavy request to build projects in React where their use case is pretty simple even wordpress can suffice.
But I guess WordPress is easier to work with if you're a non-technical person who won't be doing much else than adding new posts from time to time.
Earlier quoted context omitted.
> Not sure why my comment is being downvoted Because of the following reasons: 1) There's the subtle implication in comments like yours that this posting is not worthy because it was posted before. 2) It doesn't matter. Stuff is re-posted all the time, sometimes simultaneously. That's just the way the web works. 3) It's not your job to moderate or research this site for others.
I, for one, appreciate when some link historian goes out of his way to fight online amnesia.
Earlier quoted context omitted.
Is this because it's a quickly made demo vs a refined production-ready site, or is it a direct result of the way the sites are made? Can you use GraphQL, React, Express, etc. and make a very fast website?
You can, but it's a lot harder than building a very fast website that just uses Express to render Pug templates and that caches HTML in a CDN.
Earlier quoted context omitted.
You can, but it's a lot harder than building a very fast website that just uses Express to render Pug templates and that caches HTML in a CDN.
If the site is static enough to do that, why wouldn't I just use a static site generator? Not being snarky, I'm really trying to learn.
The original HN is one of the fastest loading sites I regularly visit. You fixed that pretty good. Disclaimer: I'm on terrible internet connections most of the time and it really makes you hate all this modern web crud. Often "dynamic" sites don't load at all because while the initial HTTP request eventually gets through, one or more of the following XMLHttpRequests or whatever fail, and a lot of the time there is no…
I also spend a lot of time on terrible internet connections, it really makes you realise how poorly optimised some websites are. HN is one of the few websites that consistently loads properly for me.
Earlier quoted context omitted.
I also spend a lot of time on terrible internet connections, it really makes you realise how poorly optimised some websites are. HN is one of the few websites that consistently loads properly for me.
I'm guessing nobody tests for this, because everyone develops on fast, reliable internet connections and it's not super easy to simulate, although there are tools, dummynet probably being one of the oldest: https://gamedev.stackexchange.com/questions/61483/how-can-i-...
I went down the path of learning Relay instead of Apollo. I'm regretting this decision. Relay is too restrictive, and the relay compiler is far too sensitive for most server side endpoints.
Interesting. I've worked with Relay almost since its release, more recently on the modern branch, and haven't run into anything that's been too restrictive. You have an element of thinking about things in "Relay" terms (in the sense of how to structure them) but once you've figured that it then things just work (TM). I'm curious about the second part of your statement, the compiler being too sensitive for your server…
The second big issue was that relay modern decoupled the networking logic, so having a series of chained queries is something you either have to handle yourself or write your own networking logic for. And because creating dynamic queries can't be done with relay it's a bit annoying that this logic isn't handled automatically for you.
My biggest gripe happens to be the lack of flexibility around dynamic queries. You can't define the data you want back at run time, which feels defeats a major point of GraphQL.
Apollo supports dynamic queries with higher-order components. It might be a case of the grass looks greener on the other side, but I felt as soon as you try to do something bigger than a todo app with Relay you start to feel the restrictions.