Uh why are you rebuilding the head thing we already have in the front-end?

Sorry just woke up, I'll have a proper look today because my brain is not braining right now.

May have broken so don't merge.

Okay I am slightly more awake and still get the feeling that while clever, this potentially feels overengineered. Let me try to articulate my thoughts a bit here.

I have changed the process for getting a texture URL. Now the front-end requests to /texture with a UUID or username. The back-end caches responses from Mojang for UUID lookup and user properties lookup for 5 minutes.

I am not entirely following the logic for this round trip to fetch the player UUID and then the texture. For the players online we already had their textures available. You deleted getPlayerTextureUrl() but it seems overkill to go through the extra step of doing https requests to get player UUIDs and texture urls for those players that are already online. It makes us much more dependent on Mojang services being online, available and not ratelimiting us. Previously this would at worse result in player heads not showing properly in webchat, with this change it will affect the backend (minecraft) and pollute the logging there as well.

I also think that httpClient.send might be blocking, compounding any issues when services aren't available or slow to respond.

To limit that dependency I think we should only go through all these extra steps of querying the Mojang API for offline players.

My initial comment had me waffling about doing this entirely on the client side. But, I just realized that might be dealing with CORS here, so I think I get why you moved that aspect to the backend. If CORS isn’t an issue, I think this logic belongs in the frontend.

Something else we might want to investigate as well.

While typing all of the above out I also realized something myself. The player head in question will be shown in the ingame chat as well. So, minecraft already did download it. For our playerlist I briefly looked into extracting that sort of data from the client in the past. I didn't get that working and since player textures can easily be downloaded anyway opted for the client side approach.

If we do want to show more than just online players and potentially other sprites in the future I do think it is worth revisiting that approach again. At the very least see if the player UUID used in the chat message isn't somewhere in memory already.

That's also why I did open #184 and split it up in two approaches. A simple one without textures first, just a question mark and a complex one like your PR. Because I didn't want to dive in head first (pun intended) and think it through properly.

Also added this to more gracefully handle unsupported component types:

I missed this initially, combining these two makes it a bit harder to review. But all things considered not a big deal.

We can't just pull from the player list textures for this because you can display any player's head even if they are not online. However, this at least works better than showing an error message.

Can we just do this as a PR first, then revisit how we want to approach the whole playerheads and other sprites in chat deal?

I am not entirely following the logic for this round trip to fetch the player UUID and then the texture.

The idea is to have only one way for the web client to fetch textures. Better to have one slow way than two ways.

But it's reasonable to put that off until later when we might be able to hack the Minecraft client to give us all of the textures we need when it fetches them itself.