The technical benefits of multi-repo are fairly minor: smaller repositories, faster clone times, possibly improved performance on CI, but nothing that should make a real impact on anthropic scales. There may be organizational advantages depending on how communication and process happens between your application's team members.
The technical downside of a multi-repo will be noticed immediately: you can't modify files across two repositories with a single commit, can't merge changes across two files in different repositories in a single commit, can't revert changes across two files in a single commit, etc.
If your client and server are tightly coupled, not being able to make changes on both sides in lockstep will require you to waste a great deal of effort in order to perform day-to-day development tasks. Shipping a new feature? Have fun creating two feature branches, doing two staging deployments, doing two pull requests, doing two code reviews, doing two ... ad infinitum.
To avoid having them be coupled might be even worse: you will need the client to be able to support multiple versions of the server and for the server to support multiple versions of the client - hiding menu items that require features detected as missing on the server, supporting or otherwise handling obsolete messages and parameters from old clients. You will need to be able to QA new features on either side independently from making the same changes on the other repository, this includes both automated testing (what could have been one suite of integration tests are now three: client integration tests, server integration tests, and end-to-end tests) as well as User Acceptance testing (can your stakeholders consume a REST API and conclude if it meets their needs? If not, prepare to build things over several times. Can your UI simulate a new feature without the server supporting it? Have fun writing lots of stubs.). Depending on your application this could be simple, a great deal of work, or effectively impossible, so you should be quite confident that the organizational benefits of having separate repositories outweighs that cost.
If you want the server to be the server, and the client to be the client, to be able to conform to the conventions of each component's framework of choice without compromises, to have a clean boundary between the products in your project (a demarcation line consisting entirely of the API) you get all of that with a couple subdirectories and a couple 'cd' commands in your CI script, and don't give up being able to change things like the name of a resource or parameter on both sides with one commit, one review, one deploy, etc.
