What is the best way to handle the mouse for an FPS game. That includes speed and the ability to read high DPI. Also how would I handle a keyboard, I assume that performance is not as big of a deal with the keyboard.

How do you define "the best way"? Here are some principal thoughts (with a "warning" close to the end):

From a player's point of view, an input system should be responsive, i.e. it should react without too noticeable delay. It should not be too sensible (especially meaning mouse movement to reaction translation). It should not miss input (especially meaning key / button pressing). And for flexibility it should be configurable.

From an implementation's point of view an input system should decouple raw input from logical input, making the other game sub-systems agnostic of what a keyboard and companions is. It has further to make sure that no unwanted look-ahead is done (i.e. input that belongs to the current state in game should be processed but not more).

From a developer's point of view an input system should be, well, simple. But above wishes disallow for simplicity.

For example, the player sees an enemy to come out behind a pillar. They presses the "fire" button. Well, the game loop is currently no longer in the input processing stage but the animation stage. It does not recognize the button down/up sequence and, because it works on key states directly, will never do this for those particular activation. The player's avatar doesn't shoot but gets shot down by the enemy. What a frustrating experience. (Hence: Performance counts even with keyboard input.)

IMHO the best solution for a fast paced game (like an FPS) is as follows: A thread is responsible for collecting raw input, and it does so (nearly) exclusively. It fetches input from the OS input loop and perhaps directly from drivers. It translates from OS specific values to more general ones and stores all relevant input into a queue. The game loop, running on another thread, uses this queue for its input processing w.r.t. the current time step. In fact the input is translated again, supported by some input configuration (where e.g. translation from mouse movement to angular velocity is defined) into logical input for steering actions and animations.

However, such a system is complicated. It is especially too complicated for beginners, because multi-threading is ever a beast even for more experienced programmers. So the first thing to do is to define the goals. Have you defined the goals yet?

Using the OS's input loop to read input from is a good thing, because it is a step towards not missing some input. Don't forget to use the delivered timestamp for comparison with the current time step of your game loop. Using an input configuration is another good thing, because it allows you an easy switching between different game states (introduction screen, menu screen, gameplay, …) and is the natural place to store translation parameters (e.g. speed scaling). It is further the place where user enabled input configuration has its effects, if such is perhaps implemented in a later step.