I do not see the problem here.
You already have this every time with your
master branch, which keeps changing while features are developed and then merged.
So, in your concrete example, you first create the
feature_xxx_backend branch and develop the backend changes. When this is done, the branch is up to review and will be merged into
master once the review is complete.
So, simply start another branch,
feature_yyy_frontend. You will probably want to branch directly from
feature_xxx_backend, so that you have those changes already in your branc. then simply develop the frontend feature asif the branch were
feature_xxx_backend branch changes, e.g. because there are things that come up during review that need to be adressed, simply do these changes and merge them into the
feature_yyy_frontend branch. Then continue on the frontend branch.
Once the review of the backend branch is completed, it gets merged into
master. At this point, it would be wise to rebase the
feature_yyy_frontend branch onto
master, so that the reviewers only need to review the new changes that this branch contributes to
master, and not need to re-review the changes made for the backend (which have already been approved).
This can also be done when you have two, three or more dependent branches. If you have two feature branches you depend on, simple make a derived branch that has both feature merged in. Branch from there, develop the third feature, merge both feature branches along the way when each of those change. When both features are done and get merged into either the derived branch, rebase onto that, or if they get merged into master, rebase onto master.
Rebasing (as suggested above) is really powerful and helps keeping a clean log of the changes, making reviews much easier.