If you make modifications, and deploy them in a way accessible to a given user, the changes must be made available to that user.
I fail to see what is unrealistic about that, or indeed user-unfriendly, unless you consider the user to be the developer and not the person on the other end of the wire.
It's not complicated, unless what you intend to do when deploying AGPL software is actually to try circumvent the license in some way; e.g., you would like some proprietary modifications to be added but still comply with the AGPL requirements.
The AGPL's extra requirements only apply if you modify the program. If you don't, then deploying it is just as easy as deploying an MIT-licensed program.
I believe that the AGPL has the same boundaries as the GPL that is if you for example run a nodejs server using a single AGPL package in your node_modules then users should be able to download the source code of your entire node app.
When you include an AGPL library your program becomes a derivative work, so the rest of your program becomes AGPL-licensed as well. The boundaries of what part of the system should or should not be included are vague, because *GPL licenses are written with C semantics in mind. So, while having a library directly in the same running process definitely makes you work a derivative, it's not clear if you the same is true if the library is a part of a different process and your program talks to it via an IPC, a filesystem, a database, an API, etc. Depending of the interpretation you may have toped-source just a tiny part of your program running on a server, or all server-side and client-side code and all supplemental scripts, tools, etc. needed for the system to run.
So, it's legally ambiguous, and since no-one has legally tested the waters the interpretation of the license can be very different, but most people prefer to stay away from AGPL code altogether.