The simplest approach is to use a single repository, so unless you like complexity for complexity's sake, then that should be the default choice in the absence of compelling arguments otherwise.
Is the client and server development going to be carried out by different organisations? Will there be multiple implementations of the client (or server)? Is the client open source and the server implementation secret? If the answer to all these questions is "No", then anything more complex than a single repository is likely to bring only inconvenience for no benefit.
If you do choose to maintain separate codebases, you will need clear policies about how this is administered, in order to avoid incompatibilities and dependency hell. After working through the first few hiccups, you might end up discovering that the safest thing is to always check out both repositories together, build them together, and deploy them together...which obviously defeats the whole purpose of separating them!
Modularity is a nice property to have, but splitting repositories is not a tool to achieve that. As the previous paragraph implies, you can have highly coupled components that are split over multiple codebases (undesirable), and likewise you can have highly modular components within the same codebase (desirable).
On more than one occasion, I have advocated (successfully) for my team to merge existing git repositories, because it simplified development and deployment.