🎉 Announcing Fuse.js: the opinionated framework for easily creating typesafe data layers →
Documentation
Data Layers
vs. GraphQL Federation

GraphQL Federation vs. Data layers

This shows on the left the classic workflow where we have boxes representing 'mobile', 'iOS' and 'web' development teams. In the middle we see a square called supergraph which connects to the backend teams over GraphQL, the important detail here being that all communication hapepens over GraphQL. On the right we see the fuse diagram where all frontend teams connect over GraphQL but the backend datasources connected by fuse are free to use their own protocol

Another solution commonly adopted to address the core problems at the interface between backend and frontend is GraphQL Federation. Federation composes a central GraphQL API (”supergraph”) from many underlying microservices that each expose a small part of the GraphQL schema (”subgraphs”).

Federation addresses the second and third problems at the interface between backend and frontend teams: unblocking UI development from API development and different UIs needing different data.

However, it significantly exacerbates the first problem: the differences in how backend and frontend teams think.

Federation requires that every microservice expose a schema that matches not only one UI’s needs but all the UIs’ needs, as it gets accessed by all the clients directly, with no ability for frontend engineers to transform it.

This requires significantly more communication between frontend and backend teams as backend engineers are forced to learn about requirements across all the UIs. They must also learn an additional technology they otherwise do not utilize in their day-to-day work for their frontend teams.

In comparison, data layers solve all three problems at the interface between backend and frontend teams while allowing backend teams to continue working the way they know and love without adaptations.

vs. Backend-for-FrontendsSetting up Fuse.js manually