Hi Ben! I'm the CEO of Apollo (and I also worked on the design for federation). Thanks for making this video. I shared it with the Apollo team. Yes, the ability to customize a query plan is something that we've been thinking about. That was actually the original motivation for breaking query execution up into a "plan" and "execute" phase, though there are other good reasons to do that too such as query plan caching. Customized query plans could simply be passed into Gateway as configuration or there could be a more complicated mechanism. We'd love to have your feedback and ideas.
I haven't worked enough with apollo federation or with microservices yet to give any specific ideas or problematic situations that would arise. So I don't know what a good customization solution for the query planner would be, but I'm glad to see this is on Apollo's radar!
Great summary! I was about to the do same type of video having spent a few hours playing around. This follows a great approach of splitting the monolithic GraphQL server into a set of microservices and the architecture follows well. Providing you're able to host and scale each service, and they can communicate with each other, it's no different than a REST microservice architecture making calls between services using gRPC, and exposing that through a gateway. It would be good to see what the protocol looks like for serviceservice communication for sure! Great video Ben!
Imo, I wouldn't really use it for service to service communication. I would rather use an event driven system for backend service communication, and expose those backend services as graphql services to the graphql gateway, which would be used for your frontend clients to query.
Mr. Awad, I am amazed how much I have learned from you just watching you and patterns you write in js code. I take what you do on your channel and do the same thing with Ariande in python. Ariende does apparently support federation and I can't wait to go play with it. Keep it up sir.
I was looking into grouping gql based microservices last year via stitching. This looks more elegant - but I think it's hard for an org like Apollo do a better job at query optimization than a group of database vendors. It's Interesting to watch these scenarios evolve.
The query planner uses metrics for plan optimization, that's the platform they sell. Still, I could easily imagine a simple directive that could weight the plan's optimization. Not for execution time, but things like pricing (use this, cheaper, data source, when possible). I think the investment in Apollo is well worth it for large data graphs, and this will drive innovation to make it easier for smaller graphs, but honestly how many small graphs are there nowadays. You usually need to integrate with a couple of things, even if they're your own system. GraphQL is the answer to a lot of problems, and Apollo is the most mature GraphQL solution.
Hi Ben, Is there any solution/workaround that we can accomodate the graphql subscription feature with the apollo federation concept. If yes can you share some thoughts here or can you please create a video. Regards Rigin Oommen
Great summary, Ben. Your thoughts here provide a valuable perspective. Agreed, probably not advised (currently) to break up a schema simply to address the complexity issue... but what about the use case for disparate data sources? This seems like an elegant way to handle bridging data stored in relational, no-sql and graph databases. Perhaps there aren't that many people who have that problem. Is there a better approach, currently?
data warehouse products (like IBM Cognos BI) have done similar architecture before, but readonly data analysis purpose. Stitched query handled in graph engine; affinity to utilize downstream cache;
I imagine that it also helps with scalability in terms of server performance. Beyond just scaling to a large team. Meaning it could even be a useful package to a single developer. But I agree using it for small projects seems like a mistake
Just looking the proposed solution it looks like its putting a lot of complexity and network load when the majority of the projects don't need all that.
This person doesn't know the content and posting things he doesnt know instead of a tutorial totally wasted my time.This tutorial should be renamed help me with my queries i dont know anything
![Megan Thee Stallion - Roc Steady (feat. Flo Milli) [Official Video]](http://i.ytimg.com/vi/HozPPyqW0dY/mqdefault.jpg)
Hi Ben! I'm the CEO of Apollo (and I also worked on the design for federation). Thanks for making this video. I shared it with the Apollo team. Yes, the ability to customize a query plan is something that we've been thinking about. That was actually the original motivation for breaking query execution up into a "plan" and "execute" phase, though there are other good reasons to do that too such as query plan caching. Customized query plans could simply be passed into Gateway as configuration or there could be a more complicated mechanism. We'd love to have your feedback and ideas.
I haven't worked enough with apollo federation or with microservices yet to give any specific ideas or problematic situations that would arise. So I don't know what a good customization solution for the query planner would be, but I'm glad to see this is on Apollo's radar!
Nice...
Hi Geoff, Can we combine Apollo Federation with aws lambda?
Pro trick: watch series on Flixzone. I've been using it for watching a lot of movies during the lockdown.
@Arian Toby definitely, been watching on Flixzone for years myself =)
Great summary! I was about to the do same type of video having spent a few hours playing around.
This follows a great approach of splitting the monolithic GraphQL server into a set of microservices and the architecture follows well. Providing you're able to host and scale each service, and they can communicate with each other, it's no different than a REST microservice architecture making calls between services using gRPC, and exposing that through a gateway.
It would be good to see what the protocol looks like for serviceservice communication for sure!
Great video Ben!
Imo, I wouldn't really use it for service to service communication. I would rather use an event driven system for backend service communication, and expose those backend services as graphql services to the graphql gateway, which would be used for your frontend clients to query.
Mr. Awad, I am amazed how much I have learned from you just watching you and patterns you write in js code. I take what you do on your channel and do the same thing with Ariande in python. Ariende does apparently support federation and I can't wait to go play with it. Keep it up sir.
I was looking into grouping gql based microservices last year via stitching. This looks more elegant - but I think it's hard for an org like Apollo do a better job at query optimization than a group of database vendors. It's Interesting to watch these scenarios evolve.
agreed
killer feature
The query planner uses metrics for plan optimization, that's the platform they sell. Still, I could easily imagine a simple directive that could weight the plan's optimization. Not for execution time, but things like pricing (use this, cheaper, data source, when possible).
I think the investment in Apollo is well worth it for large data graphs, and this will drive innovation to make it easier for smaller graphs, but honestly how many small graphs are there nowadays. You usually need to integrate with a couple of things, even if they're your own system. GraphQL is the answer to a lot of problems, and Apollo is the most mature GraphQL solution.
awesome video, thanks!
Hi Ben,
Is there any solution/workaround that we can accomodate the graphql subscription feature with the apollo federation concept. If yes can you share some thoughts here or can you please create a video.
Regards
Rigin Oommen
Great summary, Ben. Your thoughts here provide a valuable perspective.
Agreed, probably not advised (currently) to break up a schema simply to address the complexity issue... but what about the use case for disparate data sources? This seems like an elegant way to handle bridging data stored in relational, no-sql and graph databases. Perhaps there aren't that many people who have that problem.
Is there a better approach, currently?
With 1 schema you can handle that use case and have your resolvers fetch data from any number of sources
Hey @Ben, kindly let me know the font you're using in vscode for this video. It looks really good.
data warehouse products (like IBM Cognos BI) have done similar architecture before, but readonly data analysis purpose. Stitched query handled in graph engine; affinity to utilize downstream cache;
Hey guys, what font and themer is used in the code sandbox.. at 09:35
I imagine that it also helps with scalability in terms of server performance. Beyond just scaling to a large team. Meaning it could even be a useful package to a single developer. But I agree using it for small projects seems like a mistake
yeah for sure
no, it likes react component, reuse or compose others graphql services. I cal it Graphql Component. haha
Just looking the proposed solution it looks like its putting a lot of complexity and network load when the majority of the projects don't need all that.
yep
Hi! Can you make a code-along course on Apollo Federation from scratch?
Is this integration possible with java springboot ?
Thanks!
like before I watch 😅
Why you always concerned though. Always
This person doesn't know the content and posting things he doesnt know instead of a tutorial totally wasted my time.This tutorial should be renamed help me with my queries i dont know anything