GraphQL queries are usually fetched via POST requests which Varnish does not cache per default. But there is a nice way to cache them anyway and make them blazingly fast.
Once again: if you don't need it, block it. Either block it completely or allow it only for certain urls
If you have ever seen the default Varnish guru error page, you know what I'm talking about.
An easy way to do it, when you need it
Advanced methods to warmup your cache after a restart or deployment
Content caching is the easy part, cache invalidation is where the rubber meets the road
Or: how to deliver cached content fast while doing a background refresh, or while your backend is down
If you have multiple domains under the same application, and you use some files across multiple domains, you can save some caching space.
2 factors to consider and 3 ways to choose from to get started with caching in Varnish
Usually guests see some bits different then logged in users. A simple way to start with Varnish is to avoid all the caching logic for logged in users.
Caching and everything else should work behind basic auth too.
That way we define one single source of truth for all business logic related to incoming requests, caching, header transformation, etc...
Handle as many redirects as possible outside of your application
If you have a Laravel or Symfony or Ruby or Python or Next.js application, or some fancy flavor of a CMS, then why do you need to allow wordpress requests coming in?
There are good bots, and then there are the others. And they can cause some trouble with aggressive peaks in traffic.
You can either scale horizontally OR you can optimize your nginx config for handling of missing files.