The flash translation layers in SSDs implement things equivalent to the journalling functionality in modern filesystems, but they don't really provide any hierarchical organization of data. So you'll still need a normal host-based filesystem for the foreseeable future, but filesystem design can be influenced by the assumption that it's running atop flash storage.

There are several efforts underway to provide more specialized software interfaces to SSDs. Several vendors have produced models that expose a key-value store instead of fixed-size block storage; with those drives, you can throw away RocksDB and speak directly to the drive with the same semantics (subject to limitations on supported key and value sizes).

There are a few competing standards for open-channel SSDs that move some of the FTL onto the host CPU so that the journalling overhead doesn't have to exist at multiple layers; the different solutions here vary in terms of how much complexity they move to the CPU vs. how much abstraction the SSD still provides for the sake of software portability. Most of the potential benefits this approach provides are being subsumed by extensions to the NVMe protocol that allow the host and SSD to exchange optional hints about data layouts, GC status, etc.

SK Hynix recently announced they're working on a SSD with transactional storage support, so that the host can send multiple write commands and either commit or abort the transaction as a whole.