That sounds correct. However, you're very flexible in who composes the transaction and who actually submits it to the network.

In general at some point a transaction needs to be signed by the end user's wallet *(which holds the private key to your funds)* - and this is the step that requires some sort of interface that is the DApp connector *(possibly also to identify the user by the public address in the first place)*.

Regarding the client and server side of DApps, there is no single architecture that fits all use cases.

You can have a setup in which 1) the client passes its public address to the server, which then 2) generates a transaction, 3) passes it to the client for signing; 4) the client passes it *(or even only the "signature" for this tx)* back to the server for 5) final verification & server-side signing, before the server then 6) submits it to the network.

On the other hand a DApp strictly doesn't need a server at all, and everything could happen on the client side (eg in the browser through a lib like this https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-browser) - you can generate your transactions and submit them to the network through a wallet's dapp connector (eg using Nami wallet https://github.com/Berry-Pool/nami-wallet).