Lets clear 2 things up:
Vercel (as a hosting provider) does not support hosting a websocket server.
You could theoretically still use any frontend for your 2 player game. The backend should be a websocket server though. (Don't do useSWR, thats a bait for your usecase)

The architecture would look something like this (taken from google):
Doenst have to be redis (just any db). As you can see websockets is other than http a continious, bidirectional connection.

Now i don't how your game should look like but all the spicy logic of such a project will happen on the backend. You can build your frontend with any framework from vanilla js to react to nextjs. But you dont really need nextjs for a client which e.g. looks like this in the end:

(again taken from google). You are not making use of any specfic nextjs features if that would be the ui you are buliding

https://www.youtube.com/@UnitOfTimeYT This guy is really cool and uses 'Go' for his Browser based MMO. Some of his videos are really informational on how all of it works.

I'm just trying to wrap my head around the SWR part. In the article, why do they mention serverless functions and SWR then?

I suppose that you're suggesting to go the traditional route of having a Web socket server (NodeJS) and then a frontend (NextJS) that would communicate with it. I'm just more confused about this article I found.

I agree, what's with the bait thing, I actually want to look into websockets myself so

I'm confused as well and the article is from their official vercel website. Hah!

I'll dive into it. Thank you!

It's a pull vs. push architecture decision:

In theory you can pull the data using useSWR every let's say 1 second or .5 seconds. This might be okay for some use cases but for (almost every) game i'd rather say it's not the way to go. useSWR uses the http protocol, the connection is closed every time and re opend within that interval. This can be okay for let's say a dashboard which updates graphs or somthing like that. Naturally you will run into performance issues if you pull e.g. every .1 seconds a large amount of data. (Maybe racing conditions all the nasty stuff)

Websockts on the other hand would be the push principle. Connection is kept open and when the server pushes a new event you've subscribed to, you get the newest data.

Do you lose socket trigger events during the time the connection is closed during the interval time?

We might have a misunderstanding here: This site https://vercel.com/guides/do-vercel-serverless-functions-support-websocket-connections suggest to useSWR instead of websockets not a combination of both. At lesat the way i read it. If you talk about using useSWR as a websocket client to consume the websocket. It can do that as well https://swr.vercel.app/docs/subscription however I'd reference this as useSWRSubscription. So everything i said was under the assumption we are talking useSWR (as a rest api fetch) vs websockets not a combination of both

Of course! I also think useSWRSubscription should be used as it's realtime and it should be used as a workaround or substitute like you said instead of using them both. It's starting to make sense now. ALthough, creating a websocket server would be way more efficient than relying on an interval every .5 seconds. I was thinking of creating something like a simple Connect 4 which I think using SWR would be great since it's not a big project, but I would still implement it with websockets since it's more reliable.

Yeah you can do something like Connect 4 both ways. I was just trying to give some background on why and when Real Time Apps might need something like websockets.

Of course! I appreciate it! Thank you for your insight!