There should be a front and a back end team, but the back-end team should know how the front-tend works in interacting with the back-end, and even be able to write JS to this end. Having one team hitting just API endpoints is fine - until you need more nuance in your approach then you need to appreciate how end-to-end works.
example: what if you need to limit API calls, or stream data in a specific way? what if you need to work with the back-end to pre-fetch certain data and then cache it client-side?
I'd argue these things are back-end-interacting client-side code. and they should probably be written by someone with a strong appreciation of the back-end, whether than be someone actually on the BE team, or a knowledgeable FE team member.
Of course, you can always write a spec that covers all of it and bounce it between the two teams, but that doesn't always work out well, especially if FE/BE silos have developed.
One or two devs knows the other teams stuff? The whole team?
also, what does it mean in the context of "different skillsets"? It sounds like the FE devs has some comprehension of the BE, but weaker skills than the BE devs. Then cross-functional just means not strongly siloed, but what is the advantage is that? a little knowledge can be worse than none.
KT can be expensive, specialism exists for a reason, and you can end up limiting your hiring pool if your requirements are too strict.
I don't think a FE team needs every member to know every detail of the back-end, a suitable abstraction can simplify how much you need to focus on the back-end detail.
Instead I'd advocate having a few "specialists" that have a good knowledge of where FE meets BE. they needn't be the best BE or FE dev, but the best at integrating the two; I'd say this is usually a BE engineer who can write good JS and has a decent appreciation of the relevant protocols. They can architect the main touch points, and then abstract them (i.e. create relevant classes) for the FE, BE. These devs would be competent experts in integration, rather than the "jack of all trades, master of none" full-stack variant; a shallow but wide knowledge may be great for prototyping, but not for mature stacks.
example: what if you need to limit API calls, or stream data in a specific way? what if you need to work with the back-end to pre-fetch certain data and then cache it client-side?
I'd argue these things are back-end-interacting client-side code. and they should probably be written by someone with a strong appreciation of the back-end, whether than be someone actually on the BE team, or a knowledgeable FE team member.
Of course, you can always write a spec that covers all of it and bounce it between the two teams, but that doesn't always work out well, especially if FE/BE silos have developed.