When implementing a GraphQL solution it is often advantageous to modularize aspects of the graph to simplify the understanding, implementation, and testing of the complete graph. Apollo, a popular GraphQL solution vender, provides Apollo Federation as a solution to this problem, deprecating "stitching" solutions. Other solutions, such as GraphQL Modules, implement this sort of behavior on a local server level. GraphQL Modules even integrates with Apollo Federation, and they are not necessarily mutually exclusive.
It would be really helpful to have some guidelines that indicate why you would need to federate your GraphQL implementation over multiple servers. It adds a lot of complexity. At what point does Apollo Federation make sense over a local module solution like GraphQL Modules. Why would you consider utilizing both?
These are really two unrelated concepts.
Schema modularalization is a pattern meant to keep your code organized and readable. It can be done using libraries like graphql-modules or merge-graphql-schemas, but it can also be implemented using the existing type extension syntax.
Apollo Federation is a distributed architecture akin to microservices architecture that allows you to implement multiple services that each expose an individual schema and are aggregated by a single gateway. We can view each individual service as a "module" of the schema exposed by the gateway -- but this modularization is incidental and is not the point of using federation. The point is the extra scalability you gain by implementing this sort of architecture.
So this really just comes down to why you would want to implement a microservices infrastructure in the first place. If you've got a large team working on a monolithic application, the scalability you gain may outweigh the added complexity and infrastructure costs. Otherwise, you should think very carefully about whether federation makes sense for your application.