skip to content

What is Apollo Federation?

Do you have multiple data sources in your org? Apollo Federation promises to unify your data in a single GraphQL API. Alex Banks teaches us what it is, how it works & how you can use it!

Full Transcript

Click to toggle the visibility of the transcript

Captions provided by White Coat Captioning ( Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON LENGSTORF: Hello, everyone, and welcome to another episode of "Learn with Jason". Today on the show we have Alex Banks. Alex, thank you so much for joining us.

ALEX BANKS: Thank you for having me. This is exciting to be here.

JASON LENGSTORF: I'm super excited to dig in to this. We'll talk more about what we're going to do in a minute. First I want to hear a little bit about you if you don't mind giving us a quick back story.

ALEX BANKS: Yeah. I am a web developer and a teacher. I have been doing this for about 20 years. I started in professional web development in 1998 actually. The thing about web development for me which is funny is I have been trying to get out of this career. It's always been a job for me. A job that I love, but when I started doing it I wanted to be an actor. So I moved to Chicago. I really focused on acting and I was able to build a company actually a web development company around my acting desire. Of course the web development company grew and became successful and I became moderately successful as a local actor.


ALEX BANKS: So then, yes, same thing now. We moved to Tahoe and I'm pretty much a ski bum. I have built web development and all that other stuff around that lifestyle. So it's been really interesting and fascinating for me. I see it now as an asset. When I go out and do something else I get a lot of creativity that I bring back to programming and back to web development.

JASON LENGSTORF: That's actually something I love. I have had conversations with people about this in a few different places. That idea of like being a web developer is a great thing. It's a really fun job. There is so much you can do there. But it's so much more fun if you're a whole person. Like if you're bringing your interests from outside of web development, if you're exploring other parts of being an adult, of just living a full life. You can do so many interesting things by combining your other interests with web development. Like you were just telling me about when we were doing the warm up for this you were telling me about musical stuff. Do you want to talk about the D.J. stuff?

ALEX BANKS: Oh, yeah. During COVID, one of the things is we have an oculus we didn't use much but I found a program called micro dose where you're in space and you can paint particles that move to music. So during COVID I have learned the twitch thing, how to stream micro dose with D.J.s because every D.J. took their thing to twitch, too, and had streams every night. I don't know if you're part of seeing that.


ALEX BANKS: I was able to see chroma key videos and so software relates to everything. With acting it applies there, too. With improv if you just went to improv shows and just did improv and stayed in that little you'd have nothing to draw from. Things became a copy of a copy and it gets a little bit incestuous. If you got out of the circle you had wonderful stuff to draw from. Software is the same thing. When you're doing the one other thing you're thinking, oh, I could build an app for this. Wait. When will we have true AR? We can build shadow racing. That's what I think for skiing. I want to race a shadow of myself.


ALEX BANKS: All the ideas like wave point apps, guided tours and all of those things come up because I'm not in here always trying to think about interesting things to program.


ALEX BANKS: Part of your life is a user, I guess.

JASON LENGSTORF: Yes, exactly. Right? You have to have the real world experience to inform the professional stuff. Like you said, it becomes a copy of a copy. Question in the chat. Did eve do improv with you?

ALEX BANKS: Yes. That's how we met.


ALEX BANKS: We were in an improv group together.

JASON LENGSTORF: That's Eve Porcello.

ALEX BANKS: Eve is my wife, partner. We knew we could work together. We did a two person show not long after we met. Maybe a year or two. We wrote and produced a show and had kind of a big Chicago improv guy as the director. It was a blast.

JASON LENGSTORF: So I'm going to gush about Eve a little bit. She's one of my favorite educators in the space. I feel like the improv has made such you can see when somebody has improv experience as a presenter.


JASON LENGSTORF: She's so comfortable and fluid and funny and adaptable and things can go wrong and she doesn't she just keeps rolling. That's a rare and wonderful skill. I recommend her stuff for that reason. She's so much fun and engaging to watch and learn from.

ALEX BANKS: One of the biggest keys is rehearsal. We have written shows and stuff. Rehearsal is uncomfortable. You're in the living room, starting to act like characters and stuff. Once you get used to the fact that, hey, do this presentation on your feet as much as possible so it becomes like a monologue. Then you're really comfortable. When stuff happens you can improvise with it because it's your monologue. You're not like, what am I doing next?

JASON LENGSTORF: Awesome. That's very cool. Let's talk about the tech for today. You're an expert in graph QL. It's a huge discipline. It goes from way in the back, the kind of computer science y actually graph specification to the front end where it's just I'm sending off a request to an API and I don't really know about graph QL outside of forming a query. So what part of that spectrum are we going to be looking at today?

ALEX BANKS: We're going to be looking at the API part.


ALEX BANKS: Creating schemas and standing up graph QL APIs. We're going to stand them up as separate services and have them communicate with each other. I was going to talk about why we would do this and when to do this. You know, when we analyze all the wonderful tools in the arsenal it doesn't mean we have to use every tool on every site. There are places to consider federation or think about as your application grows you'll go there.

JASON LENGSTORF: Yeah. So let's talk about what that means, right? When you talk about federation, or maybe we can start by talking about what existed before. So originally, you would have a rest API and lots of different end points in the rest API.


JASON LENGSTORF: If you wanted to get your blog post you call one end point and then comment IDs and another end point for the comments and so on and so forth. It all comes back in one kind of the way you expect it, right? This gets tricky because you have multiple services where you say I want my GitHub data and I also want to get my custom database and then I want to pull in this other thing. In graph ql you start to get out of the model now where you're like I have this unified graph here, but there is this other stuff out elsewhere. It doesn't really make sense to bring the GitHub stuff in house. This was kind of like where schema stitching came from.


JASON LENGSTORF: So schema stitching if you're not familiar with it, is when you basically create an alias in the graph ql that says, hey, if somebody makes this query, send it somewhere else. Like send it to GitHub and then bring it back as if it was coming from this API or this graph ql server.


JASON LENGSTORF: Is federation another way of saying schema stitching?

ALEX BANKS: There's a technique for all of that. The architecture for all of this isn't graph ql. It predates graph ql. It's the micro service architecture. Kind of like we need to embrace this. It's really how if we are working at a large company you have to do this. You have services all over the company you're using. If you are working for yourself it's like using things like Auth0 even or stripe. You're working with this architecture where you are putting the need to do that functionality on a completely different team, a completely different company and so on. It's an architectural principle happening in all the applications. Federation is just a solution to make it work easily with graph ql. As you write schemas and stuff, everything will plug together nicely. What we are doing is micro services and federation is an API orchestration layer. If you're familiar with orchestration layers they essentially juggle and grab the information from the underlying services and send them all up through one end point. So as you make a request for a page whether you use rest or TCP or whatever you're using, this concept of orchestrating several services behind one layer has always been there. Graph ql is all about one player. So it just makes sense. If you build the services in graph ql, they will automatically fit together.


ALEX BANKS: So build it using Apollo Federation and they automatically fit together. But don't worry. If you have a rest API that you don't have as a graph ql API yet one of the neat things about graph ql is you can make rest calls to the API and still grab the data and send it out with graph ql. So all of the stuff we're going to learn today, everything we are going to look at can be adopted incrementally. You can use rest APIs beside graph ql APIs, but moving forward if you embrace graph ql you will be able to orchestrate micro services.

JASON LENGSTORF: I'm into it. Let's dive in.

ALEX BANKS: All right.

JASON LENGSTORF: This is going to be awesome. I'm going to switch over to the other view here. Let's get into the coding view.

ALEX BANKS: So I got a couple of drawings. Let's see. Here's the twitch chat.

JASON LENGSTORF: While you're looking at those we have live captioning on the show by White Coat Captioning. Thank you very much for making the show more accessible. The live captioning is made possible by sponsorships from netlify, FAUNA, SANITY and Auth0. It's so great that so many companies are willing to kick in and make a live stream more accessible to the broader community. So thank you very much. You can see the captions at And so then do you have a link for me?

ALEX BANKS: I'm going to put it in the chat. I have some drawings. I watched your show the other week. I was like, oh, maybe I could draw these live. Then we were like, oh, don't do that. We only have an hour. I have a couple drawings I want to show. Just to take a step back for people who may not necessarily understand what the micro service architecture is, why we have it or what the point is I want to talk about scaling. The point of this is scaling. Growing. It doesn't mean it's growing your user base and application, your code base or it could mean growing your clients, your company. If you are growing it's time to start thinking about scaling. We think about scaling with the representation of a cube. So we would assume down here in this lower left hand corner of the cube what we represent with that is a monolithic application meaning one code base that everybody works on running out of one instance everybody hits. Basically the first applications we have all built, right? It's just one thing running out of one instance. As we go to the other end of the scale cube


ALEX BANKS: Oh, I got it. As we go to the other end of the scale cube we scale by breaking the one thing up into many different pieces and many different parts. So this means instances, putting some of the code someplace, using third party services and so on. Every application falls somewhere within this continuum of being an absolute monolith to a totally distributed micro service architecture. You don't have to be at one you know, when you start you're going to be moving from moving the monolith into a scaled application so you don't have to have it one or the other. You are somewhere on this. So the horizontal axis is instances. So I can spin up more instances of the application. That's like, okay, I have a lot of people using the app. Let's run it on other processes or other computers and put in a load balancer and let people hit it. The second line on the cube, our Y axis is micro services. So we can break up the application by functionality. Think of something like Auth0. They'll take care of all of your user and account based interaction, storing the data, authorizing users and all of that for you so you can build other parts of the app. That's a pretty good example of one of those. The Z axis is what we call partitioning. This is typically more about database stuff.


ALEX BANKS: This means our database is getting overloaded so maybe we start to break it up by region or break it up by records A through Z over here or A through M over here and A through Z over here and so on. Those are the three directions you can move on the scale cube as you scale the application. Instances on the X, micro services on the Y Axis and data partitioning on the Z axis. So we scale instances by cloning. These are the drawings I have for you.


ALEX BANKS: I didn't get Maggie to draw them. Let's consider this. You have an advice booth, right? You're giving advice and people are asking you questions. So you're realizing, oh, wow, I have a lot of people asking advice. It's time to grow my advice group. So if you are growing it by instances you'll get buddies who are good at giving advice and open two or three more windows that can handle all of the crowd. So now everybody is lining up behind their own little advice window. We see this scaling at the grocery store. Can we get this aisle open so we can handle all of this traffic that we have here? That's what we think about with cloning or scaling horizontally. Those are instances, right? So we just get more of the same thing. Instances, you can do it right on your computer. You can run multiple instances locally behind a load balancer on your computer. We run things on different ports and today port 4,000, 5,000, 4001 are all separate instances running locally on our computer. Then the whole thing about that is we can run them across computers, on the cloud. You can really scale out instances as the application becomes popular. And then once you're global this is what you're going for is having instances on the edge. So in data centers you have instances of your advice booth running everywhere so people can get the information locally without having to send requests around the world. That's pretty common. Horizontal scaling. But we're talking about scaling micro services. Real quick I want to go over partitioning because I want you to think about what the Z axis means. Consider, again, we have another booth. Here you are with records. We're going over to get the account information or something like that. Once we have a lot of people who need records, one booth will slow everything down for us. We could obviously create a horizontal scaling and open up other record booths but there's kind of a better way. We can open up other record booths by some sort of partition. So now if your last name is A through K, line up at the first booth, L through P at the second and Q through Z at the third. Now we have applied more booths and we can handle more of the crowd but not necessarily like each booth does the exact same thing.


ALEX BANKS: From a data standpoint each of the booths has different records, different requests. So that's the horizontal partitioning also called sharding. If you are coming from the database standpoint you have heard of this. Databases like mongo all support partitioning, sharding all that stuff.

JASON LENGSTORF: The stuff you're describing is a lot of the reason why people are starting to migrate towards stuff like graph ql or the jamstock architecture. The idea of putting things on CDNs. That abstracts away so much of this. You know, I have been building stuff for the last couple of years on a CDN architecture because it means I haven't had to think about multiple instances or getting things globally distributed. It's happening in the background with the services I use. That's netlify's whole deal. Put it here and it shows up everywhere around the world. It just works. You never have to think about scale.


JASON LENGSTORF: So what I think we are about to talk about is what I'm excited about. You're about to tell us how to do it for data.

ALEX BANKS: Yeah. You're absolutely right. One of the reasons we're doing it is because every large tech company has done it to handle the traffic. To handle massive amounts of traffic. So I really got deep into this. We helped onboard Yahoo! engineers and it was the first place with a service and a team for everything. We were kind of teaching people how to touch those tools and do stuff with them. Since then I have seen the explosion of tools for us to use, not behind the wall of a company. People have been doing it for quite a while. Now we have netlify, Auth0, stripe. We're working in this environment anyways. Nothing new. We're going to learn to do it with graph ql. What we're going to do, the federation part is really about microservices. That's the Y Axis on the scale cube. Now consider the advice booth again. We have the advice booth and too many people to give advice to at once. Line's around the block. The other way to scale it is by specialty. Maybe you have somebody who specializes in financial advice, a booth that specializes in love advice and maybe a booth that specializes in wellness advice. Now, the key to this type of positioning is, one, you don't have to hire an employee that knows everything and can give advice about everything. Now you're hiring experts in finance and love and wellness. So you're giving better advice and handling the crowd. As we can see, we also have a lot of people who want love advice, right? Wellness, a couple. Finance, a couple people. But love is what everybody wants to know about. All of these things work together. So I can horizontally partition the app as well. So we have broken it up into microservices, but because love is the biggest booth that we have I have horizontally partitioned that and split it up into separate instances. So now we have three love booths all giving advice. They can handle the love crowd. It allows you to focus on things like booth by booth if you want to think about it.


ALEX BANKS: When we do things along the Y Axis or when we are scaling along the microservices axis, we are breaking up all our applications into special functionality. Kind of like specialization of labor, right? This is how all civilization exploded once this concept came into play.

JASON LENGSTORF: I didn't realize. This is going deep. We're getting into the secrets of human success on the planet. It was microservices all along.

ALEX BANKS: We have booths specialized for finance, love, and wellness. If the booths are big you treat them like little applications. Then each of the services, the whole point is they have their own tools. You can build every service out of your own language. You can use whatever database you want. The real reason we do this is because it's not just about scaling the applications. It's about scaling the company, right? If we are all touching the same code base, that's a nightmare. You know? We are all going to constantly be afraid of breaking something somebody else did. Also, it's too much to put in your head. When you have a company like this monolith. We have a front end and admin portal, information about shows, theaters that the shows are in I guess that's a movie theater thing or a ticket thing where we can search for shows or concerts. Then checkout and customers. The developers, d/b/as and back ends work on the code base. You better believe it's slow and the quality goes down without a lot of checks and balances and hoops through the production process which makes it slower. So the real reason we actually do this is so we can break our organizations up into smaller teams that are focused on one product. Because if I have a team of d/b/as and I put them with front end developers and back end developers, that small team can work together to build a full application that handles part of the system. Then you have a beautiful show catalog. Then you have people over here working on theaters. What this allows us to do is put these people in separate buildings, right?


ALEX BANKS: If we're doing this right none of these people need to talk to each other. If you really want to go there, that's the goal. Doesn't always happen.

JASON LENGSTORF: When I was at IBM this is kind of the migration that we were in the process of, right?


JASON LENGSTORF: Before I joined they had one million line java monolith, this big old beast that was hard to maintain because people would touch something and it would break. They would break somebody else's code and not realize it. So they went the microservices route. To talk about the incremental adoption you can do here they didn't do microservices by rebuilding everything as microservices. They spun up 35 parallel instances of the monolith and gave each one to a team and said, look, do what you want and you can't break other people's code. Over time they chipped it down to get to the microservices they owned and the quality of the code tremendously increased because you didn't nobody can have context on a million lines of code. But you can absolutely have context on the one corner of it that's yours.


JASON LENGSTORF: So it was a huge difference. I think these teams are spread across China. IBM has offices in, like, several dozen countries, right? So people were all over the place. We talked to some teams, the ones we worked with frequently. Other teams existed and we knew they were there. We never had to go back and forth. We couldn't break their stuff, take them down. We just worked on our initiatives and everything was cool.

ALEX BANKS: Yeah. Exactly. Then you get to focus on that. An example, again I have been saying Auth0 and stripe a lot. Those are examples of this working successfully.


ALEX BANKS: You can't call up a stripe developer and say I want you to change it to work like this. You can make a feature request. But you're getting information through documentation.


ALEX BANKS: That's why graph ql is great for this. Graph ql is like documentation for your API. So we're going to implement this structure and here's another screen where maybe instead of having a team work on checkout and one on authorization we user vises third party services for that and now with the developers we have we can break them up into three. It's about scaling your applications, your organization. The third part I like to think about is scaling your clients.


ALEX BANKS: If you're sitting back and you're a web developer and you just develop websites for people. You just crank them out. That's what I did when I met Eve doing theater. New client. Another proposal, another website. A lot of the stuff you're doing, similar code. Once you have a good boilerplate, you're reusing that code. I would watch this and think, hey, I'm not a big company. I don't really have a lot of developers. This federation stuff isn't for me. But it absolutely is. If you're growing your clients one of the things you're going to notice is you're doing the same thing over and over again. Like I cannot tell you how many times I have built a log in form.


ALEX BANKS: Authorization, create a calendar in so many languages through the years and it's always been sort of a struggle.


ALEX BANKS: When we started doing Auth0 I was shocked because I was a web developer for a long time. I was like, this is hard and you have to learn to do it over and over again. If you are running an organization you're like I'll copy and paste all of the auth. We'll copy and paste. But you can build your own account service and then you can have all of the users for all of the applications that you use in one place which gives you more control. But you don't have to build the account service for every single one of your new clients. You have the ability for them to log in and create accounts and all of that that you can just plug in to the graph ql API. That's what I want to do today.


ALEX BANKS: I want to show you to build an account service. Something like a smaller, more educational version of Auth0.

JASON LENGSTORF: I'm stealing that phrase. A more educational version which you can read to mean probably only mostly works.

ALEX BANKS: Not handling errors is what that means. Pretty much as far as we're going to get.


ALEX BANKS: That's what we're doing. We might as well get started.


ALEX BANKS: So what I want you to do is start up and build a new Apollo server. You can do it anywhere you like. You can create files locally. I have only done it locally, but I think it works in code sandbox and that, too, if you want to give it a shot. I'm going to have a local repository for us to download with the demonstration of this and that's what we'll plug into. I have an account service and we want to plug your application into the account service.


ALEX BANKS: What we're looking to build and we can get ideas from chat and whatnot. We need a small application that would mimic something that users could add posts. So that could be like a dictionary application where I can post a term and a definition or maybe just a note application where we post a note and a date. Maybe it's as simple as two words. What I use for this in the new book "Learning React" we use a color organizer and I have the application we're going to use as a demonstration. Basically when we design stuff to teach we are not looking for a lot of fields, right?


ALEX BANKS: We don't want to fill out ten different fields to make it work. We only want to post one or two fields like a definition or color or something like that.

JASON LENGSTORF: Okay. I think we should just do free association.


JASON LENGSTORF: We'll put in a word and decide what the next word is that we think of and maybe the chat can help.

ALEX BANKS: Yeah, yeah.

JASON LENGSTORF: We'll pick a word and the chat can free associate. Remember, this is a PG 13 show. I'm going to get init and open it up.

ALEX BANKS: Let's start with the schema. When I say CRUD all we need is a CR. All we have to do is create a word or a word combo or something and then query all of them to see what the words are and maybe query an individual one. What we want to think about the words is full on posts like images or tweets or something like this. We are keeping the data sets small so we can get it done.

JASON LENGSTORF: Okay. So we'll say, like, word will be a string.


JASON LENGSTORF: Association will be a string. I think that's probably enough.

ALEX BANKS: Give us an ID just for the fun of it.


ALEX BANKS: I don't know if we are going to make it this far. But if we can let other services associate with this you need a unique identifier for that.

JASON LENGSTORF: So we probably want like a get all to bring us back a free association if I can spell it right. I should copy/paste it.

ALEX BANKS: Yeah. Maybe look up one of them. No, let's not do too much.

JASON LENGSTORF: Just the all.

ALEX BANKS: I get excited about doing too much and we don't make it as far as we could.



JASON LENGSTORF: Or just add free association and that's going to be something like this. Then we need an input and that's going to be okay. So I have a question for you. You've done more schema design than me. Also I realized I'm going through it and not explaining what I'm doing.


JASON LENGSTORF: So maybe we do first things first. Let's talk through what we are accomplishing here.


JASON LENGSTORF: So the first thing is we have defined two built in graph QL types, query and mutation. A query is a read operation. A mutation is anything else. What we're doing here would be the create. We could also do an update. We could also do a delete. Those would be mutations.


JASON LENGSTORF: I defined a type and if you were defining a database table it's just a little more what I consider to be human friendly. We're saying this is what it's called. This is what it has. This is the data type that goes in it. The exclamation points mean it's required. No empty fields basically. For a mutation, we are saying that when someone calls this mutation we say we want to add a free association, I have to provide this data no. I did that wrong, didn't I?

ALEX BANKS: Yeah. That goes into the arguments if you're doing it there. Add free association, you can return the free association from that. Or, you know, if we were doing our good job work we would create a mutation type and stuff. But it doesn't matter. One thing I like to return on mutations is boolean. Old school return true. It doesn't matter. Just means that it works.

JASON LENGSTORF: Here's my question. We're going to have the mutation type where we add an argument. This will be called a function basically. Add free association and we have to provide these values. So when you're designing inputs, I have seen it done a few ways. Is it better to do an inputs field.


JASON LENGSTORF: With something like this or do you prefer to have, you know, word like do you put stuff straight in?

ALEX BANKS: That's what I do. I try to keep things as simple as possible. That means if there is only one or two arguments I would put them there. Look, you just deleted a bunch of lines of code to do that. As soon as you get to the third argument that becomes difficult.


ALEX BANKS: I go ahead and put them in the input fields but the design process is one of always growing. Just a neat little side note, with input types they are actually the forms. They usually look like the forms on them. You can create something that reads input types and automatically generates forms. Sometimes you can think of input type as being like, okay, what does this form mean and what am I going to see on this screen and you can group stuff like that once you get to the UI level. When I'm starting like this and we're messing around I do what you have done there. There's only two arguments and it's easy to put them there. I always prioritize simplicity. That's my goal. If we don't need the other type, the other thing right away, I try not to use it. I know we're going there. Code will constantly change. There will be a day we'll come in and delete the arguments and add the type. But this is how we're getting it started for now.


ALEX BANKS: One other key I want to add is if you haven't seen much graph ql this is why I love it. We haven't built an app at all yet but we are defining what to build right here. We have a way we could talk about this and decide where to put the arguments. You can talk with your whole team about this stuff before anybody sits down to code the application. I think that's what's fascinating about using graph ql.

JASON LENGSTORF: When you say whole team it's not just developers. We can put it in front of executives and say, look, this is the data we are collecting. Do we need additional data here.

ALEX BANKS: Exactly.

JASON LENGSTORF: That's really powerful. It's difficult to do if you're showing somebody a java script object.

ALEX BANKS: Right. Sometimes developers want to take all of their stuff and they don't necessarily want to show the product owners or project managers because they assume we know about the tech stuff. But at the same time this is a level that you can communicate with everybody your stakeholders, owners. As a developer, I would rather have my product manager know exactly what I'm going to build so there's no confusion. You told me to build this and return these exact types. You know, this is what this is all about. So I love graph ql for this.

JASON LENGSTORF: Yeah. We'll look at it in a little bit here. But the really exciting thing about defining types and having these strong configurations here is we're going to get things like auto completion. We're going to automatically document code and automatically validate code. All these things that aren't impossible to do with a rest API or other API specs but you have to add extra stuff. You have to implement the open API spec, validate it, make sure your docs are up to date. With this, you can't ship an out of date documentation for a schema because the schema is the code. You're writing your docs and your code in the same place. The power of that is really difficult to overstate.

ALEX BANKS: Yep. The thing is I have had a lot of people like I don't like graph ql, and what do you think of O data and there is no point to graph ql. I look at them do you like type systems? I like it. Graph ql is a type system for API. Then you see the lightbulbs go off. I like type systems. I don't like graph ql. I like type systems. It's fun. All right. Let's make this thing work.

JASON LENGSTORF: Let's do it. You might have to talk me through this part. It's been a while since I have built a server.

ALEX BANKS: Me, too. You could do this in one java script file. Create an index.JS or something. If you want to do installs first install graph ql and Apollo server.

JASON LENGSTORF: Okay. And then in here I need to import is graph ql a named import?

ALEX BANKS: I just import it as text usually. I usually read it. I think they probably have good web pack tools we can put in play but we don't really have any now. I want to avoid that.

JASON LENGSTORF: Okay. Then I need is it default export, right, Apollo server?

ALEX BANKS: I didn't pull that up. Let me get a cheat sheet here. I don't think this has changed but what I have had to do unless I put in a web pack tool and I haven't found one I love for importing the graph ql. I have to actually do a file system read file.


ALEX BANKS: So you want to import the file system and do an SF read file synch and pull it in as text because it's just a text file. The last time I was messing around with the importers it didn't do everything I wanted it to do.


ALEX BANKS: Exactly. Read file synch and import that. There you go.

JASON LENGSTORF: Oh, I'm in node. Out here writing.

ALEX BANKS: So the Apollo server, you want to destructure that and also grab GQL. Just Apollo server. You don't need the GQL because we put the types in a separate file. I'm sorry about that.


ALEX BANKS: There you go. Now you need resolvers and you can create them here. So create an object called resolvers.

JASON LENGSTORF: And let's see. For this one we need to do

ALEX BANKS: Query and mutation. Show everybody is schema real quick. This is a fun part. So we're going to just match what we created in the schema. We have a type query, a type mutation. Eventually you'd probably have a free association type listed in your schema. We don't need that just yet because we are not doing any custom fields off of that. One really important thing to notice if this is your first time seeing graph ql is that the schema definition defines what we're going to build and the resolvers are where you actually do the work. So you'll notice they look alike, like mirrors. Resolvers are functions that return data that matches the type you defined. So this is what I really love about graph ql and I love telling students this. They're like, can I load data from here, here and here. I'm like, it's a function. Whatever you can do in a function. In a function I can get data from a Twitch stream and a database and the weather and juggle those things to return whatever I want. That's the beautiful thing about it.

JASON LENGSTORF: This is actually exciting, too. What that means is we can do something like this where we do, like, ID one and word and then association. This works now. Once we plug it in, this will return data for us. Maybe we should do that.

ALEX BANKS: But we're going to add to that. We want to put it in a variable. We can just do it locally like a local variable. Since we're going to modify the array

JASON LENGSTORF: I get what you mean. Yeah.

ALEX BANKS: We need a place to add that. Right there will work. Perfect. Beautiful. See that? That's crazy. We're just returning that array. And get all free association if you look on line two of the schema it says we'll get an array or list of free association types. That's how all of that matches up.

JASON LENGSTORF: Notice here, too, this is a java script object with an ID, a word, an association, ID, word, association. This is an ID and that means anything unique. This could be like ABC, 123 or whatever. But for the word we know it will be a string. Association will be a string. So I didn't have to know things. I was able to just look at this and say, oh, yeah, I need an ID, word and association and I know what types to return for that.


JASON LENGSTORF: I can't do that if you tell me what a rest API is. Oh, hit the user end point. Okay, what's there? With this, I know exactly what's here.

ALEX BANKS: Yeah. When you document and explain it with notes, too, you even know more about what's there. This is sweet. Should we spin it up and test it or do you want to build the push, too?

JASON LENGSTORF: Let's spin it up and add a push.

ALEX BANKS: So create a new server instance using Apollo server. You want to put I usually put it in some sort of a start. Make it a start asynchronous function and then call that yeah. There you go. So this will start the application, right?


ALEX BANKS: We're going to create a new server. We send the server and object the type defs and the resolvers.


ALEX BANKS: That's all. On the next line you want a server.listen.

JASON LENGSTORF: I feel like this got way easier than I remember.

ALEX BANKS: Yeah. Wait 'til you see federation. We're going to add two lightning lines to this and ding!

JASON LENGSTORF: So now just pick any port, right?

ALEX BANKS: Yeah. Let's see. We're going to be using a lot of ports. I'm going to have something with a lot of ports. Let's pick port 4003. If that's okay.


ALEX BANKS: So start on that port and I do a dot then because it's a promise or 08 for that. Then just log that's a promise, so

JASON LENGSTORF: I understand.

ALEX BANKS: I like the dot then thing. Then you can get the URL. You can destructure the URL from the argument sent to that and destructure it.


ALEX BANKS: You can use that to log to the console that the server has started and listening.

JASON LENGSTORF: Okay. So 34 lines of code. Plus 13 lines of schema. Have we built a server? Let's find out. I need to call start.

ALEX BANKS: Oh, yeah, good.

JASON LENGSTORF: All right. So let's call start. We'll see if it works. I'm going to do that by running node index. I missed a thing.

ALEX BANKS: What does it say?

JASON LENGSTORF: Find in resolvers but not in schema.

ALEX BANKS: Let's see. Mutation? Let's look at the schema and resolvers.

JASON LENGSTORF: Add free association. Oh, my bad.

ALEX BANKS: Associations. Oh, yeah. It wasn't named right. Sweet. Now you have a graph ql server. I hope people are watching this that have never seen graph ql so they can see how quickly we can stand up something silly.

JASON LENGSTORF: What's going on? Did this just there we go. All right. Here's the graph ql play ground and this is where things get exciting. Check this out. We are already here. I'm going to just get all free associations. Nope. That's not right. What happens next? I can go in here and this is a thing you have to know. If I hit control space it auto completes for me. Look at that. There we go.

ALEX BANKS: Yeah. You can select what you want, too.



JASON LENGSTORF: We don't need this ID. Boom, no more ID.


JASON LENGSTORF: That's incredible. But it's even more exciting. Look. We have buttons. Here's the schema. This is just straight up there's our schema. That's cool. This is cooler. We know what we can do and then we can click into it. It's going to show us what we get. It describes what a string is.


JASON LENGSTORF: That's amazing.

ALEX BANKS: I always tell everybody you can actually comment those fields. Not now but sometimes funny things happen but you can write comments on the fields so you can define them. You can say the word is the word that we are going to associate and users add it or all that other stuff. You can put emojis in which is fun. When you float over everything inside the play ground you see the definitions come up if you have created them. Right there it says string. But if you put a description in there it would pop up. So you can say, oh, that's what that is. It's all about communication, like what the API can do. What the types are.

JASON LENGSTORF: Yeah. Really, really cool stuff.

ALEX BANKS: All right. Let's add the post, add the mutation.

JASON LENGSTORF: Let's do it. So in here I have this add free association. So we decided this is going to get a word and an association. So I know that's what's going to come in. And then I just need data dot

ALEX BANKS: That might be the second argument. Hang on. It's been a while since I have done one of these.

JASON LENGSTORF: Oh, right. It's going to send the root.

ALEX BANKS: Right, because the root is the first argument.

JASON LENGSTORF: So the root is kind of like a vestigial field.

ALEX BANKS: There's a lot we can do with the root. I think we have to use it for our stuff. The root is something I want to explain or talk about. Maybe once we get past this. It's all hypothetical now. It's easier to see it when you see it.

JASON LENGSTORF: Got it. Okay. So we are going to concatenate, do the ID, data dot length.

ALEX BANKS: Perfect.

JASON LENGSTORF: We started at one so we need to do a plus one. And then do the word and the association.

ALEX BANKS: That's perfect.

JASON LENGSTORF: All right. Then because that worked we're going to return true. Because it expects a boolean.

ALEX BANKS: Let's talk about this. Usually when I code this is how I start, right? This is education friendly right now. Meaning that what we would actually do typically in the real world is return a type that let us know how the mutation went, whether it was successful or not. And maybe also some information that you can query about what you just added. You can do whatever you want off graph ql. When I start building things I put in the boolean and think about that later.

JASON LENGSTORF: We can do something like pull this out into like

ALEX BANKS: Yeah. And we just need to send the word and association again. Yeah. You can do the business logic and a separate thing. You tie it to the resolvers.

JASON LENGSTORF: Then we can just return add free association. And I would need to make this I can make these async, right?


JASON LENGSTORF: So now we are effectively we have created a mutation. We have the business logic here. It runs asynchronously. So at this point we could you know.

ALEX BANKS: Here's the beautiful thing. This is what I say. We don't need it to run asynchronously now, right?

JASON LENGSTORF: I guess I was thinking like if the end of the story is this ends up being a call to a database or something.


JASON LENGSTORF: You would need to run async.

ALEX BANKS: Cool. I get that. The only thing I'm saying is I don't do it until I need it.

JASON LENGSTORF: That's fair. Fair enough.

ALEX BANKS: I'm letting the users know you don't have to take these steps to do things until you need to take them. Just because we are not doing anything asynchronously yet. You have it set up so it will work. Let's try it out and make sure we're actually getting

JASON LENGSTORF: Okay. So I have my mutation. Is this hot reload? No. Start it again.

ALEX BANKS: Yeah. You can start it using node mon or something, too. I love to run the query once just to make sure that something else hasn't happened.


ALEX BANKS: The query works, yeah.

JASON LENGSTORF: Now I'll create a mutation. It's going to auto populate for me. It wants a word. I'm going to choose the word corgi. Chat, free associate. First word that comes into your head with corgi. Party, done. So run a boolean, get back true.

ALEX BANKS: And run the query again.

JASON LENGSTORF: Uh oh. I might be bad at java

ALEX BANKS: Do you have to say data equals data and override it?

JASON LENGSTORF: Yeah, correct. Yep. We need to do data equals which means we need to make this overridable. Okay. Stop and start that. Try again. That works.

ALEX BANKS: Yay! Hit play.


ALEX BANKS: Yay! It works.

JASON LENGSTORF: We can do one more just for fun. Let's do skis. Free associate, chat.

ALEX BANKS: You want me to? I'm sorry.

JASON LENGSTORF: No, no. Chat's got us. They got us covered.

ALEX BANKS: Sweet, great.

JASON LENGSTORF: There we go. We have built a full functional graph ql API.


JASON LENGSTORF: The next steps would be to hook up the data which is a little bit of a draw scenario, but there are other episodes of this show on how to do data. There are tons of resource on how to hook it township a graph ql. I imagine you and Eve have lots as well.

ALEX BANKS: Yeah. The rest is just java script. Get good at node database. All the code you typically use to do it is the same. The graph ql is just the structure around what's getting returned.


ALEX BANKS: So let's go back


ALEX BANKS: I'm sorry about that. Let's head back over to the schema. The inevitable next step is to say, well, wait a second. You can't just randomly post stuff. We're not recreating reddit or something. You want to know who is doing this association. So you come here and say, okay, now we probably need to add stuff for authorization. Specifically we would add, I don't know, a type or add to the mutation. Specifically we'd add to the mutation. Add a type for user. I'm sorry.

ALEX BANKS: A type, okay.

JASON LENGSTORF: It took me a second. I was thinking.

ALEX BANKS: So they would have an e mail address and ID. I like to use e mails as IDs for users because they're unique. An ID is a unique string. It makes sure everything is nice and unique. Maybe they have a name, avatar and all that stuff. So we have this idea that someone is adding the free association. We want to save data about them, too. That means under the mutations we add a create account, log in or authorize.

JASON LENGSTORF: So with this we want

ALEX BANKS: E mail, password probably. This would probably have so many fields you would make it an input because you want the user name

JASON LENGSTORF: Do you do it like this? Or

ALEX BANKS: I specifically call them forms because I have them so linked to forms in my head.


ALEX BANKS: I call it input but my naming convention isn't input. It's form like the user form. I'm thinking about it already like, oh, these are my screens. How do you break things up? How do you break your user inputs up and decide maybe these should go on this input type and these go on this input type. We have wire frames so each of the screens are just an input type we're using, typically. That's just me.

JASON LENGSTORF: So we are not going to keep the password in the schema.

ALEX BANKS: You input it as a string, right? When it comes over it's not a password when it comes over. Hopefully you have HTTPS set up and everything is encrypted. We don't put password on the user type so you can query it. These input types are just for the data you're sending. Yeah. We send our passwords. If you wanted to, you could go an extra edge and enscript the password on the java script side and decrypt it at the server.


ALEX BANKS: But that's what https is for.


ALEX BANKS: So if we do this we have to do it every time we get a new client. This client wants free association. What if somebody wants photo sharing? We want users and we want them to log in. What we should do, Jason, is build a federated account service for all of the stuff we're going to build.


ALEX BANKS: And federate it. So we're going to the moon highway cloud. It's a GitHub repository. It's a little like the under construction death star. It's fully operational. You can use this to destroy a planet, but it's still under construction. There is a lot of stuff here that hasn't been built. There are some issues for stuff if people want to play around. This is all purely educational. Everything we're doing with this, this isn't like our cloud. Like here's our applications and how we run our classes and everything. It's just an educational infrastructure for what a cloud and what microservice and all that stuff looks like.

JASON LENGSTORF: I'm assuming you want me to run it locally.

ALEX BANKS: We are going to run service by service. You can see it's a collection of different ones. I took it out because I knew I would be sharing this. We could use PM2, docker to spin up services for us. Now you're getting into dev ops a little bit. We want to see there is a service on 4001 and stuff like that. The first one to run is account service. Navigate to service dash accounts. Do an npm install.

JASON LENGSTORF: Boy, I don't know if you had a chance to catch Sarah Dasner on the show this week but the chat bombed us with sound effects. I don't know where you're at, chat. I'm going to regret that. Okay. It's installed.

ALEX BANKS: Let's start it. Oh, this requires mongo. Do you have one set up?

JASON LENGSTORF: Unfortunately.

ALEX BANKS: We can set it up real quick. Do you have brew?


ALEX BANKS: Let's look at brew services list.

JASON LENGSTORF: Okay. We'll move this up a bit since the chat seems to want to bury us in boops.

ALEX BANKS: Brew services. Doesn't look like you have mongo there.


ALEX BANKS: Brew. I can't remember how Toni stall. Brew install a mongo db.



JASON LENGSTORF: Update homebrew. Oh, no.

ALEX BANKS: This will take a second. This is a good place to chat about why I don't use databases in classes. I would prefer everybody to just be able to start this without taking this step to make sure you have mongo. But originally when I designed this what I was trying to demonstrate is, look, the accounts is using mongo and the review service is using their own funky database. That's the real idea behind microservices. You as a team get to decide what to use. I'm eating potato salad.

JASON LENGSTORF: I'm sorry. Chat's helping. I'm with you on that. Running databases locally is one of my least favorite things.


ALEX BANKS: We could probably is that working or did it freeze?

JASON LENGSTORF: It's doing its thing slowly.

ALEX BANKS: We could take the next step. Go into the next service while we wait for this one. If you want to start up a new window and we'll get out of the service accounts. We want to be in the root and go to service colors.

JASON LENGSTORF: Okay. Get everything installed.

ALEX BANKS: This one doesn't use a database. We should be okay with this. Let's go ahead and start it. Do an NPM start. Yay! So we can go ahead and while brew is installing we can look at local host 5001 to see what the service does.


JASON LENGSTORF: So we have all colors, total colors. Let's look.

ALEX BANKS: A couple things added. You can see the query added entities. Service and stuff.


ALEX BANKS: What federation actually is a technique for having the graph ql APIs talk and send queries to each other. When you create a federated Apollo server it adds stuff to the regular schema.


ALEX BANKS: So you can go ahead and list colors. It might be an empty list now.


ALEX BANKS: We'll talk about that later. See all the stuff added entities, service query. Oh, my bucket!

ALEX BANKS: They are there so it can communicate. This is the special Apollo magic we have to make a change to sprinkle on your service. If you go to the schema you see it, too. So in the schema tab, federation works with directives. We'll create entities and do things. So it's really a way of working with graph ql which means this architecture, you can create in other languages and people have. You can start to use python, java and other things because Apollo documents how this works very well in case you want to reproduce it. But basically you are creating graph ql APIs that can talk to each other.


ALEX BANKS: That's the color service. We got it up and running. A key to the color service is let's go to the query and see if we can run it real quick. I guess we don't have colors yet. We need to add colors and we need users for that.


ALEX BANKS: There's another service we need to start for this and that's the review service. We have two awesome services here. We have constitution account service that manages the accounts for applications in moon highway and we have a review service we can use to add reviews to any applications across all moon highway.


ALEX BANKS: What's neat is they work more like Auth0 or stripe. If I work on the accounts team, I have no clue who will be using my application. So I can't hard stuff into accounts assuming there's going to be a word association app. I don't know if there will be a word association app. If developers create a word association app like we have we want them to be able to incorporate accounts. So accounts is like a service that has a lot of clients but the clients are developers. They're websites, right? So we're going to have accounts for the color app and also have accounts for your application as well. Same thing with reviews.

JASON LENGSTORF: Is the community edition going to be okay? I haven't used mongo in a long time.

ALEX BANKS: I guess so. Or, shoot. I guess mongo lab is done, huh? We can't use a link to that.

JASON LENGSTORF: I'm not sure.

ALEX BANKS: Use the community edition. That should work. I think that's what I have installed.

JASON LENGSTORF: Okay. This is going way faster now. I think I have to turn this off, but by default home brew will update itself every time you run it. So if you wait a little while between running homebrew it downloads the whole internet before it runs the command you tried. So this should be running now.

ALEX BANKS: Brew services list. Let's see if it's running. You may have to start it.

JASON LENGSTORF: Mongo db community is stopped.

ALEX BANKS: Brew services start mongo db I think is the command or mongo db community. Okay. I always run a list again just to make sure.


ALEX BANKS: Is it running?

JASON LENGSTORF: It says I don't know. It says started.

ALEX BANKS: Cool. There it is. I didn't see that little green there. Let's start the account service then. So we have the account service, too. We can go ahead and load that. What's key is we are running on two different ports. These are two different instances. We're dealing with microservices. One service is dedicated to accounts and you can see there's a create account and an authorize and a me. Then the other service is dedicated to colors. Specialization of labor. One is running on 5,000 and the other is on 5003. I'm using the ports because 5000 are like the services we have in our organization. This is a really good note for security. We're going to orchestrate

JASON LENGSTORF: Uh oh. The review service is some kind of.

ALEX BANKS: I know the problem here. You need redis. They're different teams. They like different ways of doing data.

JASON LENGSTORF: So brew install redis. Oh, boy. My poor little "com pooper." Brew services. Start redis.

ALEX BANKS: List them and let's see.

JASON LENGSTORF: Redis and mongo are running
What are you doing, computer? Why? Why are you like this?

JASON LENGSTORF: My computer's got it on lock right now. We're good.

ALEX BANKS: Three services, right? 5000, 5001 and 5002. This is the hardest part about learning federation. You have different folders, things running on different ports. If it's the end of the day and you're banging away at requests to the wrong port or something like that, those types of mistakes happen. It's not like a real mistake. You're just not on the right thing. We have different services running. You have to keep that stuff in your head. Typically working under this architecture you and the team are working.

JASON LENGSTORF: Yes. So now each of these is running. We have free associations. This is the one we built.


JASON LENGSTORF: We have the users which is an empty table and this one is the reviews.


JASON LENGSTORF: We'll talk about the reviews.

ALEX BANKS: We have all the services. Your organization has services and it's time to expose the services to the world. What you need to do that is a gateway. So our Apollo gateway is an orchestration layer. From a security perspective all of the services on 5000, no one from the outside can hit those. The only thing publicly facing is the gateway. Everything else is internal. So long as the gateway can communicate with services, you're fine. Then you have added security. If you have all of your services exposed, you could end up with security issues. Especially because we have an account service and stuff like that here.


ALEX BANKS: Everything I have on five should be secured. So we create a gateway on port 4000.


ALEX BANKS: So go to the hue review gateway.

JASON LENGSTORF: Oh, gateway hue review. Got it.

ALEX BANKS: There's no databases or anything here. The gate way will orchestrate these services. If you run NPM start you have started another service. It's the gate way and that's on 4,000. This is all of the services orchestrated together. Puck get rid of those panels. That was the last thing you had running, I believe.


ALEX BANKS: Now I want to walk us through the process of adding a color and then talk about what's happening. We have all the other services set up. When you open schema and types everything is put together. It's grabbing the types from the underlying services and combining them. The query me comes from the account service. Total reviews comes from the review service, right? The colors comes from the color service. All of those things are now combined into one schema as if they are the monolith even though they live in their own separate locations. So that's really key to what's going on here.


ALEX BANKS: So we have the account functionality built into this hue review site. So I want you to run account mutation.

JASON LENGSTORF: Okay. Mutation, create account. It wants an input. My input is e mail

ALEX BANKS: It could be a fake one, yours or whatever.

JASON LENGSTORF: Need a name and I need a password.

ALEX BANKS: Something easy so we can log you in.

JASON LENGSTORF: I probably should not do okay.

ALEX BANKS: I always type "badpassword." You know it's bad. If you type password we don't know if it's bad or not.

JASON LENGSTORF: Okay. That gives me a token.

ALEX BANKS: You can get information about yourself back if you want, too. That's an object you have to select your name or whatever.

JASON LENGSTORF: All right. Let's get the created. I'm going to collapse this, run it.


JASON LENGSTORF: I have a user.

ALEX BANKS: Grab that token.


ALEX BANKS: Let's go ahead and open up a new tab. We'll add the token to our http headers.

JASON LENGSTORF: That's are down here.

ALEX BANKS: Yeah. You just create an authorization header.

JASON LENGSTORF: This is like a bearer kind of thing?

ALEX BANKS: Yeah, and the token. The account service, that's the idea. Create a token, log in so we can identify you. To test it we'll send a me query.

JASON LENGSTORF: There we go. If I take this out

ALEX BANKS: That's you. Let's go ahead and post a color now.

JASON LENGSTORF: Nothing. Oh, there. I took out the authorization to show that's what makes it work.

ALEX BANKS: Let's stay here for a second. In the bottom right hand corner of the screen you'll notice a query plan. Go ahead and open it up. Oh, shoot. It didn't work here. Can you hit play again? Sometimes the query plan doesn't work. Let's go back out to the first tab I'm sorry. I'm sorry to be moving so fast. My head is full of coffee. Oh, do this. No, do this. We are not going to worry about this. We'll get the query plan to show up on the next screen.


ALEX BANKS: Let's do another tab.


ALEX BANKS: Yeah. I want you to post a color. I think the mutation is called add color. There we go.

JASON LENGSTORF: Can I pick any is it a hex value?

ALEX BANKS: The title is the name of the color like rad red or pink or you know, whatever you want to call it.


ALEX BANKS: And a hex value.

JASON LENGSTORF: Do I include the hashtag?

ALEX BANKS: Yeah. Pound FF00. I think any web color will work.


ALEX BANKS: We're on the graph ql side. So we'll never see the colors.

JASON LENGSTORF: Okay. I created rad red.

ALEX BANKS: Let's create another one for the fun of it.

JASON LENGSTORF: RGB. So now we have red and purple.

ALEX BANKS: Let's open another tab and a colors query. Let's get the titles to start.


ALEX BANKS: There are the colors. Now let's see if the query plan works. Go ahead and open that panel. Oh, why doesn't the query plan work? I have seen this I see it happen sometimes. Leave that panel open and hit refresh for me. Then hit play. Is it doing something?

JASON LENGSTORF: I don't know. There it is.

ALEX BANKS: Yay. I don't know why sometimes you have to shock it to life. What's happening is it's showing you're asking for colors. But colors aren't hosted on this. This is the gatewaylayer. You're going to 4000. What the gateway does for colors is sends a fetch request to the colors service. That's the service we started that's running on 5000. Notice as you ask for all colors you see the title. Go ahead and ask for the value of the color. Then also go ahead and ask for posted by. So hit enter and do posted by. Or created by. That's the sub field. This is how we link to the account service. Instead of asking for name I want you to ask for e mail.


ALEX BANKS: Ask for the e mail right now. What happens when we work with federation is references to users are saved by one field, by an ID. That ID can be used in the other service to look up the full details for the user. If you notice when we send this and fetch we are only sending a fetch to colors. Only one fetch occurred because the color service saves the e mail address that you used when you added it. It actually saves that field. We have it in the service. Now go ahead and add your name and create it over there.


ALEX BANKS: Date created or whatever.


ALEX BANKS: Now look what's happening. If you look at the query plan you get all the information and it's coming from two services. One service has the information about the colors along with your e mail address for every color you added or unique identifier and the second service we have to hit has the information about the users. This query plan is telling you exactly what the gateway is doing. In order to do it, it must first make a request to get the colors. As it goes through and makes the colors request, it sees that you are asking for more information from another service.


ALEX BANKS: So in sequence, not in parallel. In sequence it has to make a request now for the other information you asked for from the user service.


ALEX BANKS: So we have your e mail and if you scroll down we are actually trying to get the name and create it from that service. So the query plan will tell you how the whole thing orchestrates together. But you need to know this as a developer of federation to a user who is using the API. It looks just like graph ql.


ALEX BANKS: It doesn't matter. You would think this is a monolith. Just time checking. We have about ten minutes left.


ALEX BANKS: Let's try to move fast here. I want you to try one other thing in case we can't. If we can't we still have the moon highway cloud people can start, play with and see if they have the thing. Let's go to the me query.


ALEX BANKS: Yeah. Under the me query you should be able to see your posted colors. If you hit enter and look for another field, now you can get the title of all the colors you posted. So now it's orchestrating from the other way. We are starting with a query about you from the user service and then we're seeing the information about all of the colors you posted from a completely separate service.

JASON LENGSTORF: That's super cool.

ALEX BANKS: Let's try this. Ten minutes on a hustle. Let me ask you and everybody. Do we want to try to add your service to this in ten minutes? Or do we want to look under the hood of these services and see how they work.

JASON LENGSTORF: Chat, do you want to build one or review one that's already built? They want to see under the hood.

ALEX BANKS: Build, build, build.

JASON LENGSTORF: It's a dead heat here. We are going to see under the hood if we build it.

ALEX BANKS: Yeah. If we build it you'll see it.


ALEX BANKS: Debugging, we probably can't, but let's give it a shot. Go to the service you have running now.

JASON LENGSTORF: Got it. Here. All right.

ALEX BANKS: So what you want to do is stop this service.

JASON LENGSTORF: So my service is at which 5000?

ALEX BANKS: This is the confusing stuff.

JASON LENGSTORF: Here's my service.

ALEX BANKS: Cool. Let's stop this and install @Apollo/federation.


ALEX BANKS: All right. What I want you to do now we're using Apollo Federation. We have that package. Go into your index.JS file to import it. So I want you to import destructure and we're going to pull this argument out called build federate it schema. Then require it from the Apollo Federation.


ALEX BANKS: All right. Sweet. Let's go ahead and go down to where we start the server. Down in here so instead of what you are going to do for type defs and resolvers here, right where they are go ahead and add a schema colon. And invoke build federated schema. That's a function.

JASON LENGSTORF: Do I pass the type defs and resolvers into it?

ALEX BANKS: We want an array, so yeah. Hit enter and add an object. Then the object resolvers and type defs.


ALEX BANKS: There you go.


ALEX BANKS: Now on our server yeah. That should work. Schema equals so I think that should work. I don't think I'm missing anything. I want you to try and start it.


ALEX BANKS: See if it starts. What does it say?

JASON LENGSTORF: Cannot read property kind of undefined. Oh, wait. I think I might have had that extra stuff in here that we didn't

ALEX BANKS: Yeah. That's what it is probably, yeah.

JASON LENGSTORF: All right. Try it again. No. What don't you like?

ALEX BANKS: Oh, man. This is what I was worried about.

JASON LENGSTORF: Known directives.

ALEX BANKS: We don't have any directives though. Hmm. Let me look at something real quick. That's good.

JASON LENGSTORF: I didn't add a user or anything, did I?

ALEX BANKS: I don't see that anywhere. Free association. We don't have comments or anything. Just for the fun of it to amuse me because sometimes federation is funny with stuff, get rid of the comma between word and association. It should work, but just we'll go over there. Let me check something else real quick. Oh, we have to move fast.


ALEX BANKS: Let's see if they change the syntax real quick. Okay. So what we are trying to do here is sprinkle all of that good federation stuff on top of our schema.


ALEX BANKS: So basically those are supposed to be the two lines of code that we are supposed to add. But obviously we have something missing. I just want to check one thing and then I'll move over to showing how that works.

JASON LENGSTORF: Got an issue link here. Cannot read property "kind" of undefined.

ALEX BANKS: I'm worried they changed the way they did it. No, that looks good. That's what we've got.

JASON LENGSTORF: That's all right. Oh, we have to use the GQL thing.


JASON LENGSTORF: We can do that really fast.

ALEX BANKS: Go ahead and add that. Surround your type defs with GQL. You could probably do it. That works right there. And then whatever your type defs are.

JASON LENGSTORF: We're going to do this fast, get this out of there and now it's going to just work, I believe.

JASON LENGSTORF: Come on. Let's do it.

ALEX BANKS: Look at it go.

JASON LENGSTORF: Open it up real quick. So 4003. If we look at the docs we can see, service.

ALEX BANKS: We got it. That's all you have to do. If you want to use federation if your service goes behind the gateway you have to set up a federated service. It doesn't support subscriptions. There is a workaround but we don't have time. Let's build a gateway real quick. Start a new project really quickly.


ALEX BANKS: You're going to install the graph ql I'll wait until you get to the screen. Call it gateway or whatever.

JASON LENGSTORF: Gateway, yeah.

ALEX BANKS: Install graph ql. Apollo server.

JASON LENGSTORF: Anything else?

ALEX BANKS: @Apollo/gateway.


ALEX BANKS: And then let's go ahead and in your gateway create an index JS like everything else and let's open that index.js.


ALEX BANKS: All right. Then what you want to do is create an instance of the Apollo server. So const and destructure Apollo server.

JASON LENGSTORF: Oh, boy. I can do it. It's happening.

ALEX BANKS: Apollo gateway also destructure. And remote graph ql data source.


ALEX BANKS: Is there a capital R in remote?


ALEX BANKS: Let's capital that. QL is capital and D.

JASON LENGSTORF: And the source?

ALEX BANKS: That's from Apollo gateway. All right. Also a quick side note. If we didn't want to build this Apollo has managed gateways. You can go to the Apollo manager and create a gateway without having to write code. Now create a variable called gateway. New Apollo gateway. We'll use that Apollo instance to do it.


ALEX BANKS: The first is service list. That's an array where we list our services.


ALEX BANKS: Object. The first object will be the name, our free association service. That's a string and you can call it whatever you want. And then the URL. So whatever local host port that one is running on.


ALEX BANKS: Then the next object is the user service, right? We're trying to put the user service now together with the

JASON LENGSTORF: That one was at let's see.

ALEX BANKS: I think it's 5,000? What is it.


ALEX BANKS: Yes. 5000.


ALEX BANKS: So that's our organizations user service. We never have to do that again just by incorporating once it's run. So now run the server. We have the gateway. We need an asynchronous start functions I like to create.

JASON LENGSTORF: So our server is new Apollo

ALEX BANKS: New Apollo server. This time in the object you send the gateway. So send the new Apollo server your gateway and usually set subscriptions to false. Gateway comma subscriptions false. And that's it. Subscriptions false. And go ahead and server.listen.


ALEX BANKS: That's already running. Let's do 400 3.

JASON LENGSTORF: We have 4003. Let's do 4004.

ALEX BANKS: Okay. We don't need to worry about the URL this time for speed.

JASON LENGSTORF: Okay. Then we'll call it.

ALEX BANKS: And run this.

JASON LENGSTORF: Async function start. Okay. I believe this is going to work on the first try. Running.

ALEX BANKS: Yes! Go to the gateway.

JASON LENGSTORF: 4004. Get all the free associations.

ALEX BANKS: Just combine them. That's the step that I thought we could get to in this. If you want to keep going I'm glad to.

JASON LENGSTORF: Look at it go though.

ALEX BANKS: You just combined them. You can query your free associations here, too. So the next step really would be to combine the user is when you make a post we know you have made a post. But I know we don't have time for that. I have resources for how to do it though.

JASON LENGSTORF: Yes. We'll add those in the show notes. And we'll make sure so go check out on learn with the episode with Alex will be posted. You'll be able to see all the show notes here once the episode goes live. It will be cross posted tomorrow and also in the replay notes on Twitch for as long as the replay is available there. Alex, where else should people go if they want to follow you online?

ALEX BANKS: I just put in the chat a link to an egghead collection I have on federation. That actually shows us what the next step is. I would be impressed if you were following along and built your own free association server. The information you need to take the next step is here. The videos are short. But we talked a lot, didn't we? You saw how fast we got it going once we wrote the code. There's so much conceptually. I'm MoonTahoe on Twitter. Not a lot of people know that because Alex Banks was taken. I'm MoonTahoe on things. If you're playing switch and you see MoonTahoe, that's me.

JASON LENGSTORF: Unfortunately, that's all the time we have. I feel I could go on this all day. It's so much fun. Alex, thanks for coming on. Everybody follow Alex on Twitter and everywhere else. Make sure you check out Alex and Eve's work. It's really best in class. With that we'll do one more quick shout out to the sponsors. Netlify, SANITY, Auth0 and Fauna for having White Coat Captioning do the live captioning for us. Check out our schedule because we have a lot of fun stuff coming up. It will be a whole lot of fun. Lots of things to learn. You can add it to your calendar so you get notified. Alex, thank you so much. Chat, thanks for hanging out. Stay tuned, we're going to raid. See you next time.

ALEX BANKS: See you.

Closed captioning and more are made possible by our sponsors: