How to Handle GraphQL with React Query: Adding Security Headers

Joel Marinho — Thu, 13 Nov 2025 05:23:22 +0000

Hey there! Welcome back! Hopefully, you’ve had a chance to read my previous article on handling GraphQL with React Query. If not, don’t worry! Here’s the link to catch up (https://medium.com/@joeldeveloper2011140/how-to-integrate-react-query-with-graphql-for-efficient-caching-part-2-529744130836).

But wait, I realized I missed something important in that post. In real-world projects, security is everything. Whenever we interact with an API, we often need to provide authentication tokens or API keys in the headers, or maybe even add custom headers for specific actions. 😅

So, to make sure you’re covered, here's how you can integrate security headers with graphql-request and react-query if you’re following along from the article:

Adding Headers with graphql-request and React Query

If you’ve already read my previous article, this will feel like a quick refresher. If not, no worries, let’s dive right in!

First, let’s use the graphql-request library with react-query and inject headers such as an API key. Here’s a sample implementation for your useApiGetUsers hook:

`import request from "graphql-request";
import { useQuery } from "@tanstack/react-query";
import { GRAPHQL_API_URL } from "../../../constants";
import { GetUserSchema } from "./users.schema";

interface IUseApiGetUsersParams {
search: string;
}

interface IUseApiGetUserResponse {
User: {
about: string;
name: string;
id: number;
avatar: {
large: string;
};
siteUrl: string;
};
}

export const useApiGetUsers = (searchItem: string = "") => {
const { data: user, isLoading: isGettingUser } = useQuery({
queryKey: ["user", searchItem],
queryFn: async () => {
const response = await request<
IUseApiGetUserResponse,
IUseApiGetUsersParams
>(
GRAPHQL_API_URL,
GetUserSchema,
{ search: searchItem },
{ "api-key": "bla bla bla bla" } // Here's the key!
);
return response?.User;
},
});

return {
user,
isGettingUser,
};
}; `

Now, you can send custom headers (like your api-key) to your GraphQL API when making requests. Boom—just like that, you've added security to your GraphQL calls. 🚀

Reduce Duplication with a GraphQL Client

Now, let's talk about reducing code duplication. If you’re working on a larger project, you might want to create a GraphQL client that you can reuse across your app. This will prevent you from having to manually add headers every time you make a request.

I could have gone the extra mile and created a reusable GraphQLClient in this demo, but I kept it simple for now. But hey, if you want to keep your code neat and DRY (Don’t Repeat Yourself, folks), here’s how you can set up a GraphQL client:

`
import { GraphQLClient } from "graphql-request";

const graphQlClient = new GraphQLClient(GRAPHQL_API_URL, {
headers: {
"api-key": "bla bla bla", // Put your API key here
},
});
`
Now, instead of adding headers manually to each graphql-request, you can reuse the graphQlClient throughout your project. Just call it wherever you need a request, and boom, no more repeating code! 🙌

Wrapping It Up

Alright, folks, that’s all for today! You've learned how to:

Add custom headers like api-key to your GraphQL requests.
Keep things DRY by using a reusable GraphQLClient.

Before I sign off, I want to leave you with a quick tip: Always check out the GraphQLClient itself for more options and parameters—it’s like the Swiss Army knife of GraphQL requests! 🔪✨

Thanks for reading, and happy coding! Now go and make your GraphQL queries secure and efficient—because who needs security flaws in their app, right? 😜

That’s all folks! 🎉

🚀 Exploring Microfrontends with Webpack Module Federation

Joel Marinho — Thu, 13 Nov 2025 05:17:50 +0000

Recently, I built a small project using Webpack Module Federation — a host app dynamically loading a remote React component (profile) — to better understand how microfrontends actually work in practice.

🧩 What Are Microfrontends?

Microfrontends bring the microservices mindset to the frontend.
Each part of the UI is an independent application — owned by separate teams, deployed separately, and composed into one seamless experience.

This architecture enables scalability, autonomy, and faster releases, especially in large organizations.

⚙️ Common Approaches

Module Federation (Webpack 5+)
→ Dynamically loads remote modules at runtime, sharing dependencies like React — no rebuilds or iframes.

Multi-Zone Architecture (Next.js)
→ Multiple Next.js apps stitched together through routing, ideal for domain-based segmentation.

Internal NPM Packages
→ Each microfrontend is versioned and shared as a private package — great control, but tighter coupling.

Iframes (the classic)
→ Offers full isolation and security, though with limited inter-app communication and styling flexibility.

🧠 How Remotes Work

A remote app exposes modules like this (for example the profile):

new ModuleFederationPlugin({
name: "profile",
filename: "remoteEntry.js",
exposes: { "./Profile": "./src/Profile.tsx" },
});

And the host dynamically loads it:

new ModuleFederationPlugin({
name: "container",
remotes: {
profile: "profile@http://localhost:3001/remoteEntry.js",
},
})
const Profile = React.lazy(() => import("profile/Profile"));

Webpack fetches remoteEntry.js, shares the React instance, and mounts the component — all at runtime.

⚖️ Trade-Offs to Consider

Deployment orchestration: independent deploys give flexibility, but require careful version control and CI/CD coordination.

Shared session state: managing auth and context across apps often needs shared cookies, tokens, or an API gateway.

Performance: multiple bundles add overhead — smart caching and lazy loading help keep things fast.

Consistency: design systems and routing conventions must be aligned across teams to avoid fragmentation.

Microfrontends aren’t a silver bullet — but they’re powerful when autonomy, scale, and parallel development matter.

If you’d like to see it in action, here’s the repos :
🔗 Host (Container): https://github.com/joel2011140/mfe-container
🔗 Remote (Profile): https://github.com/joel2011140/mfe-profile

I’d love your feedback — how are you handling deployment, communication, or shared state in your microfrontend setups?