loveholidays

Hey Piotr,

It's hard to really give a single recommendation for the things you are looking for, generally because I think content and state are very different things and you can choose to manage both independently.

Therefore I've picked Sanity as an example of a content management platform that you could utilise with your Next.js and GraphQL implementation. I've used Contentful and Sanity and both provide direct GraphQL integrations, so ultimately it's up to you what you want to pick here. As far as CMSes go, Sanity is much more "built it yourself with a good system around you" and Contentful is more of a "here is a platform, go create some content models". You will need more infrastructure for Sanity, but you might also get flexibility from it in the future. It really depends on what your PoC becomes.

As far as state management goes, it really depends on what you are doing. Honestly my advice is don't pick a state management library or tool just yet, and make do with React context, hooks and simple management of components. If things get complicated quickly I would look at how you are architecting data flow and rendering. Having used Apollo Client extensively in the past, you can use it for local state management as well as network calls, but the lines get blurry and I don't think it's very easy to follow when you do that. Having said that, it works out of the box for GQL and will give you what you need to get started. We use URQL in production and we like the simplicity it gives us and the lack of potential caching issues you can come across with Apollo Client.

My advice for Apollo Client is:

• Do not nest your queries too much and SSR, renderToString() gets expensive when traversing the DOM tree
• We saw benefits of using HTTP Batching for requests, but we also saw lag in the calls
• Using Apollo Client works best with Apollo Server (naturally) so anything else can be a bit problematic because it doesn't do all the magic that Apollo Client would like

As you are doing a PoC, do whatever you feel gets you there faster with the GQL implementation. I would say read the docs of both and see which one takes your preference. Both are actively maintained and looked after well.

If you are expecting your PoC to become a fully fledged solution at some point, things to consider about both:

• Bundle size
• Adaptability when you start having N different GraphQL APIs going into a gateway
• Ease of use for other people to pick up. Apollo has better documentation right out of the box.

To summarise, for content management:

• Contentful or Sanity

For state management:

• All local state with Context and Hooks
• All data fetching with Apollo or URQL. My preference here is URQL, but if it's your first time with GrapQL then Apollo will have more support.

Hope that helps!

I've picked Node.js here but honestly it's a toss up between that and Go around this. It really depends on your background and skillset around "get something going fast" for one of these languages. Based on not knowing that I've suggested Node because it can be easier to prototype quickly and built right is performant enough. The scaffolding provided around Node.js services (Koa, Restify, NestJS) means you can get up and running pretty easily. It's important to note that the tooling surrounding this is good also, such as tracing, metrics et al (important when you're building production ready services).

You'll get more scalability and perf from go, but balancing them out I would say that you'll get pretty far with a well built Node.JS service (our entire site with over 1.5k requests/m scales easily and holds it's own with 4 pods in production.

Without knowing the scale you are building for and the systems you are using around it it's hard to say for certain this is the right route.