3 ms·

A whole lot of people use it at work and witnessed valid criticisms. It’s not like we’re going to have the knives out when React/Angular is new. Give it a litt

A whole lot of people use it at work and witnessed valid criticisms. It’s not like we’re going to have the knives out when React/Angular is new. Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase. HN will be full of ‘we rebuilt our api in GraphQl and boy things are a mess’ in 2 years.

jsjw7sbw 7y ago
We rewrote our frontend in hooks and graphql 1 year ago. Hooks are fine, but graphql is a messy time sink for our usecase.
- WiseWeasel 7y ago
  Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge to rewrite a complex REST react app to GQL, since you'd be discarding a ton of data shuffling code, but we've been happy with the resulting simplification of our frontends.
  - gregkerzhner 7y ago
    I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest. For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux. In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer. I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested. The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy. In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.
    - mikewhy 7y ago
      > For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. Apollo is for GraphQL. I'm not sure why you'd try to use it's internal caching system to add local application stuff. Note that using Apollo does not stop you from continuing to use Redux. > The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. This is what hooks aim to solve.
    - WiseWeasel 7y ago
      The convenient thing about the Query and Mutation components being in your markup is the access to the loading and error states within that context. With Mutation, I often end up just passing the mutate callback to an event handler method. There's always direct access to the client when you want to make normal procedural API calls. The Apollo caching system hasn’t been all roses; it can be pretty easy to wipe out parts of a cached entity you were needing on a view with the response to a mutation on a different view if you’re inconsistent with query and mutation response structure. But I find it convenient after getting the hang of its pitfalls.

jsjw7sbw 7y ago

We rewrote our frontend in hooks and graphql 1 year ago. Hooks are fine, but graphql is a messy time sink for our usecase.

WiseWeasel 7y ago
Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge to rewrite a complex REST react app to GQL, since you'd be discarding a ton of data shuffling code, but we've been happy with the resulting simplification of our frontends.
- gregkerzhner 7y ago
  I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest. For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux. In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer. I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested. The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy. In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.
  - mikewhy 7y ago
    > For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. Apollo is for GraphQL. I'm not sure why you'd try to use it's internal caching system to add local application stuff. Note that using Apollo does not stop you from continuing to use Redux. > The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. This is what hooks aim to solve.
  - WiseWeasel 7y ago
    The convenient thing about the Query and Mutation components being in your markup is the access to the loading and error states within that context. With Mutation, I often end up just passing the mutate callback to an event handler method. There's always direct access to the client when you want to make normal procedural API calls. The Apollo caching system hasn’t been all roses; it can be pretty easy to wipe out parts of a cached entity you were needing on a view with the response to a mutation on a different view if you’re inconsistent with query and mutation response structure. But I find it convenient after getting the hang of its pitfalls.