Enterprise Operations
Web Manager
A configuration-driven operations console where permissions define menus, routes, and forms.
Senior Frontend Developer at Bank Saqu · August 2024 - Present
6
Roles
15+
Menus
12+
Routes
7
Operational Domains
The Problem
The operations platform covered multiple business domains and user roles. Building separate menus, routes, and forms for every role would create duplicated UI and authorization logic as the platform expanded.
My Role
Sole frontend engineer responsible for the application's frontend architecture, UI system, permission-driven navigation, dynamic form generation, API integration layer (REST and GraphQL), session handling, and automated end-to-end testing.
Architecture
The Web Manager frontend uses permission configuration as the central source for navigation and UI behavior, while a shared API client and session layer connect the application to multiple backend services.
Operations Users
Internal users accessing features according to their assigned roles and permissions.
Next.js Console
Main application UI built with Next.js, Zustand, Radix UI, and Tailwind CSS.
Permission Configuration
Defines roles, menus, routes, and granular actions used to determine accessible UI behavior.
Dynamic Form Generator
Generates forms from configuration rather than creating separate implementations for each role or integration.
Session Layer
Next.js middleware and NextAuth/JWT with Redis-backed session validation.
Centralized API Client
Communicates with 5+ backend services via REST and GraphQL, and normalizes response/error contracts.
Backend Services
Engineering Decisions
Configuration-driven UI
Moved menu, route, and form behavior into configuration so the frontend could adapt to roles and permissions without duplicating screens.
Permission-driven navigation
Used role and action permissions to control navigation and available UI actions.
Shared API client
Centralized communication with backend services so response and error handling could be normalized.
Server-backed session validation
Used Redis-backed session validation so session revocation could be detected independently of client-side token state.
What I Built
- Owned the frontend architecture and implementation across 7 operational domains.
- Built a configuration-driven permission system covering 6 roles, 15+ menus, and 12+ routes.
- Implemented granular action permissions including view, create, update, delete, export, upload, and approve.
- Built the dynamic form generator using the same permission and configuration model.
- Built the shared API client (REST and GraphQL) for communication with 5+ backend services.
- Implemented centralized response and error normalization including RFC 7807 problem details.
- Implemented Redis-backed session validation using Next.js middleware and NextAuth/JWT.
- Validated releases using automated Playwright end-to-end tests.
Constraints
- The application handled sensitive operational processes, so access control and session security were important.
- Backend services exposed different response and error contracts.
- The UI needed to support multiple roles without creating separate implementations for each role.
Outcome
One console covers all 7 operational domains, generating 15+ menus and 12+ routes across 6 roles from a permission config instead of a hand-built screen each, with sessions that terminate immediately on revocation and per-feature error-handling code reduced by the shared API client.
Technology
Engineering Highlights