Zero-to-Federation in 60 Seconds: How a GraphQL Middleware Replaced 500+ Legac… | apidays India 2026

Good afternoon everyone. Today I'm going to talk about a transformation that we made through the graphical middleware. So I will be talking about like how a graphical middleware has replaced a 500 plus legacy APIs and we have saved a time of 3 year that we are going to be investing on a migration part. So the story is I can summarize from that zero to federation in 60 seconds. That's the way I am calling my talk like that. So myself Rajin uh I'm working with Red Hat as a principal software engineer. So let's uh see what is the problem that we are addressing here. So this is a legacy landscape what we are owning till what we are owning 3 months before. So people who worked with the Salesforce know that like Salesforce has a lot of rest APIs and uh it is every time we customize our own APIs according to the business requirements and we are maintaining maintaining a legacy number of Salesforce APIs. In our case we have a legacy system we used to cater around 500 plus APIs and uh that was built by the effort of the 100 plus developers. So that was a quite effort and we invested around 3 years at that time around 10 years before uh to build this big ecosystem and at the end of the day everything everything is talking towards say one single eos data source which is a salesforce. So whenever any Salesforce object is being changed every time we have to make the changes in the rest API manually maybe any subject matter expert can do this one because that Salesforce will make a change everything is uh broken in our side. So we have to re-engineer that effort and that was going forward. So when it comes to the AI when it comes to the modern modernization we thought of like okay Salesforce has a graphql endpoint and why don't we leverage the graphical endpoint which has a power for the dynamic APIs which has a power for the dynamic change management let's leverage that that was our p that was our vision towards it because we don't need to manage anything in the graph it's a self-managed way uh only thing is you have to define your data accordingly so and in this case sales source is a product and it can it has its own interface for that. So uh when we are evaluating the graphical we encountered four blockers here when we want to adopt the sales force. First one is the introspection is broken. When I say introspection is broken. So whenever an red hat admin or any other admins is adopting the Salesforce towards their own premises they cater the APIs but there may not be the SMMES on that how to tune their own graphical APIs here so that our own introspection was broken there. Second thing is like uh no federation directives. We do have a red graphical ecosystem. So where we can connecting our own subgraphs uh towards a single super graph and we'll be quering from the super graph towards it. Our goal was to connect that towards it. But that is a federated ecosystem. What the Salesforce graphical is providing is a non-federated ecosystem. So that was a bigger challenge to convert it to there. Third thing is about the incompatible authentication. Every enterprises or every companies have their own authentication standards. For example, they have their own JWT. They have their own basic. In our case, we uses the JWT here. But in the Salesforce, they are very much tight. They are not flexible here. So what they expect is that their own authentication mechanism over there because they they have their own authentication mechanism over there. So that they are expecting their own tokens to be authenticated against the Salesforce user. Our red support or red sales is highly dependent on the Salesforce here and every time we have to map it, it is very difficult things over here. And fourth thing for part is type name collisions. In the type name collisions for example uh if you worked on the schema stitching or basic thing you can see that one common type can be found in multiple places. So in the salesforce there are type names are very much generic. For example if you take an example of a case is a type which can come from another subgraph. How to namespace the things here? So this is a quite a difficult challenge at initially we thought it's a quite unusable piece of thing like even the salesforce as a graphical how to integrate the super graph. So these were the blockers we identified here. But despite of this blockers, we built a system over here. So I will take you through the workflow like how we have resolved this issue. Like let's think about from a client perspective. For example, you are talking towards our own super graph and you want to get your own Salesforce data from the instance. So Apollo router basically our super graph lives there. Uh so in the Apollo router what we do is we implemented a middleware I told before right in the middleware whenever a request is coming towards Apollo router it will make sure the request is from a legitimate source it will by it will pass the request towards the middleware what the middleware does is like that's a good part here middleware handles the authentication for example I told before like every enterprises has its own authentication way let's say uh rad uses the key clock based authentication for all our systems and the sfdc Salesforce has its own token in our middleware what it tried to transform is like the incoming request it will be translated to a sfdc token for example uh if Michael is logging to the portal okay we see that okay uh he's a federated user for the salesforce we'll be behalf of him we'll be obtaining a token and we'll be modifying that original request with the Salesforce token. Second thing that middleware does is the query rewriting. So uh it will rewrite the query for example like it is taking the uh query which is in the super graph maybe which is not a standard type of the uh which is defined in the salesforce. It is taking this query from the super graph and customize it is according to the Salesforce it needed and it makes a request towards the Salesforce API which has a native graphql over there in the so that same request will be processed with the uh data if it is a user is a if the user has a right permissions for the certain object the request will be processed and request will be transformed by appending the correct data types over there and returning it to the client. And that's how the basic functionality here is working. So let's go to the each and every phases here. So our first as I told that our first first blocker was this broken introspection. Yeah. So what we do is like we take the Salesforce upstream GraphQL schema and we yeah and we inject the federation directives and the cleaning the invalid data and applying the name space directive for example if the Salesforce is telling like their data type is UI API and we'll be adding an prefix towards it Salesforce support and we'll be adding that and pushing towards the super graph. That's how we so super graph doesn't know the original Salesforce schema. The middleware is trans transforming this one. So uh we make the we make the schema like this and push towards the super graph by the middleware. This checks will be has configured in every 1 hour 2 hours so that new changes will be promoted to the systems uh very fastly here. So when also we inject the federation types also here because our superraph is federation compatible. So we want to make that non-federated schema to be a part uh to non-federated schema to be a federation supported one. So we make the schema to be a federated one by injecting the federation headers to the uh fetched schema from the middleware and also apply the middleares for we follow the certain standards like how the fields types and units are defined. So we apply that customization over here and do it. So the query rewriting is the other part I was talking the query rewriting. So in the query rewriting so graphql has a powerful thing called as aliases. So in the graphql you can define the type like how we need. For example you are fetching the list of books and if you want to uh if you want to name a books to something like a paper something like any any field you want field name that you want to include you can put that field name over here and get it. So what the what our super graph from a user is sending a query like this. What the middleware does is like it will be transforming the query like the aliases like this graphical aliases and we'll sending it to the Salesforce with the token with the token which is transformed by the Salesforce. So uh through that we'll be sending towards the Salesforce and Salesforce doesn't know that okay this is a schema good part over here is like since the alias's power is like like we are defining it like we don't need a postprocessing to transform the data back so if I'm sending it like this the case is returning data is like this so that I don't need to I don't need to uh I don't need to change the processing way of like okay I my schema uh my original data is like case I don't need to put it like the Salesforce case is automatically done by the GraphQL by by the standards and specs. So that's a power of here and other thing is the bridging of SSO here. So in our case a user is logging with the red SSO token and our middleware it validates the JWT it's a it's a right token and we give the same JWT token towards our O handler. So o handle will be doing the federated identity check with the Salesforce and coming with the Salesforce token and we'll be forwarding that same request to the Salesforce here. So user doesn't see that like for example like what is your real Salesforce identity it is masked with it is it is covered up with the red standards like whatever the standards that we are defining in our own middleware it is covered up with that also like it is able to do the federated identity checks for every each and every users and uh uh and it is fully comp fully compliant according to the standards here. So no user for a programming programmatic things will not be directly talking towards the salesforce directly instead of that they'll be coming through the super graph so that uh so that will be complying our needs after doing all of this the 500 APIs like there we used to manage it we have decommissioned it today so uh the 500 APS is not there it will be only with the one single middleware and we built that old service took a 3 years with the help of 100 developers at that moment of time. Now we built this middleware in very much uh short period of time and in the in when it when you build an API you hardcode your own types how you need to transform your types and all we are not hard coding at all instead of that we are defining a programmatic support over there okay how that transformation should be happening so this transformation is uh defined in over there and another thing is the coverage part we are giving the coverage on the entire Salesforce instance for the end user for example like if the user of course the user is permitted over there so based on the user permissions that you can see the entire Salesforce graph Salesforce API schemas in a graphql view so they can define compose their own APIs graphql is good for the developer experience part here right so uh so the people can find their own APIs people can find uh their build their own APIs without another developer help so they can do that So also one more thing is like if you want to make say say if you want to say that like okay Salesforce is releasing something new today a new object what we do here is like the middleware fetches that schema in every 1 hour and we doing the checks over there if you push towards the super graph will get will that going to be something to be broken so this is all being possible with Apollo uh Apollo enablement so we'll be checking with our own Apollo graph operating system and uh getting the things done over there. So it uh it checks over there and uh if the schema is qualified then it'll be promoting to the super graph. So uh so that the resourcing also has been reduced a lot and the dependencies also reduced a lot and we make sure that always the stable changes are automatically being promoted to the production because of this automation. uh this is an example for any other legacy systems like for example like if they want to move towards the graphql uh this I so the salesforce offer example tomorrow let's say you have a legacy graphql API or you have an incompatible graphical API you want to merge towards the federation this is also another path or approach that you can follow for that so key takeaways of the session is like every time you don't need to rewrite the APIs for example like it's automatically managed if a developer wants that let the developer defend what they wants. So if some breaking change is always happening so it is automatically handled in the schema check. So we have this orchestration platform over there which is called as Apollo graph operating system. Through that we'll be able to do the things over here and uh [clears throat] aliases aliases is not aliases is an underrated thing in my perspective because aliases using aliases can be very much powerful on transforming the data. uh be because that really solved our problem graphical aliases because you can define the way how you want to this type name collision issues these these things can be avoided in the graphql because of the aliases because super we are telling the super graph that okay you uh instead of the account name it is Salesforce account name we are just adding the abbreviations over there and the aliases can be able to process that data accordingly also the o bridging that's another important there part. So the o bridging is something that we can take a help of the our own organization standards and saying that okay you translate the o token uh because of the federation federated identity federated identity is something like it's a mapping like if the the person should have a account in the salesforce as well as in the uh red system that they map their own ids so that the so that the respective tokens can be get issued over there. Yeah, that's quite about this. Yeah. Any questions? [snorts] >> Yeah. I couldn't hear >> this about aliases and if any personalization happened >> okay >> in some of the APIs for interfacing so are there any uh suggested uh I mean the way you can roll back and revalidate or anything so that kind of mechanism If something goes wrong >> particularly aliasis and some personalization happens. >> Yes, there is a way to do that. So in our orchestration platforms I told about the power of the graph operating systems and all right. If this check is not failing, if the checks are not passing, it will not go to the production. So it will be rolling back to the older schema. That's how we have architected it. >> Check should be defined before >> it it is it's already defined in our pipelines. So we have defined some kind of a chron jobs in the system like never ever you fetch the schema from the graphql you verify that against the super graph and uh okay then tell that if something is breaking over there let us know if something is breaking don't promote that production the process is supported there and it will also make sure our our own downstream API which is the salesforce team that okay if you're making something like this this is something which is breaking so they can also stop that effort so that's how we have a coordination there but in majority in a 95 percentage cases this is not happening because like uh everything is passing in a things going in a good manner here. Thank y uh any more questions? >> Yep. >> Could you talk a little bit about versioning your APIs? How does that work? >> So about the specific Salesforce thing or the graphical versioning? >> Okay. So in the Salesforce like technically this is a middleware what we are using here. Whatever our downstream API is versioning it is directly pushed towards it. Our admins is handling the versioning under the hood. This is just a middleware in the sense of the graphql here. Uh yeah so originally this version controls are being handled by the our own Salesforce admin. For example let's say Salesforce uh today's version is maybe 17. If the admin is defining that 17 should be their own uh upstream version. They said that okay 17th is my API version and that will be rolled out towards the middleware. So and that will be checked against the existing clients or if something is breaking we go to the Apollo and override the things. So that's how the checks has been working over here.