Since I deploy my Next front-end to Vercel, it makes sense to use Vercel for the rest of my app. Having only one hosting for the whole app avoids having to synchronize deployments accross multiple platforms, which can be tricky if some deployments fail. It is also more performant if I use dynamic server-side rendering, since Next instanciates a serverless function for that on the same network as my main API. The developer experience writing serverless endpoints with Vercel is really great, particularly the native TypeScript support and fast automatic reload on changes. I am very happy with Vercel but I am open to trying other services.Might change soon? Possibly
Vercel API routes do not support websockets (and therefore GraphQL subscriptions) at the moment, which is not surprising considering the ephemeral nature of serverless functions. It may work on other providers, but it is not an ideal architecture anyway, since we cannot maintain a persistent and reliable connection between the client and the serverless endpoint. We could maybe handle occasional disconnects and reconnects seemlessly for the user, but that's still not a great user experience.
A more reliable alternative is to have a separate stateful server to handle websocket connections, and have your GraphQL API talk to that server to push messages down to the clients. Upstream messages from the client can still happen through the GraphQL API via HTTP and don't need to be sent via websocket, unless you really need very fast requests (for a real-time multiplayer video game for instance). If you don't want to host your own websocket server, you can use Pusher.