Federation for unrelated data sources?

Does federation make sense for data that isn’t necessarily tied together by a foreign key data point? IE: more like querying different peripheral tables/batches of documents that are independent of each other. The schema for each set of documents is different enough that combining the data into one giant schema seems like the wrong choice.

You can still choose federation even if your entities are completely unrelated (today). If the data sources behind these federated services are different REST APIs, then, with a federated architecture, you can have a single entry-point (Gateway) into all the different data sources (through federated services). And, in the future, if you decide to actually co-related entities, you will already have most of the pieces in place.

Be aware that building and maintaining federated services come with a cost. And if that is definitely a concern for you, you can always start with a monolith graphql service. You can always migrate from a monolith to a federated architecture when there is a need for it in your project.

1 Like