Hacker News new | ask | show | jobs
by andrewingram 1729 days ago
Not planning on getting dragged into a debate about whether GraphQL is a good tech choice here (even though I won't pretend i'm not a massive fanboy). But the "with-apollo" Next.js example used as a reference (and then decried as being a bad experience and unscalable), is a pretty bad representation of how it can feel to use GraphQL with Next.js.

I've never used Apollo in anger, but i've used Relay with Next.js for a few projects and it's been a dream. The biggest downside has been the size overhead of the Relay client itself (approx 40kb over the network), and the size of the serialized data (but that's the same price you'd be paying whether you were using GraphQL or not, just an unfortunate reality of the hydration model).

1 comments

I’d love to hear more about your experience with that “with-apollo” pattern. I decried it without using it first, but I see the problem as a coupling/cohesion imbalance.

What has it looked like in practice for you?

I've mostly used the Relay examples as a starting point, though they've generally need to be fixed up to avoid some bugs. In the olden days of getInitialProps (still available as an API, but its use isn't actively encouraged) things were easier and more elegant, getServerSideProps and getStaticProps both force things to be a little uglier.

For my older (getInitialProps) approach, you can see a rough example here: https://gist.github.com/AndrewIngram/e974f63160af9df292fc39e...

Look at the last file (PostDetail.jsx) to see what it's like using GraphQL as part of a page (PostLayout isn't defined here, but assume it's just a regular React component using Relay's useFragment hook).