For Uno, you can totally build it in a web browser. Doing so would even be a good thing, because your target market would be much bigger than a native app.
You could use messaging over websockets. Keep a server up that has some kind of process or object for each game currently running. Receive commands from the players, send known state to the other players. It's important to not send all player's hands to all players; send only the size of each player's hand to all players, and the specific hidden cards to the players that can see that state. Else some player will open the web console, or a packet sniffer, and see the data.
If you absolutely must write a native game, know that Unreal and Unity mostly focus on 3D games, but can do 2D as well. More lightweight engines like Godot are generally just as good, if not better, at 2D, and are often easier to work with for simple games. Networking in game engines either comes built-in with the engine (Unreal) or using TCP or UDP sockets, with some structure you yourself put on top. It's not as firmly structured as the HTTP protocol or Websockets, generally because the payload needs to be sent much more often (for real-time games) and the overhead of plain text and headers (and the latency of compression) is too much.
