DEV Community

Cover image for Building an Enterprise Dashboard : 3 Architecture Lessons That Clicked
Vivek Vohra
Vivek Vohra

Posted on

Building an Enterprise Dashboard : 3 Architecture Lessons That Clicked

#typescript #redux #react #webdev

I’ve been learning React recently,and I build something that pushed me to learn a lot - an enterprise-style dashboard.

It had the stuff dashboards usually have:

  • big data tables
  • filters that actually matter
  • layouts with sidebars
  • routes that should be locked down based on role

And that’s when I realized something:

the way we write React in beginner tutorials doesn’t scale cleanly to dashboards.

Here are 3 architecture lessons I learned while building it.

1) I stopped doing “fetch inside useEffect” everywhere (RTK Query made it clean)

At the start, my instinct was the usual:

  • put fetch() inside useEffect
  • manage isLoading, isError
  • store data in local state
  • repeat the same pattern in multiple components

That works fine… until you add filters.

In my “Quality Checks” table, the user could switch tabs and apply filters, and the data needed to refresh smoothly. Doing this manually started getting messy fast - lots of repeated code and state handling.

So I switched to RTK Query.

What I liked most as a beginner was:

I didn’t have to manually manage loading + caching logic everywhere.

The shift

Instead of writing fetch logic inside the component, I created a centralized API slice:

// features/api/apiSlice.ts
export const apiSlice = createApi({
  reducerPath: "api",
  baseQuery: fetchBaseQuery({ baseUrl: "http://localhost:3001" }),
  tagTypes: ["QualityCheck"],
  endpoints: (builder) => ({
    getQualityChecks: builder.query({
      query: (filters) => `/qualityChecks?status=${filters.status}`,
      providesTags: ["QualityCheck"],
    }),
  }),
});
Enter fullscreen mode Exit fullscreen mode

Then in the component, it becomes super simple:

const { data: records = [], isLoading } =
  useGetQualityChecksQuery({ status: activeTab });
Enter fullscreen mode Exit fullscreen mode

Now when activeTab changes, the request updates automatically.

No useEffect dependency confusion.

No duplicated loading state logic.

It just… behaves like a dashboard should.

2) Dashboards are a “layout game” (I learned the Three‑Pane UI pattern)

Most beginner projects are simple pages that scroll normally.

Dashboards are different.

In enterprise UIs, navigation should stay visible while the data area scrolls. So I built a three‑pane layout:

  • Primary sidebar (modules)
  • Secondary sidebar (sub-navigation)
  • Main content (filters + table)

The layout trick that finally made it work

The biggest lesson was keeping layout styling separate from component styling.

The layout needed to:

  • lock the overall screen height (100vh)
  • stop the browser from scrolling the entire page
  • allow scrolling only inside the table/content section

So the root layout uses something like:

  • display: flex
  • height: 100vh
  • overflow: hidden

…and only the content area gets:

  • overflow-y: auto

Once I did that, the UI suddenly felt like a real tool instead of a normal webpage.

3) I learned route security is not just “hide the menu” (RBAC needs structure)

This was a big one.

In a real dashboard:

  • Admins might access configuration screens
  • Operators might only access production/quality screens
  • Some routes should be completely blocked based on role

At first, it’s tempting to do random checks like:

{user.role === "admin" && <AdminMenuItem />}
Enter fullscreen mode Exit fullscreen mode

But the problem is:

  • it spreads role logic everywhere
  • you can easily forget a screen
  • someone can still type the URL directly if routes aren’t protected

So instead, I made one place where permissions are defined (a route/menu config), and protected routes using a wrapper.

const ProtectedRoute = ({ element, allowedRoles }) => {
  const user = useSelector(selectCurrentUser);

  if (!user) return <Navigate to="/login" />;
  if (!allowedRoles.includes(user.role)) return <Navigate to="/unauthorized" />;

  return element;
};
Enter fullscreen mode Exit fullscreen mode

This made the app feel safer and cleaner.

Also, it’s easier to scale:

If a new role comes later (like “Manager”), you don’t rewrite the whole app - you update the config + allowed roles.

The takeaway (from a beginner’s perspective)

Building this dashboard taught me that React isn’t only about components.

At dashboard level, you start thinking about:

  • data fetching patterns
  • layout structure
  • role-based access
  • and writing code that won’t collapse when features grow

If you’re early in React learning like me, try building a dashboard with mock data (seriously, json-server helps a lot). A dashboard forces you to learn the “real stuff” naturally.

Top comments (0)