You can roll your own bi-directional sync between the MySQL data and FileMaker data. Or cache the MySQL data into FileMaker to work with it.
I avoid what you outline (FM front end to MySQL backend) mostly because on any sort, summary, or calculation, FileMaker will crawl to a stop if there is a large set of data. So while your web UI will become very usable, your FM UI will become highly unusable.
As a PHP developer prior to my FM knowledge, I found the PHP API fairly easy to work with.
I would stick with whatever users have the most involvement with. If the web component is smaller than the FM interface, use the PHP API. If the web component is going to be much larger than the FM interface, then I would setup a sync to pull data down from MySQL at the beginning of a user session, and push the changes back up to MySQL when completed.
It can be done, but it must be done with great care in the design and is not suitable for every type of application.
As Mike mentioned, sorts, and summaries are very slow. If you can manage the size of your found set to a few hundred or less records through views and other "tricks", FM with ESS can be made to perform acceptably. FM13 gives us some new flexibility in that now we can call stored procedures from the server without having to have ODBC installed on all the workstations.
If you need to deal with large record sets and lots of relations, my experience is you will have to employ a hybrid model to keep things moving smoothly. It is not for the faint of heart, but if you go in with realistic expectations and a good idea of the complexities, it is doable and can be made to work quite well.
If you haven't checked it out, our product at 360Works MirrorSync can quickly set up and manage a bidirectional sync from a FileMaker database to MySQL, without the need to set up DSN / slow ESS / et cetera. If you're interested in getting a temporary license key to try out the server to server syncing, or if you have any questions, please let me know!
sarah @ 360works.com