Individuals don't have velocity, teams have velocity.
Even if you have two roles in the team (backend and frontend), with some people unable to do other people's work, it's still the team as a whole that delivers work. Can you deliver only the backend to the user, with no frontend? Or the other way? No.
So the sum of all the story points delivered in a sprint will be the team velocity, and it's something you can use to forecast future work or use as a reference to know how much work to pull in a sprint. Most of the times you also have backend and front end work on stories, and even if some sprint one effort leans towards backend or frontend, on the long run it tends to balance. So you need to use the team velocity.
Now, about using the velocity, the question is how you use it. I've sometimes seen people say "Hey team, we averaged 100 SPs these last 3 sprints, so let's target 100 SPs this sprint also". That sounds good, but then they shove stuff into the sprint and stop when they hit 100 SPs. This isn't right.
That number should be a guide. You properly do your planning and then ask the team how confident they are in reaching the sprint goal with the work they have planned. You can then use the previous velocity to get a better understanding of what is going on. For example, if the team now pulls only 50 SPs or tries for 150 SPs, then you ask what is different, and why, and plan accordingly. You don't just shove 100 SPs on the team's throat.
So don't use "individual velocity". If people end up with less or more work then you can cross that bridge when you get there. For example, you could pull more work if that doesn't create negative effects on the current sprint, people can help others with their work if they become available sooner, they can pair program and spread the knowledge trying to become more cross-functional, etc. In Scrum, teams deliver software, not individuals.