I cannot do the peer to peer topology as I'm using Websockets (Browser based). But I wish I could.

You can have a logical peer to peer topology (one player "hosts" the game instance) while you still use a physical start topology (a single server repeats messages to other players in the same session.)

how do I go about having the monster inch its way closer and closer to the player?

Then you need to have monsters ative when they're close enough that they should know where the player is to start moving towards it.

not sure how to make the server authoritative to track monster movements and AI

Just make it authoritative. If it runs too slow, first look for options to optimize the implemented code, and only when you can't do that anymore, split your world across multiple processes (cores.) I think you over-estimate the "cost" of running simulations on server side. As long as you don't add too much unnecessary indirection or repeated re-processing, you can push a lot of load even on a medium-capable modern CPU.

First, you shouldn't path for enemies that are far away from players

SIMSpace kept the total number of active targets (both within and beyond visual range) in the simulation low at all times, perhaps 20-30 at most at once.

2) Peer-to-peer. Here, perhaps some player "hosts" the game, and is the "server" from point of view of making decisions

this is how SIMSpace worked

1) All clients must use the exact same computation model. This has been a problem even for Windows, as some Pentium systems had the division bug, and some AMD FPUs do internal precision/rounding differently from Intel FPUs. Early SSE also had not-entirely-bit-precise specifications.

this is why SIMSpace transmitted combat results, not just attacks. due to the "maximum randomness" design of the game, different targets required different dice rolls at different times, so there was no hope of keeping the rand() functions sync'ed. The pentium divsion bug and AMD rounding issue were not accounted for. SSE instructions were not used, and may not have existed at that time (MMX was the latest and greatest at the time as i recall).

2) Late joins / drop-ins is much harder to implement, and will almost always require that all the other players pause for a little while the new player enters the simulation

the 2500 byte setup packet to add a new target in SIMSpace did cause a pause of a couple seconds. The testers decided it was acceptable.

Just make it authoritative. If it runs too slow, first look for options to optimize the implemented code, and only when you can't do that anymore, split your world across multiple processes (cores.)

SIMSpace was 2 player co-op via modem or null-modem cable. as i recall, i estimated you needed one PC server, one PC for each player, and one PC for every ten active targets to reproduce the full single player experience in a true multiplayer environment. as best as i can figure, this was with 486/66 PCs (IE 486DX2 processor running at 66Mhz clock speed). contrast that to the dual core e300 1.3 Ghz laptop chip i'm using now.

I cannot do the peer to peer topology as I'm using Websockets (Browser based). But I wish I could.

You can have a logical peer to peer topology (one player "hosts" the game instance) while you still use a physical start topology (a single server repeats messages to other players in the same session.)

how do I go about having the monster inch its way closer and closer to the player?

Then you need to have monsters ative when they're close enough that they should know where the player is to start moving towards it.

not sure how to make the server authoritative to track monster movements and AI

Just make it authoritative. If it runs too slow, first look for options to optimize the implemented code, and only when you can't do that anymore, split your world across multiple processes (cores.) I think you over-estimate the "cost" of running simulations on server side. As long as you don't add too much unnecessary indirection or repeated re-processing, you can push a lot of load even on a medium-capable modern CPU.

Sorry for the late response.

I will look into that physical start topology, I will have to incorporate WebRTC somehow as well I'm assuming?

This is what my server-side monster AI looks like right now:

If a player uses a skill, I notify everyone in the game, then check for cooldowns and validate input server-side. Then when that skill collides with a monster, it sends an attack signal to the server (AM 72) -- which then checks if the player is in a certain radius of the monster, etc. Then, it calculates the players damage, damage to mob, etc, then pops out damage numbers.

I just don't know if this type of design architecture is the right way to do this? Cooldowns are authoritative and fireball has a 1 second cooldown, and the server checks if a player is next to a mob before doing damage (in a certain radius) -- so they could just send the attack commands in the console to do damage, but they would have to be in that monsters vicinity. And traveling takes a while especially in larger maps.

I will have to incorporate WebRTC somehow as well I'm assuming?

If you want to use UDP, yes. If you're OK with TCP, then websockets alone is good enough.
Some successful web games only use websockets.

I just don't know if this type of design architecture is the right way to do this?

There is no "right way," only "different ways with different trade-offs."