DEV Community: shriramcs

How I Stopped Hardcoding Permissions in My Frontend

shriramcs — Wed, 22 Jul 2026 12:17:23 +0000

Most apps start their access control with something like this:

function canEditReportsSummary(role) {
  return ['EDITOR', 'ADMIN'].includes(role);
}

It works, right up until you have a dozen pages, each with a few sections, each
needing independent read/write rules per role. Now you've got dozens of these
little arrays scattered across the codebase, and adding a new role means hunting
down every single one and hoping you didn't miss any.
0
There's a much simpler model that scales cleanly: a three-level permission
tree — page → section → { r, w } - plus one generic function that walks it.
No new library, no framework lock-in, just a data structure and ~5 lines of code.

The shape of the data

Instead of scattering role checks in code, define one permission tree per
role. Three levels deep:

Page — the top-level feature/route (dashboard, reports, settings)
Section — a sub-area within that page (overview, summary, billing)
Action — r (read) or w (write)

{
  "dashboard": {
    "overview":  { "r": true,  "w": false },
    "analytics": { "r": true,  "w": false }
  },
  "reports": {
    "summary": { "r": true,  "w": false },
    "export":  { "r": false, "w": false }
  },
  "settings": {
    "general": { "r": true,  "w": false },
    "billing": { "r": false, "w": false }
  }
}

This one blob fully describes what a single role can see and do. Give each role
its own tree, e.g. for three common roles:

Page	Section	Viewer	Editor	Admin
dashboard	overview	r	r, w	r, w
dashboard	analytics	r	r	r, w
reports	summary	r	r, w	r, w
reports	export	–	r	r, w
settings	general	r	r	r, w
settings	billing	–	–	r, w

Notice how this reads almost like a spreadsheet a product owner could fill in —
that's the point. It's declarative data, not scattered if statements, so
non-engineers can review it and engineers don't have to guess what a role does.

The generic access-check function

Once permissions are just nested objects, checking access is one small,
reusable, framework-agnostic function:

function checkAccess(permissionTree, [page, section, action]) {
  if (!permissionTree) return false;

  const pageNode = permissionTree[page];
  if (!pageNode) return false;

  const sectionNode = pageNode[section];
  if (!sectionNode) return false;

  return sectionNode[action] === true;
}

Usage:

checkAccess(currentUser.permissions, ['reports', 'export', 'w']); // false for Viewer/Editor... true for Admin
checkAccess(currentUser.permissions, ['dashboard', 'overview', 'r']); // true for all three roles above

This works identically whether permissionTree comes from Vuex/Redux/Zustand
state, a React context, or is just passed around as a plain object — it has zero
framework dependencies. It's also fail-closed by design: any missing page,
missing section, or typo in the path returns false rather than throwing or
accidentally granting access.

Wiring it into your UI

Wrap the raw function in named, intention-revealing helpers rather than calling
checkAccess([...]) inline everywhere — this keeps each resource path in exactly
one place:

const canViewReportsExport = () => checkAccess(user.permissions, ['reports', 'export', 'r']);
const canEditReportsExport = () => checkAccess(user.permissions, ['reports', 'export', 'w']);

Then use them wherever you'd normally reach for a role check:

Navigation — hide a page link entirely if no section within it is readable.
Route guards — redirect away from a page if canView...() is false.
Buttons/forms — disable or hide "Save"/"Edit" controls based on the w check.

Adding a brand-new page later (say, "Audits") is the same three steps every time:
add an audits branch to each role's tree, write canViewAudits/canEditAudits
helpers, wire them into the UI. No new pattern to invent, no scattered role list
to update.

Don't forget the backend

This pattern is just as useful server-side — attach the same permission tree to
the authenticated user/session, and re-run checkAccess before any write
operation. The frontend checks are for UX only (hiding buttons a user
shouldn't see); the real security boundary is the server independently checking
the same tree before mutating anything. Keep both sides reading the exact same
shape so they never drift out of sync.

When this isn't enough anymore

This lightweight pattern is great for typical CRUD-style apps with a handful of
roles and a moderate number of pages/sections. Consider a dedicated
authorization library (like CASL, Casbin, or a policy engine like OPA) once you
need things this simple tree can't express cleanly:

Duplicate entries in DB layer — Each role will have json structure repeated for all page/section, any new page addition involves changes in all roles
Conditional/attribute-based rules — editors can edit only records they
created," not just "editors can edit this section.
Explicit deny-overrides-allow precedence — right now everything is
additive; there's no way to say "deny this specific case even though the
section is generally writable."
Large role/permission matrices — if you're maintaining hundreds of
page/section combinations across dozens of roles, dedicated tooling with
testing helpers becomes worth the added dependency.

Until you hit one of those walls, though: three levels, one tree per role, one
small walker function. That's it.

How do you deal with stress

shriramcs — Thu, 10 Oct 2024 09:07:33 +0000

"How do you deal with stress" at work?

This was the question asked to me in a recent interview. I look at them as honestly as possible to introspect myself and answer. I don't shy away from thinking out loud. Interviews are a very beautiful experiences to introspect on yourself about your technical understanding, project development and other soft skills.

Here is how I answered.

We feel stressed when there is a deadline for a delivery. It is with the individual to handle the stress, in my case, I look at it as another time period I should be able to finish my work. I consider it as seriously as possible, yet, I work in my own pace, making a constant progress at the task in hand.
Important things to note in a stressful environment is or in other words, how not to feel stressed is, to focus only on one thing which is of most important and keep other things aside.

A generic work involves complete attention no matter what is the deadline for delivery. we do have daily stand ups and to report the progress, the hurdles on the way for the manager to handle the needle for deadline.

A good manager, sets a practical dead line and allows team to work on their own pace and team members are not supposed to deviate from that. Also, a good manager absorbs the progress and sets internal target for himself to have a clear communication with their higher management.

To refocus on the stress part, I feel it is with individual to look at what is causing the stress in them. A fear of not completing the work, A fear of getting a bug out of their deliveries. We live in the future and that causes stress.

The Best way to handle this is to look at the complexity of the task, try to create milestones and see if you are getting their as expected or else, report it to team about the progress.

I'm sure I spent most of my time explaining this to my interviewer, I enjoyed introspecting myself in a situation about how would I really do it.

Two questions for you.

How do you handle stress at work?
How do you answer if it was asked for you in an interview?

Leave me a comment!

How I Doubled My Salary in 1.5 Years: My Developer Journey Through Job Switches and Career Growth

shriramcs — Fri, 20 Sep 2024 11:31:09 +0000

Hello, I'm Shriram Sapparad, a software engineer focused on the frontend of web application development at Ikea, Sweden.
I would like to share my story about how I achieved both career growth and financial stability in the early days of my career.

TLDR: Work on the opportunities, ask for a salary hike or promotion if it is in scope in current org else switch job.

At the end of 2014, I made my first job switch, moving from Tata Consultancy Services (TCS) to Société Générale. After working in IT for five years, I felt it was time for a change. It was also the beginning of the front-end development boom, and I decided to learn Angular for a new company project. I worked day and night on this exciting project because I enjoyed it so much.

That same year, I also got engaged, and things started moving quickly in my life in 2015. I was lucky to have a supportive team and great colleagues who helped me not only improve my technical skills but also advised me on financial planning, especially as I was preparing to start my own family.

Within a year, I switched jobs again, this time to Thermo Fisher Scientific. Over a period of 1.5 years, with two job switches and improving my tech skills, I was able to double my salary by 100%.

After my marriage, I was managing some financial responsibilities. I was paying off a marriage loan and also supporting my family back in my hometown by sending a monthly amount to my father. Despite these obligations, I didn’t want to cut back on my expenses, so I started looking for ways to earn more.

I began reading stories on Quora about how to get into top IT companies that pay well. However, I realized that top-tier tech companies like FANG (Facebook, Amazon, Netflix, Google) weren’t the right fit for me. I didn’t see myself as someone who would build innovative tech, but rather as someone who develops solutions using the best tools available.

Eventually, I found my place in financial and IT companies. I prepared well and was able to crack an interview with JPMorgan Chase. This marked a new phase in my tech career, where I achieved both career growth and financial stability.