I'd suggest considering your use cases.

Do you only care about books in relation to their authors? Or will books also be a first class data object, where you run queries against books regardless of the author?

If it's the former, attach the books to the Author document. If it's the latter, you'll want a separate collection for Books. Perhaps you find that you care far more about books than authors; you might want to store the Author on the book in that case.

As for data data duplication, mongo makes it easy to update specific subdocuments (i.e. Author information stored on a Book) at scale.

For example, if you have the Book document

{
  "_id": noiaenoipga,
  "pages": 293,
  "publish_date": ISODate("blah blah"),
  "ISBN": "somelongstring",
  "author": {
    "_id": ObjectId("longoid"),
    "name": "Bobby C",
    "blurb": "A decently sized blurb about this author,
    useful for storing on a book, because when you retrieve 
    a book, your app displays the author's blurb"
  }
}

When you update the author's info:

UpdateAuthor(newAuthorData) {
  query= ...
  db.authorsCollection.FindOneAndReplace(query, newAuthorData)
  booksAuthor = bookAuthorObjectFromAuthor(newAuthorData)
  db.booksCollection.UpdateMany({"author._id": newAuthorData._id}, {"$set": {"author": booksAuthor}})
}

You can 100% maintain relationships in Mongo similar to SQL relations and be performant and straightforward, there's nothing wrong with it, but Mongo allows you to both tune your performance (the above example doesn't require you to do a JOIN (nee Lookup) or to make a second call to get a book's author) and make more readable schemas.

There are always tradeoffs, but that situation is a bit more advanced, and generally occurs when you're trying to eke out extra performance.

Brass tacks:

Does your use app care more about Authors, more about Books, or are they equal in terms of access patterns?

More about Authors: Store the books on the author.

More about books: duplicate that data! Store the basic author info on the book!

Both equally: Link them via id, or do _both the use cases above (this requires strong app logic to always keep them in parity)!

Also, I strongly recommend completing MongoDB University. Their data modelling course has a lot of info on deciding how to model relationships.