Hiring Senior Engineers Beyond Coding Interviews

For a long time, I strongly believed in coding interviews, especially when hiring senior engineers. I wanted to know whether candidates could write clean code, solve problems, understand algorithms and data structures, and make sound technical decisions.

I still believe those skills matter.

However, after spending years building engineering teams and hiring senior engineers, my thinking has evolved. I have learned that coding ability is only one part of what makes someone a great senior engineer.

One of the most important lessons came from candidates who had strong technical skills but struggled to demonstrate system thinking. They could solve the problem in front of them, but when the discussion moved toward architecture, ownership, trade-offs, business impact, and what happens beyond their own piece of code, the gap became visible.

That changed the way I think about senior engineering hiring.

The question is no longer simply, “Can this person write good code?”

The more important question is:

“What kind of impact will this person have on the engineering organization?”

What to Look for When Hiring Senior Engineers

Let me be clear: I have not stopped believing in coding rounds.A senior engineer should have strong technical fundamentals. They should be able to write maintainable code, debug difficult problems, understand their technology stack, review other engineers’ work, and make sound technical decisions.

Technical competence is not optional.

But I have started looking at coding ability as the foundation rather than the complete definition of seniority.

As engineers become more senior, their responsibilities expand beyond implementation. They are expected to understand the larger system, make decisions under uncertainty, work with product and business teams, identify risks, mentor other engineers, and take ownership when something goes wrong.

That is where a traditional coding interview starts to become insufficient.

The Challenge of Hiring Senior Engineers

A typical engineering interview often follows a familiar pattern: coding round, technical discussion, system design, and finally a managerial or HR discussion.

There is nothing inherently wrong with this structure. The problem is how we interpret the results.

It is easy to use coding performance as a proxy for overall engineering capability. If someone solves difficult problems quickly and communicates their solution well, we naturally assume they will perform well in a senior role.

But senior engineering is rarely about solving a clearly defined problem with all the necessary information available.

Real engineering is messy.

Requirements change. Production systems fail. Customers behave differently than expected. Legacy systems have constraints. Teams disagree about technical decisions. Business priorities change halfway through implementation.

A senior engineer needs to operate effectively in that environment.

That requires more than coding skill.

Hiring Senior Engineers for Ownership

Over time, this has changed the way I approach hiring senior engineers. The biggest change in my thinking has been around ownership. A task-oriented engineer thinks, “I completed my task.”

A senior engineer should think, “I own the outcome.” There is a significant difference between the two. This is one of the biggest lessons I have learned while hiring senior engineers.

Imagine a production issue affecting customers. A task-oriented mindset might focus on determining which service or team is responsible for the problem. An ownership mindset starts somewhere else: the system is having an issue, customers are affected, and we need to understand what is happening and get it resolved. Ownership doesn’t mean that one engineer personally fixes everything. It means they take responsibility for moving the problem toward a resolution.

That is one of the strongest signals of seniority I look for today.

What Engineering Ownership Looks Like

Ownership starts with understanding outcomes rather than simply completing requirements.

A senior engineer should want to understand why something is being built, who will use it, what problem it solves, and what success looks like. They should be willing to challenge assumptions when necessary rather than blindly implementing whatever is written in a ticket.

Ownership also extends to quality. Quality is not something that belongs only to the QA team. Senior engineers should care about reliability, security, performance, maintainability, testing, observability, and operational readiness. If something they built creates repeated problems in production, completing the original ticket shouldn’t be considered the end of their responsibility.

The same applies to technical debt. Every engineering organization accumulates technical debt. The problem isn’t having technical debt; the problem is ignoring its impact. I look for engineers who can identify technical debt, explain the business and technical consequences, and propose a practical way to address it.

There is a big difference between saying, “This code is bad,” and saying, “This design will become a bottleneck as our usage grows. Here is the risk, here are the alternatives, and here is how I would improve it without disrupting current delivery.”

System Thinking in Senior Engineer Hiring

One of the biggest lessons I’ve learned from senior engineering interviews is that local optimization is not enough. An engineer might design an excellent component, but how does that component interact with the rest of the system? This is particularly important when hiring senior engineers, because the role demands a much broader view of the technology landscape.

Does it affect other services? Does it introduce database constraints? What happens to performance as usage grows? How will it be monitored? How will it be deployed? What happens when a dependency fails? How will another team maintain it six months from now?

These questions reveal whether someone is thinking about a component or thinking about a system. When I discuss architecture with senior candidates, I am not looking only for a particular architecture or technology choice. I am interested in how they arrive at the decision.

During architecture discussions, I pay attention to how candidates approach the problem. I look for people who ask clarifying questions, identify trade-offs, consider failure scenarios, and think about operational complexity. I also want to understand whether they consider cost, scalability, and the impact their decisions may have on other teams.

There isn’t always one correct answer. What matters is whether the engineer can reason through the problem.

The Questions I Ask Have Changed

Earlier in my career, I focused heavily on questions such as, “Write an algorithm to solve this problem.” I still use those questions when appropriate. But for senior engineers, I now spend more time asking about systems they have actually owned.

I might ask them to describe a system they were responsible for and then keep going deeper.

I usually start by asking why the system was designed that way and what alternatives were considered. From there, I want to understand what went wrong during implementation and what the engineer would change if they were making the decision today. I also ask how they measured success and what they learned once the system went into production.

These conversations often reveal much more than a theoretical architecture exercise. They show how someone behaves when they have real responsibility. These conversations often reveal much more than a theoretical architecture exercise.

They show how someone behaves when they have real responsibility.

I Look for the “Why”

One of my favorite ways to understand how a senior engineer thinks is to keep asking one simple question: why?

I want to understand the reasoning behind their technical decisions. Why was a particular database chosen? What made microservices a better fit than a simpler architecture? What problem did caching solve? Why was synchronous communication preferred? What was the thinking behind introducing a particular abstraction?

The conversation becomes even more interesting when we discuss decisions that involve trade-offs. Perhaps the team knowingly accepted some technical debt, or perhaps a simpler solution was rejected because it created problems elsewhere.

There isn’t necessarily a right answer to these questions. That is precisely why they are useful. I am not trying to determine whether a candidate would make the same decision I would make. I want to understand whether they can evaluate alternatives, recognize trade-offs, and explain the reasoning behind their choices.

A strong senior engineer doesn’t need to agree with me. They need to be able to explain why they made the decision and demonstrate that they understand its consequences.

Communication Is an Engineering Skill

Another lesson I have learned is that communication is not simply a “soft skill” that sits outside engineering. For senior engineers, communication is part of the engineering job.

Senior engineers work across product, business, QA, DevOps, security, architecture, and other engineering teams. They need to explain technical complexity to people who may not have the same technical background.

A senior engineer should be able to explain the available options, describe the trade-offs, recommend a direction, communicate the risks, and make the next steps clear.

That ability creates leverage. Technical knowledge that cannot be communicated effectively often remains isolated with one person. Good communication turns that knowledge into something the entire organization can use.

I Look for Engineers Who Multiply Others

Another strong indicator of seniority is the impact an engineer has on the people around them.

Technical leadership isn’t always about being the person with the deepest knowledge in the room. It is often about helping others become better engineers. I look for people who mentor teammates, give thoughtful feedback during code reviews, share knowledge, and help establish practices that make the entire team more effective.

A senior engineer should also be willing to invest time in less experienced engineers. Helping someone understand a difficult concept, guiding them through a design decision, or giving them the confidence to solve a problem independently can have a much greater long-term impact than solving the problem yourself.

The best senior engineers don’t become bottlenecks that everyone depends on. Instead, they create more capable engineers around them.

That is what I mean by multiplying others.

Individual contribution creates output. Engineering leadership creates leverage. And as engineers become more senior, that leverage becomes one of the most valuable things they can bring to an organization.

Seniority Is About Leverage

This is probably the biggest lesson I have taken from hiring and working with senior engineers. A junior engineer can create value by completing tasks. A mid-level engineer can independently solve problems.

A senior engineer should create leverage.

That leverage can come from better architecture, better engineering practices, better systems, better documentation, better automation, better technical decisions, and better mentoring.

The code they personally write is only one part of their contribution.

As engineers become more senior, I expect their impact to extend beyond their own repository, service, or sprint.

How I Think About Senior Engineer Evaluation

Today, when evaluating a senior engineer, I think about five dimensions: technical depth, system thinking, ownership, decision-making, and engineering impact. Technical depth tells me whether they can handle difficult engineering problems.

System thinking tells me whether they understand how individual decisions affect the broader product and architecture. Ownership tells me whether they take responsibility for outcomes rather than simply completing assigned work. Decision-making tells me whether they can evaluate trade-offs and make pragmatic choices under uncertainty.

Engineering impact tells me whether they make the systems and people around them better. Coding remains an important part of this evaluation. But it is one dimension of a much larger picture.

The Question I Ultimately Want Answered

After a senior engineering interview, there is one question I increasingly ask myself:

If I give this person a difficult engineering problem with ambiguity, will they wait for instructions, or will they take ownership and drive it toward an outcome?

That distinction matters because real engineering rarely looks like an interview problem. Production doesn’t give you a clean problem statement. Customers don’t provide algorithm constraints. Legacy systems don’t come with perfect architecture diagrams. Incidents don’t happen at convenient times. Business requirements change.

Senior engineers need to be comfortable operating in that ambiguity.

Hiring for the Engineer You Need Tomorrow

One of the biggest mistakes I try to avoid when hiring senior engineers is hiring only for today’s problems. When hiring a senior engineer, I want to understand what the organization will need from that person six months or a year from now.

I’m not only asking, “Can this person solve the problems we have today?”

I’m asking:

“Can this person help us solve problems we haven’t encountered yet?”

That requires technical depth, but it also requires curiosity, ownership, system thinking, communication, and the ability to make others better.

My Biggest Lesson From Hiring Senior Engineers

I still believe coding rounds have an important place in the hiring process. Strong technical fundamentals remain essential, and I continue to challenge senior engineers on their ability to solve difficult engineering problems.

What has changed is how I interpret those results.

A strong coding performance tells me that someone can solve a technical problem. It doesn’t necessarily tell me whether they can own a system, navigate ambiguity, make sound architectural decisions, or create impact beyond their individual contribution.

Over time, I have learned not to confuse coding ability with engineering maturity.

Some of the strongest senior engineers aren’t necessarily the people who write the most code. They are the people who make the right problems visible, take ownership when things go wrong, make thoughtful technical decisions, build systems that other engineers can work with, and raise the capability of the people around them.

That is what I now look for when hiring senior engineers.

At senior levels, I am not hiring someone simply to write code. I am hiring someone to own outcomes, solve problems, and raise the engineering capability of the organization.

From Code Chaos to an Enterprise-Grade CI/CD Platform: How I Standardized Engineering Delivery Across the Organization

Leave a reply

Enterprise CI/CD Platform: Standardizing Engineering Delivery with Jenkins, Nexus & Kubernetes

Software delivery has evolved significantly over the last decade. Yet, many engineering organizations still struggle with inconsistent deployment processes, fragmented tooling, and dependency management issues that slow down development and increase operational risk.

When I took ownership of engineering delivery, I quickly realised that the challenge wasn’t simply the absence of CI/CD. The organisation had capable engineers, good products, and ambitious goals-but every team followed a slightly different way of building, packaging, and deploying software.

Different repositories had different build scripts.
Some applications were deployed manually.
Docker images were stored inconsistently.
Frontend teams downloaded packages directly from npm.
Python projects depended on public PyPI repositories.
Every deployment felt like its own unique process.

As engineering teams grow, these inconsistencies become technical debt.

Instead of solving deployment issues project by project, I decided to build Enterprise CI/CD Platform that every development team could use consistently. The objective wasn’t just automation. It was standardisation and governance. It was creating a software delivery platform that engineers could trust.

The Problem with Growing Engineering Teams

As organisations scale, delivery complexity increases faster than application complexity.
One team introduces a shared UI library. Another creates utility functions. Someone publishes a Docker image. Another team copies code instead of reusing it. Soon every project looks different. This creates several common challenges:

Manual deployments prone to human error
Different build processes across projects
Repeated code across repositories
Public dependency risks
Inconsistent versioning
Lack of deployment traceability
Slow onboarding for new developers
Difficult rollback during production incidents
No central governance for reusable components

These problems aren’t caused by poor engineers. They are symptoms of a platform that hasn’t evolved with the organisation.

Looking Beyond CI/CD

Many organisations believe adopting Jenkins, GitHub Actions, or Azure DevOps automatically means they’ve implemented CI/CD. In reality, these tools are only automation engines. A mature engineering platform goes much further.

It should answer questions like:

Where are application artifacts stored?
How are shared libraries managed?
Who owns reusable packages?
How do teams consume internal components?
How are deployments standardised?
How do we secure our software supply chain?
How do we make onboarding effortless?

Once we started asking these questions, it became clear that what we needed wasn’t another build server. We needed an internal engineering platform.

Enterprise CI/CD Platform Architecture

The delivery platform was designed around a simple philosophy. Every application should follow the same journey from source code to production. The architecture consisted of four primary components:

Azure DevOps

Source control
Pull requests
Branch policies
Sprint management
Work item tracking

Jenkins

Pipeline orchestration
Build automation
Test execution
Artifact creation

Sonatype Nexus Repository

Docker Registry
npm Registry
PyPI Registry
Versioned artifacts
Dependency caching

Kubernetes

Automated deployments
Rolling updates
Self-healing infrastructure
Container orchestration

This architecture established a single, repeatable software delivery pipeline that every project could adopt.

Azure DevOps as the Single Source of Truth

Everything begins with source code. We standardised repository structures, enforced pull request workflows, and introduced branch policies to improve code quality before builds even started. Every change became traceable. Deployment could be linked back to a work item. Every release had complete visibility. This eliminated ambiguity around what had changed and why.

Jenkins: Automating Every Build

Jenkins became the automation engine that transformed source code into deployable software. Rather than creating unique pipelines for every project, we established reusable pipeline templates that followed the same lifecycle:

Checkout source code
Install dependencies
Execute unit tests
Perform static analysis
Build the application
Build Docker image
Tag using semantic versioning
Publish artifacts
Trigger deployment

Because pipelines were defined as code, every application inherited the same engineering standards. Developers no longer had to remember deployment steps. The platform handled them automatically.

Nexus Repository: The Heart of Engineering Standardisation

This was arguably the most transformative part of the platform. Many teams use Nexus purely as a Docker registry. We expanded its role into a central engineering asset repository. Instead of downloading everything directly from the internet, our teams consumed approved, version-controlled packages from internal repositories. This significantly improved consistency, reliability, and governance.

Docker Registry: Trusted Container Images

Every build produced a versioned Docker image. Instead of building containers directly on deployment servers, Jenkins published immutable images into Nexus. This provided several benefits:

Central image repository
Consistent deployments
Easy rollback
Complete version history
Controlled access
Faster deployments

Deployments became predictable because every environment pulled the exact same container image. No surprises. No environment-specific builds.

npm Registry: Encouraging Reusable Frontend Engineering

One of the biggest improvements was introducing an internal npm registry. As frontend applications matured, multiple teams began solving the same problems repeatedly. Rather than copying code between repositories, we converted shared functionality into reusable packages.

Examples included:

Shared UI component library
Configuration framework
API client SDK
Authentication helpers
Common utilities
Design system components

Developers simply installed internal packages like any other dependency.
Versioning became controlled. Updates became intentional. Shared components evolved independently without affecting every project immediately. This dramatically reduced duplicate code while promoting engineering consistency across frontend applications.

PyPI Registry: Standardising Backend Development

The same philosophy was applied to Python services. Instead of copying helper modules between repositories, we published reusable Python packages into our internal PyPI registry. These packages included:

Authentication libraries
Logging framework
AI helper modules
Prompt management utilities
Database connectors
Common integrations
Shared middleware

Each package had proper versioning, ownership, and release management.
Developers focused on solving business problems rather than rewriting infrastructure code.

Why Internal Package Registries Matter

Many organisations underestimate the importance of private package repositories.
They deliver far more than convenience. They establish engineering discipline.

Benefits include:

Approved dependencies
Faster builds through caching
Better security
Reduced internet dependency
Controlled package versions
Central ownership
Easier auditing
Better governance

Most importantly, they encourage engineers to think in terms of reusable platforms instead of isolated projects.

Kubernetes Completed the Automation Story

Once artifacts were published, deployments became straightforward. Applications followed a consistent deployment workflow:

Source Code
Build
Unit Tests
Docker Image
Nexus Repository
Kubernetes Deployment
Health Checks
Rolling Updates
Application Available

Every release followed the same process. The deployment mechanism was no longer dependent on individual engineers. It became part of the platform itself.

Improving Security Through Standardisation

Modern DevOps is also about securing the software supply chain.
By centralising artifact management, we gained several security advantages:

Controlled package approvals
Private Docker images
Internal npm packages
Internal Python packages
Version traceability
Credential management
Immutable release artifacts
Reduced exposure to public dependency risks

Security became an integrated part of software delivery rather than an afterthought.

Developer Experience Improved Dramatically

One of the biggest wins wasn’t faster deployments. It was a better experience for developers. New engineers no longer spent days configuring environments. Projects followed the same structure. Dependencies came from trusted internal repositories.
Pipelines behaved consistently. Deployment steps were predictable. Developers could spend more time writing software and less time understanding infrastructure. That consistency improves productivity in ways that are difficult to measure but impossible to ignore.

The Business Impact of Enterprise CI/CD Platform

Technology leaders often focus on tools. Business leaders focus on outcomes. The platform delivered measurable improvements across the engineering organisation.

Before	After
Manual deployments	Fully automated delivery
Different pipelines	Standardised CI/CD
Public dependencies	Internal package ecosystem
Code duplication	Reusable libraries
Environment inconsistencies	Immutable artifacts
Difficult rollback	Version-controlled releases
Slow onboarding	Faster developer productivity
Limited governance	Central engineering standards

Looking back, the achievement was not automating deployments. It was changing the way engineering teams worked together. As engineering leaders, our responsibility isn’t simply to choose the right tools. It’s to build Enterprise CI/CD Platform that enable our teams to deliver exceptional software with confidence, every single day.

Part 1: Demystifying NER – How Named Entity Recognition Helps Understand Test Cases

Leave a reply

NER - Named Entity Recognition — NER – Named Entity Recognition

Blog Series Overview

Writing test cases in plain English is second nature for most QA professionals—but what if machines could understand and act on those instructions directly? This is where Named Entity Recognition (NER), a powerful Natural Language Processing (NLP) technique, comes into play. By identifying key entities like actions, screens, and objects from everyday language, NER helps bridge the gap between human-readable test steps and machine-executable automation scripts. In this post, we’ll explore how NER in QA can transform natural language test cases into structured data that powers AI-driven test automation.

What is Named Entity Recognition (NER)?

Named Entity Recognition (NER) is a subtask of Natural Language Processing (NLP) that identifies and classifies words or phrases in a sentence into predefined categories. In the context of NLP test automation, NER plays a crucial role in breaking down plain English test steps into actionable components. For example:

Screens – UI areas like "Login screen" or "Job Order page"
Actions – Operations like "insert", "submit", "delete"
Objects – Functional items such as "Job order", "form", or "user"

For more details about NER, check this Wikipedia Link

How I trained my NER model?

To build a truly custom test automation solution, I didn’t rely on generic models. Instead, I fine-tuned a BERT-based Named Entity Recognition (NER) model specifically trained to understand test case language written in natural English.

Why BERT?

I chose bert-base-cased from Hugging Face Transformers as the base model for a few reasons:

It’s pre-trained on a massive corpus of English (Wikipedia + BookCorpus), giving it a solid grasp of language structure.
The “cased” version preserves capitalization, which is often useful in UI terms like “Login Screen” vs “login screen”.
It’s proven to perform well on token-level classification tasks like NER, especially after fine-tuning on a domain-specific dataset.

My Fine-Tuning Approach

I created a small, task-focused dataset where each sentence is a simple test step like:

“Create Job Order Screen”

Each sentence is tokenized and labeled like this:

["Create", "Job", "Order", "Screen"]
["0", "B-ORDER", "I-ORDER", "B-TOOL"]

This tagging format is based on the IOB (Inside-Outside-Beginning) scheme commonly used for NER tasks.

The Training Pipeline

Here’s the overall workflow I followed:

Tokenization:
Used BertTokenizerFast to tokenize inputs while aligning labels with tokenized outputs.
Dataset Preparation:
- Created synthetic but diverse train and test datasets.
- Used Hugging Face datasets.Dataset class for formatting and transformation.
Label Alignment:
Carefully handled alignment between original tokens and subwords, marking non-aligned subwords with -100 (to be ignored during loss computation).
Fine-Tuning:
Used the Trainer API from Hugging Face with:
- Learning rate: 2e-5
- Batch size: 16
- Epochs: 5 for better convergence
- Evaluation metrics: Precision, Recall, F1-score using sklearn
Model Saving:
Finally, saved both the fine-tuned model and tokenizer locally for reuse:

model.save_pretrained("./fine_tuned_ner")
tokenizer.save_pretrained("./fine_tuned_ner")

This saved model is now capable of understanding test steps like:

“Open Job Order Screen”
“Open Service Request Screen”
“Initiate Quality Check Screen”

and accurately tagging entities such as:

B-SCREEN, I-SCREEN – for multi-word actions
B-TOOL – for tools or execution components

Now that the model is trained and saved, it’s time to put it to work—converting plain English test steps into structured, automation-ready formats.

In the next post, we’ll dive into intent detection—how it complements NER and helps drive even smarter automation pipelines.

Kubernetes for Web Developers

Leave a reply

Kubernetes, also known as k8s, is very popular term now a days among the developers. Many companies are adopting it now a days. The primary reason for this is rapid shift from monolithic architecture to micro-services and micro-frontend architecture. This blog post is about web developers who are curious about K8S. We will understand,

Why a web developer should know about k8s
Fundamentals of K8S
Getting started with K8S

Why would a Web Developer learn K8S?

Adopting micro-service architecture has many benefits. It makes developing, deploying, and scaling very effective for backend applications. Same goes for micro-frontend architecture. You can read more micro-frontend in my previous blog Frontend Development Trends of 2022

For both micro-service and micro-frontend k8s plays vital role. It allows developers to build containerised application, which is highly scalable. K8S helps developers build the ‘infrastructure as code’ and also helps them manage coding environment configurations as code. Hence as a web developer it’s good to know fundamentals k8s.

Let’s now understand some of the fundamentals of k8s.

What is K8S?

Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management. Google originally designed K8S, but the Cloud Native Computing Foundation now maintains the project. It handles the container deployment, scaling and load balancing of containers.

What is Docker?

Docker is an open source containerization platform. It is a set of platform as a service products that use OS-level virtualization to deliver software in packages called containers. For your backend or frontend applications, we have the Dockerfile. It defines the build process for the application. When we build it with docker build command, it will install all the necessary dependencies, and create an immutable image, which can be used to run the application.

How Docker and K8S works together ?

As mentioned above using Docker you can containerize your application, means it helps creating the container. Kubernetes will help you in managing these containers.

Let’s first understand few terms of K8S.

K8S containers

Containers are standardized, self-contained execution enclosures for applications. For each application and Microservice, a container is created which will have all the necessary dependencies required to run the application like node modules.

K8S PODs

Pods are the smallest execution unit in a Kubernetes. In Kubernetes, containers do not run directly on nodes. One or more containers are encased in a pod. All applications in a pod share the same resources. For each application and Microservice, a POD is created which encases the container for each application.

K8S Nodes

Node is the smallest unit of compute hardware in Kubernetes cluster. Nodes can be physical on-premises servers, or VMs which are there in cloud provider. Together Nodes will form a Kubernetes Cluster. For each Pod we can assign Nodes in the Kubernetes cluster. That means your application will be running from different Nodes as a part of scaling and load balancing with Kubernetes. Every node runs an agent called kubelet, which communicates with the cluster control plane.

Easy way to start with Managed K8S

From above all terminologies it looks difficult to start with Kubernetes. That’s why it’s recommended to start with managed kubernetes. Managed Kubernetes is like third-party providers. They take over responsibility for some or all of the work necessary for the successful set-up and operation of K8s. By opting for a managed Kubernetes solution, you don’t have to deal with complexity associated with deploying and operating your containerized applications. There are many vendors available who provide you managed kubernetes platform.

Google K8S Engine (GKE)

GKE is one of the most advanced managed platforms available. Designed for use on Google Cloud. GKE gives you complete control over every aspect of container orchestration.

Learn more about GKE from official GKE website

Amazon EKS

It is a managed Kubernetes service that makes it easy for you to run Kubernetes on AWS.

Learn more about it from official Website

In the next blog post we will learn how to contanarize your frontend and backend applications.

OpenFGA – Open Source Authorization by Auth0

Leave a reply

Few days back I came to know about OpenFGA – Open Source Authorization by Auth0. Since then I am exploring it a bit. Here in this blog post we will understand what is OpenFGA.

Whenever we discuss about authorization, there is always a confusion about difference between authentication and authorization. Let’s first clear that.

Difference between Authorization and Authentication

Authentication is all about identity of the user. Authorization is all about what user can do with your system. As an application developer or system architect we always face challenges with Authorization.

There are lots of things involved with Authorization. It includes,

Access to system entities.
What all URLs user can access
Types of actions, like create / read / update/ delete
Grant and revoke permissions etc.

Considering above factors it’s always a challenge to implement robust architecture for the authorization.

OpenFGA – Fine Grained Authorization Solution

It’s a fast, scalable and flexible system. It’s inspired by Google’s Zanzibar project. This paper presents the design, implementation, and deployment of Zanzibar, a global system for storing and evaluating access control lists.

Auth0 / Okta developed OpenFGA on top of Google’s Zanzibar and made is open source. It is easy for application developers to develop their access control layer, and to add and integrate authorization which is consistent across all of their applications.

Why it is important?

As mentioned earlier in the post authorization is very critical and complex aspect of modern applications and platforms. With increasing demands from users, it’s crucial to build robust system without compromising cyber security.

Let’s understand building blocks of OpenFGA one by one.

OpenFGA Server

This act as permission engine. It uses expressive language to define your authorization model. This server consists of HTTP APIs using which one can,

Define permission models
Querying and modifying them
Checking and granting permission

It has modular data storage. It supports an in-memory database and PostgreSQL. Also it has graph querying implementation inspired by Google Zanzibar. It is also available as docker image, you can check the quick start guide here.

OpenFGA Client

There are no of choices of SDK available to use in your application to set up a client. Available SDKs are GO SDK, .NET SDK, JS SDK. The client allows you to interact with the server API in an idiomatic way.

Client works with store. A store is a OpenFGA entity that contains your authorization data. You will need to create a store in OpenFGA before adding an authorization model and relationship tuples to it.

How does it work?

Let’s first get high level overview of how does it work before we see the code example. Let’s take an example of project management system.

Define the model

A project can be created by an employee.
It can be approved by manager of employee.
Team member can view project.

To solve this problems, we will define the authorization model.

type project
relations
define creator as self
define approver as manager from creator
define team-member as self or creator or approver

type employee
relations
define approver as self or manager

Define the tuples

Once model is defined you will pass data by using the OpenFGA’s Write API and a few “tuples”.

Define employee manager relation. Here John is the manager of Smith. Hence he become approver.

{ 
    "user": "employee:john",  
    "relation": "approver", 
    "object": "employee:smith" 
}

Employee create project

{
"user": "employee:smith",
"relation": "creator",
"object": "smith-project"
}

Team member added.

{
"user": "employee:jane",
"relation": "team-member",
"object": "smith-project"
}

Now we can use OpenFGA’s Check API, which will return true or false for the tuples. Based on the user, relation and object the API will return true or false.

In the next post, we will understand about js-sdk for OpenFGA and see how we can use it.

Better Development Experience with Vite

Leave a reply

Few days back I came to know about an amazing frontend tool Vite. Since then I am exploring it a bit. Here in this blog post we will go through some of the feature of Vite. We will also see how Vite can make your web development experience faster and better.

There is already a discussion going on around Vite as a replacement of Webpack. In this post we will avoid this discussion. We will focus more on features of it.

What’s the need of bundling tools like Vite in your web app?

Since the ES6 modules introduced it’s a good practice to write JS code in a modular fashion. But in early days a lot of browsers were not handling loading ES6 modules natively. So we have the concept of bundling our code, using tools like webpack. The tools like Webpack and Vite converts source modules into the code that can run in the browser. These tools crawls through your code, find out dependencies and process it. Once processed it generates the bundle of all your module which can run in browser.

What are the problems with existing tools?

As we mentioned above the tools like Webpack and all, crawls through source code and process it. This works fine when you have smaller project and less no of modules. Once project grows and no of modules grows, we start experience following issues.

Very Slow start of dev server
Slow file updates
Slow HMR
Longer build time

The reason is, code transpile and concatenate takes time once your project grows. This affects the developer ‘s productivity. Every time we have to wait for the build and to start the dev server for every small changes.
So how Vite solves these issues? There are two primary things.

Pre bundling of Dependencies

When we work with web apps we use lots of vendor packages. These are external dependencies which are not going to change during the development. What Vite does is, it pre bundles these dependencies esbuild. esbuild is extremely fast JavaScript bundler.

Dependency resolving and serve

For the application source code, it resolves the dependencies and only transform and serve source code on demand. That means no time spent on bundling your source code before server starts. Here browser will take care of bundling and requesting the module as and when it’s required.

This leads to a great developer experience as we don’t have to have for serve to start. Also there is blazing fast HMR.

Here is how Vite works.

Getting Started with Vite in your React Project

Let’s see an example of how to work with Vite in your React Application. First we will start by adding necessary dependencies in your app.

"devDependencies": {
    "@vitejs/plugin-react": "^1.0.7",
    "vite": "^2.7.2"
  }

Also you have to add a config file. Following is the bare minimum configuration needed. For more options you can check out the documentation here. Vite config

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()]
})

To start the dev server with Vite, you just have to use command vite or npm run dev. Once this command is executed it will look for index.html file where you should specify your entry point.

<script type="module" src="/src/main.jsx"></script>

That’s it and it will start the dev server in fraction of seconds. If you check the network tab of your browser you can see the main.jsx is loaded as native ES module.

Fast HMR

HMR is the strategy to allow module to Hot Replace it self without affecting the page. This way we can see our changes instantly on the screen. This works fine when have smaller code but as your project grows HMR takes lots of time. This greatly affects the productivity as every time we have to wait for bundling.

When file is edited and saved it just invalidate the edited module and and its closest HMR boundary. Also if you see network tab, Vite requests the source cod with specific HTTP headers. For dependencies module requests, it uses the cache control header to cache the requests so it does not hit server. For source code module requests it uses 304 Not Modified to conditionally load it.

Because of all these features Vite is becoming popular among developers and its adoption is increasing day by day.

I will soon share my experience of replacing Webpack with Vite in larger project.

TensorFlow.js Image Classification with MobileNet Model

Leave a reply

TensorFlow.js is a library for machine learning in JavaScript. Using TensorFlow.js one can,

Run existing model
Develop ML models in JavaScript
Use existing model and retrain it

Here in this blog post we will see first use case which is to run existing model. We will use MobileNet model to predict object through webcam.

TensorFlow.js Image Classification HTML

Let’s start it with basic HTML and add necessary scripts in it. First of all create one index.html file. Add following code in that file. Also create css folder and tfjs folder. Here we will out our style.css and our JS file to start image classification

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Image Classification</title>
    <link rel="stylesheet" href="css/style.css">
  </head>
  <body>
    <button id="webCam" class="btn webCam-button" onclick="openWebCam()">Start Web Cam</button>
    <div class="webcam-popup" id="webCamDisplay">
      <video autoplay playsinline muted id="webcam" width="224" height="224"></video>
      <button type="button" class="btn" id="predict" onclick="predictObject()">Predict</button>
      <button type="button" class="btn cancel" onclick="closeWebCamDisplay()">Close</button>
    </div>
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs/dist/tf.min.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/mobilenet"></script>
    <script src="tfjs/imageClassification.js"></script>
  </body>
</html>

As you can see in above HTML, we have very simple HTML here. We have button to start web cam. There is video element to show the preview of web cam. Then we have couple of buttons to start prediction. Now let’s add CSS. Create style.css in css folder and add following styles to it.

CSS Part

html {
  font-size: 60%;
  overflow-x: hidden;
  scroll-padding-top: 5rem;
  scroll-behavior: smooth;
}

header {
  margin-bottom: 2rem;
  position: relative;
  margin-left: 70px;
  margin-top: 30px;
  font-weight: bold;
}
header h1 {
  font-size: 30px;
  margin-left: 20px;
  font-weight: bold;
}

.btn {
  margin-top: 1rem;
  display: inline-block;
  padding: 1rem 2rem !important;
  border-radius: 1rem;
  color: #fff;
  background: #189ab4;
  font-size: 1.5rem !important;
  cursor: pointer;
  font-weight: 600 !important;
  margin-right: 10px;
}

.webCam-button {
  color: white;
  padding: 16px 20px;
  border: none;
  cursor: pointer;
  position: fixed;
  bottom: 140px;
  right: 28px;
}

.webcam-popup {
  display: none;
  position: fixed;
  bottom: 0;
  right: 15px;
  border: 3px solid #f1f1f1;
  z-index: 9;
  background-color: black;
}

JavaScript Part

Now we have html and css ready. It’s time for some JavaScript logic. We will create file with name imageClassification,js in tfjs folder and add following code to it.

const webcamElement = document.getElementById('webcam');
let startPrediction =  false;

async function app() {
  console.log('Loading mobilenet..');

  net = await mobilenet.load();
  console.log('Successfully loaded model');
  
  const webcam = await tf.data.webcam(webcamElement);
  while (true) {
    const img = await webcam.capture();
    const result = await net.classify(img);

    for(var i = 0 ; i < result.length ; i++ ) {
      res = result[i];
      if(res.probability > 0.5) {
        alert(res.className);
        location.reload();
        break;
      }
    }
    img.dispose();
    await tf.nextFrame();
  }
}

function openWebCam() {
  document.getElementById("webCamDisplay").style.display = "block";
}

function closeWebCamDisplay() {
  document.getElementById("webCamDisplay").style.display = "none";
}

function predictObject() {
  app();
}

Here we have functions to open & close pop up. There is predict button. Where we will start web cam preview and load the MobileNet Model. We are using async await syntax to wait till MobileNet model is loaded and then start the prediction. Following line loads the model.

net = await mobilenet.load();

Then we set the data source which is our webcam preview with following line.

const webcam = await tf.data.webcam(webcamElement);

Then we have while loop added where we capture the image frame and try to classify it with MobileNet model.

const img = await webcam.capture();
const result = await net.classify(img);

We are checking the results with accuracy over 50% to check if the classification is correct or not. If probability is good we show the classname in alert. This class name contains the name of object. It’s coming from MobileNet trained data.

When you run the code it may take a while to predict the object. You can check it out by placing multiple objects in front of web cam and check. Following are few examples.

As you can see in few cases the prediction is correct for example, mobile phone and mouse. But in the first case it’s wrong. I am not wearing bullet proof vest.

You can read more about TenorFlow.js on Official Website

Here is the link to MobileNet Model GitHub

React Developer Tools for Better Development

Leave a reply

In this blog post we will go through some of the useful React Developer Tools, that can help you in development and debugging of your React apps. Using this tool one can write better and cleaner code.

React Developer Tools

Some of the tools which we are going to cover here are Debugging Tools, Libraries, Test utilities etc. Using these tools you can enhance code quality and performance of your react app.

React Developer Tools I have mentioned here are based on my experience with it and use in the projects I am working on. If you know any other React Developer Tools, feel free to mention about it in comments.

React Developer Tool

This tool is available as browser extension for major browsers like Chrome, Firefox, Edge. It is also available as separate NPM package if you want to use it in mobile browser for debugging. Here is the link react-devtools

This is very popular tool, useful for both developing and debugging React apps by all the developers worldwide. Also known as React dev tool gives you a way to debug the rendered components through tab in dev tools. You can view all the props and its value for a particular component.

The feature, I like most is the, visual representation of components re render with timestamps. This is most useful for enhancing the performance of the React App.

Storybook

This is a tool for developing your React UI components separately. It helps in terms of development, testing and documentation of UI components. Imagine that you want to showcase some UI component before using it in project. Using Storybook this is possible.

As a developer, we can create develop the component and share with teams to play with it. It works outside your react project so you don’t need to make any changes in project. You can simply create components and share the storybook with your teams. Checkout official Github of Storybook

Why Did You Render

While React Developer Tool can show the visualisation of re renders, WDYR can notify you about potentially avoidable re-renders. In short it can show you the possible root cause and then you can debug more and fix it. It also works with React Native as well.

This is a nice tool for performance tweaking of your React apps. It is available as NPM package, you can install and use it in your React app. For documentation please check the official Github page of WDYR

Webpack Bundle Analyzer

This is very useful tool to for analysing the application bundle to find out which modules are heavy and which modules can be removed. It uses the webpack stats JSON file to provide us with an interactive treemap visualization of the contents of our bundle.

It is available as npm plugin so you can install and configure it to use in your React application. Checkout the official GitHub of Bundle Analyzer

JEST

Jest was created by Facebook and is a testing framework to test javascript and React apps. You can do unit testing with JEST for your React App. Unit testing is utmost important to reduce bugs in your production app.

JEST is pretty much simple to configure and use with your React App. You can add it as npm package and set up the test. Writing unit test cases are considered to be good practices for the development. You can refer to official GitHub of JEST

Frontend Development trends to Look For in 2022

Leave a reply

As we are moving to new year 2022, it’s good to keep an eye on Frontend Development trends. You should keep up with this latest trends so you don’t miss any opportunity that could be a turning point of your career.

In this blog I am going to mention some Frontend Development trends, you should not miss out. This is based on what I have learned from industry. If you have some different opinion, feel free to share your feedback in comments.

1) Progressive Web Apps

PWA is already trending since last few years thanks to its native app like capabilities. It can be installed like native app. You can work with it offline. It is blazing fast. Major mobile browsers now support it. With PWA, you can access hardwares like camera, microphone etc.

Above all capabilities, made PWA favourite among developers and businesses operating over internet. Lots of businesses are using it and many more are vouching for it in upcoming year. Hence if you are a PWA developer you may have great chances to work with major online businesses.

2) Micro Frontend Architecture

In a simple words, it’s about breaking monolith frontend to smaller and independent applications. Together it works as one single application. This gives you more control over development and CI /CD. Many teams can work together and combining it together makes your entire frontend.

Many companies have already adopted this architecture and their productivity has been increased. This trend is going to dominate in upcoming year. If you are front end developer or architect it will be good to learn about this.

3) Rise of Voice User Interface (VUI)

Accessibility is a prime thing to look for in web application now a days. This gives rise to Voice User Interface. As a human, voice / language is the most natural way of communication for us. This is also another major reason behind the rise of VUI. Major companies like Amazon, Google, Apple has introduced the platforms like Alexa, Assistant and Siri. These platforms are open for developers to build applications on top of that.

Power of text to speech and speech to text technologies has increased exponentially. These gives good accessibility to your web apps. Your users can interact with apps with voice and also it is blessing for visually impaired people. There are still major challenges in this area. Like understanding regional languages. But it’s worth adding VUI in web app.

4) Rise of JAMstack

JAMstack ==> JavaScript + API + Markup

Core principles of JAMstack are Pre rendering and decoupling. JAMstack makes web app faster, more secure and easily scalable. You can convert your entire frontend to highly optimised prebuilt static pages which can be delivered from CDN. Let’s understand each part of JAMstack

JavaScript

As we know JavaScript is most popular when it comes to building web application. Using the modern frameworks like ReactJS, Angular, Vue and Svelte, we can develop web apps which is modularised and easy to maintain.

API

API plays vital role in JAMstack. As a developer it’s up to you that how you can make your JAMstack app dynamic by utilizing the API in proper way. From JavaScript you can make API call to multiple host which will deliver the content.

Markup

This is the most critical part of JAMstack. To be considered a JAMstack app, your app should server the HTML statically, which means not being dynamically rendered from a server. Markups is your prebuilt and pre rendered content. It is requested by JavaScript through API. Frontend developers can use frameworks like Gatsby, NextJs for this.

5) Rise of GraphQL

Facebook introduced GraphQL in 2018 to address the issues with REST APIs. The issue with REST APIs are you have make multiple network requests to get the entire data. This leads to performance degrade both on front end and back end. Using GraphQL we can obtain entire data with one single quest from one end point.

Few advantages of GrapQL is, it’s much faster, strongly typed and follows hierarchical structure where relationships between objects are defined in a graphical structure. Many big companies are using GraphQL. As a front end developer it’s good learn about GraphQL as more and more businesses are moving towards GraphQL

6) Web Assembly

Most of the time we use JavaScript for the web development. With web assembly developer can use code written in C and C++ in web browser. WebAssembly can help client apps to run on the web that previously was not possible. Sometimes we need to build app in lower level code like C, C++ etc. For example games or streaming apps. But it can’t run on web but with Web Assembly we can write apps in C, C++, RUST, Go Lang and run on the web with near-native performance. Web assembly works along with JavaScript in browser.

7) Machine Learning / Augmented Reality / Virtual Reality

How you can leverage the power of ML, AR & VR in your web app. To know more about this check out my session on Google DevFest India 2021 Day3

Hope you liked this blog about Frontend Development trends and keep exploring it more.

Laravel Copy Tables To Other Server

Leave a reply

Recently in one of my Laravel project, I had a situation where some of the tables are required to copy from one db server to other db server on real time basis.

First of all I thought about using binary logging but it, but my hosting provider refused to enable binary logging. Other option is to use federated storage engine. But hosting provider refused to enable it too. In fact the tech support team asked me a question that what is Fedarated storage engine? So I gave up the hope on them. Finally I implemented with the strategy that I am going to explain in this blog.

Using Laravel Observer and Eloquent

In Laravel we can use model observers to listen to the events on models and take actions. Here are steps you have to perform.

Step 1 : Create Observer

Create a new Class in App\Http\Observers folder and name is ModelObserver

Step 2 : Assign Observer to Model

In your model file add boot function as following.

public static function boot()
{
parent::boot();
YourModelName::observe(new \App\Http\Observers\ModelObserver);
}

Step 3 : Add Methods to Your Observer

In your ModelObserver class add following methods.

public function created($model)
{

}

public function updated($model)
{

}

Now when you insert or update record with Eloquent it will invoke created and updated method and will send model instance as param.

Replication to Other Server

Now next step is to implement replication strategy. For this we are going to create separate model and use remote server connection with that model.

Step 1 : Save Remote Host Connection

For this first of all create saparate MySql connection in your config/database.php file

‘replica’ => [
‘driver’ => ‘mysql’,
‘host’ => env(‘REPLICA_DB_HOST’, ‘remotehost’),
‘port’ => env(‘REPLICA_DB_PORT’, ‘3306’),
‘database’ => env(‘REPLICA_DB_NAME’, ‘your_db’),
‘username’ => env(‘REPLICA_DB_USERNAME’, ‘your_username’),
‘password’ => env(‘REPLICA_DB_PASSWORD’, ‘your_password’),
‘charset’ => ‘utf8’,
‘collation’ => ‘utf8_unicode_ci’,
‘prefix’ => ”,
‘strict’ => false,
‘engine’ => null,
]

Step 2 : Create Model to Connect to Remote Host

Now create a separate model and assign remote server connection to it.

<?php

namespace App\Http\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteModel extends Model
{
protected $connection= ‘replica’;
protected $table = ‘remote_table’;
}

Step 3 : Replicate Model

Now inside your observer’s created method add following code.

if($model instanceOf \App\Http\Models\Model){
$modelArray = $model->toArray();
$newModel = new \App\Http\Models\RemoteModel;
foreach( $modelArray as $key => $value ){
if(gettype($modelArray[$key]) != ‘array’){
$newModel[$key] = $modelArray[$key];
}
}
$newModel->save();
}

As you can see in above code that we are checking first if model created is type of our Model Class and then creating object of RemoteModel and assigning values of Model to RemoteModel object and then finally call save method, this will create row in remote table on remote server.