DEV Community: Kfir Zvi

GitGrit - The Open Source Engineering Standards Platform Built From a Decade of Pain Points as an Engineer

Kfir Zvi — Wed, 22 Jul 2026 17:20:12 +0000

In this article I'm going to present you with something I've been working on personally for almost two years now (on and off), and it's a topic close to my heart.

GitGrit - my open source, MIT licensed, engineering standards platform.

What the heck is an engineering standards platform? why do you even need it? Give me five minutes of your time to convince you it's exactly what you've been missing.

Self Introduction

Before we go on, let me introduce myself - I'm Kfir Zvi, an Israeli Software Engineer for the past decade. I've worked in many organizations and setups all the way from a founding member at a startup to big corps with tons of bureaucracy and infra to handle.
I specialize in backend development, designing highly scalable systems, and transforming messy, hard-to-understand systems and workflows to simpler, easier-to-maintain concepts that fit the human brain. I also enjoy DevOps and like to see how and where my code runs.

Today I'm running KfirZvi.com, the software studio behind GitGrit and hopefully soon enough behind more great products.

The Problem

Engineering can, and should, be simpler.

Here is the specific way it stops being simple: A team grows. Repositories multiply. The way you build, the standards, the conventions, the lessons you paid for in outages, ends up living in three places at once: in a few senior people's heads, in a wiki nobody opens, and, in theory, in the code itself. The moment you look away, those three drift apart.

What is left is a gap between how you think your teams build and how they actually build. Nobody is at fault. Everyone is busy shipping. But the gap is where the pain hides: the forced migration nobody saw coming, the service with no owner, the best practice we all agreed on that only half the repos ever adopted. And when someone asks a simple question, are we consistent, are we current, the honest answer is "we would have to go check, repo by repo."

GitGrit is my attempt to close that gap: to spread engineering knowledge across an organization, make technical complexity visible, and give leaders an honest answer at any moment, without turning their engineers into a compliance chore.

The Solution

As promised, an engineering standards platform - It is a single place that knows every standard you care about, checks them against every repository you own, continuously, and tells you at any moment exactly where you stand. Not a document describing how you would like to build. A living system that watches how you actually build, and closes the gap between the two.

GitGrit is fundamentally built on your git repositories. Why? because anything related to your production code should exist in a git repository (or other version control systems). Modern DevOps practices also dictate the use of IaC tools and the GitOps method. That means that your infra setup should exist in a git repository as well.

How it actually works, and this is the whole model:

1. Connect your Git host. GitHub, GitLab. GitGrit watches the repos you point it at and notices every time one changes.
2. Add projects, group them into stacks. A stack is just the set of repos that make up one real application: your microservices, your app together with its infrastructure. It is how you already think about your systems, so it is how GitGrit organizes them.
3. Define your standards as policies. Install them from the marketplace, or write your own.
4. That is it. Now you have a live view. Every push, pull request, and tag checks the repo again against your standards. At any moment you can see where each project stands, and why.

Policies In Detail

How They Are Built

A policy is just a Python function. It receives a Project context, the files, the languages, the members, branch protection settings, commit history, and returns pass or fail, with a message and a score. That is the whole contract. No DSL, no config language, no plugin API. If you can write a Python if, you can write a policy. And because it is real code, there is no ceiling on what a standard can be. You express it the way you would explain it to a new hire, and then it runs itself, forever.

Here is one I learned the hard way. It is 2am, production is down, and the fix is a one line change. You go to ship it and find the service is pinned to a Python version that went end of life months ago. The patch you need depends on something that version cannot run, so now you are doing an unplanned runtime upgrade in the middle of an incident, at the worst possible time to do it. The policy that prevents this is boring and about ten lines long: read the Python version the repo declares, compare it against the known end of life dates, fail if it is past. It ships with the real end of life dates built in. The upgrade never gets scheduled until it hurts. This just moves the hurt to a Tuesday afternoon instead of 2am.

Using LLMs

Here is where it gets interesting. Because a policy is just code, a policy can call a language model. That opens up a whole class of standards that were impossible to check before: the subjective ones. A linter can tell you a README exists. It cannot tell you it is any good.

A policy that hands the file to an LLM can: does this README actually explain how to run the project, or is it a title and a TODO? The model runs inside the same sandbox, you bring your own key and model, and its verdict comes back as pass or fail like any other check. This is the part I am most excited about. It is the jump from "does it exist" to "is it any good", which is the whole difference between a checklist and a standard.

Here is a higher stakes one. AI assistants are brilliant at generating a LICENSE file, and also brilliant at stitching together fragments of licenses that were never meant to sit together: an MIT header over a block of GPL text, a copyright line naming a company nobody at yours has ever heard of. To a human skimming a pull request it still looks like a license. Legally it can be a landmine, and license problems tend to surface during an acquisition or a funding round, again at the worst possible moment. No linter flags this, because nothing is syntactically wrong. An LLM policy can: hand it the LICENSE file and ask, is this one coherent, real license, or a Frankenstein of several stitched together? That is the difference between checking a box and actually protecting the company.

Architecture Map

There is one more piece that is not about pass or fail at all. Once GitGrit knows your projects and how you have grouped them into stacks, it draws them: an automatically generated map of your systems, how they depend on each other, and where they reach out to external services. It regenerates as your repos change, so it never goes stale the way the architecture diagram in a slide deck always does. This is the "map technical complexity" part: the picture a new hire wishes existed on day one, and the one a leader needs before deciding where to invest.

Haven't we solved this already?

If you have been doing this a while, you are already thinking of the usual answers. I tried all of them. Here is why each one leaks, and what GitGrit does instead.

Project templates.

You spin up a golden template so every new repo starts right. Great on day one. But a template only applies at creation. Update it later and nothing flows back to the repos already out there, and they start drifting immediately. GitGrit is living: it checks every repo on every change, not once at birth.

Uniform CI/CD pipelines.

You push the standard into a shared pipeline. Now it is real, but it is also buried in YAML across dozens of repos, invisible unless you go digging, and painful to change everywhere at once. GitGrit is visible: one dashboard shows where every repo stands, and the standard lives in one place instead of scattered through pipeline files.

Wikis and docs.

You write it all down. Nobody reads it, it is hard to keep accurate, and it can never tell you the actual status right now. GitGrit is executable: the standard is code that runs itself, so "are we following it" is always a live answer, not an archaeology project.

Linters and security scanners.

These are great, and GitGrit does not replace them. But they work one repo at a time, and they only check what is mechanically present. They cannot tell you which of your two hundred repos even has a linter configured, and they cannot judge whether something is any good. GitGrit works across the whole fleet, checks that those tools are even in place, and with LLM policies can grade quality, not just existence.

If you have read this far, thank you. GitGrit is open source under MIT. You can host it yourself anywhere, or use the hosted version at app.gitgrit.dev.

⭐ Star it on GitHub
🐛 Open an issue: a policy you wish existed, a standard you cannot currently express, a rough edge. I read every one.
✉️ Or just reach out. I built this because it is close to my heart, and I would love to hear how you keep your standards from rotting.

This is early, and it is built in the open, on purpose. Come build it with me.

Next.js, NestJS, MobX and how I structured my open-source project

Kfir Zvi — Fri, 17 Sep 2021 22:29:02 +0000

This is part of a series of articles about my open-source project (backend and frontend). if you want to join me feel free to contact me at - zvikfir10@gmail.com.

Introduction

Recently, I have re-started working on an open source project I came up with last year, called MyWay (it is named after my and my dog trainer girlfriend's dog "Maui"). This project aims to serve as a Customer Management System (CMS) platform for dog trainers, helping them to keep track of their work with each customer, including abilities such as sending a summary of the last session directly to the customer, or plan the progress that needs to be made along the training sessions in a chart that is easy to use and read.

In the beginning, I started the project with the technologies I knew back then, which were React, Express over Node, and MongoDB (it is worth mentioning that I didn't have a lot of experience with full-stack, and most of what I knew were from the freeCodeCamp courses I took on my free time). These worked great for me last year as I worked on the project for a few weeks. However, this time, when I tried to keep using them I felt a lot of discomfort. I felt that for a large portion of my code - I don't really know if it works, or how well it works.

I tried to take inspiration from several template projects I found on Github, but it was hard for me since each such template took its own approach into doing things. I personally needed to have a framework that would dictate a project structure and layout.

I consulted an open source community Facebook group named "Pull Request", and I was recommended to use NestJS. At first, it was really hard for me to get used to a whole new framework, which is written in Typescript rather than Javascript (although it is possible to use it with JS), and contains a whole new set of classes, objects, and methodologies. Nonetheless, it felt like the right thing to do, as Nest helps to keep your code organized, and much less error-prone.

I tried to find a similar solution to the front-end part, and eventually I chose Next.JS. It mainly provides the ability to pre-render, but I liked that it contained a special pages directory which automatically created routes according to the file's name. However, NextJS does not provide a clear project structure and it still gives much freedom to each developer, which didn't fit for me.

I wound up combining several ideas (the main ones were taken from this post covering the use of MobX with React hooks, and from this GitHub project taken from Ariel Weinberger's excellent Udemy course covering NestJS) into what I think is a good project structure, and this is what I'm going to cover in this post.

The Proposed Structure

The structure I will cover here uses MobX, a very popular state management library. Although MobX is not an essential part and you can achieve a similar solution without using it, I think it is of great value and that's why I included it.
MobX is used to provide all the components in our app with an instance of the RootStore. The RootStore is a class that creates all the services your app requires, as well as all the stores. While creating each store, the RootStore makes sure to provide an instance of itself, so that each store will be able to access other stores, and an instance of the its dependent services.

Before I explain each step in detail, you can view almost all the relevant changes I have made in the MyWay project in this commit.

First of all, create three folders: services, stores, and dto. In the stores folder, create a file named stores/index.ts and in it create the RootStore class:

stores/index.ts

export class RootStore {
  constructor() {
    const authService = new AuthService();

    this.userStore = new UserStore(this, authService);
  }
}

export const StoresContext = createContext(new RootStore());
export const useStores = () => useContext(StoresContext);

This code presents how you can create services in the RootStore constructor so that each of this services will be a Singleton, since they are created only once, and create all the needed stores in your application. In this example we have the AuthService and the UserStore. The AuthService will contain logic related to authentication, such as login, register, and logout. The UserStore is a store that contains information about the user in the application, and it might want to save the user information once it is logging into its account, so that all the components in the system can use it.

As mentioned, note that each store is given the RootStore instance (this), and the services it requires.

Another important part of that code is how we expose it to all of the components in our app. To do so, we make use of React's context. We first use createContext to create a context containing the RootStore instance, and then we export a useStores function that will easily allow us to use the context created.

Next up, let's create the AuthService class.

We will most likely have many services in our app. To simplify their creation, we'll create a base class from which they will inherit. This base class will abstract the use of http libraries such as the built-in fetch or axios. This way, should the need to switch to a more modern library arises, you can do so easily (you can read a more detailed explanation here).

Create a file named services/base-http.service.ts:

services/base-http.service.ts

import axios, { AxiosError, AxiosRequestConfig, AxiosResponse } from "axios";
import Router from "next/router";
import { APIErrorResponse } from "../dto/api/api-error-response";
import { APIResponse } from "../dto/api/api-response";

// Taken from https://github.com/arielweinberger/task-management-frontend/blob/master/src/services/base-http.service.js

export default class BaseHttpService {
  BASE_URL = process.env.BASE_URL || "http://localhost:3000";
  //   _accessToken: string = null;

  async get<T = any>(
    endpoint: string,
    options: AxiosRequestConfig = {}
  ): Promise<T | void> {
    Object.assign(options, this._getCommonOptions());
    return axios
      .get<APIResponse<T>>(`${this.BASE_URL}${endpoint}`, options)
      .then((res: AxiosResponse<APIResponse<T>>) => res.data.data)
      .catch((error: AxiosError<APIErrorResponse>) =>
        this._handleHttpError(error)
      );
  }

  async post<T = any>(
    endpoint: string,
    data: any = {},
    options: AxiosRequestConfig = {}
  ): Promise<T | void> {
    Object.assign(options, this._getCommonOptions());
    return axios
      .post<APIResponse<T>>(`${this.BASE_URL}${endpoint}`, data, options)
      .then((res: AxiosResponse<APIResponse<T>>) => res.data.data)
      .catch((error: AxiosError<APIErrorResponse>) =>
        this._handleHttpError(error)
      );
  }

  async delete<T = any>(
    endpoint: string,
    options: AxiosRequestConfig = {}
  ): Promise<T | void> {
    Object.assign(options, this._getCommonOptions());
    return axios
      .delete<APIResponse<T>>(`${this.BASE_URL}${endpoint}`, options)
      .then((res: AxiosResponse<APIResponse<T>>) => res.data.data)
      .catch((error: AxiosError<APIErrorResponse>) =>
        this._handleHttpError(error)
      );
  }

  async patch<T = any>(
    endpoint: string,
    data: any = {},
    options: AxiosRequestConfig = {}
  ): Promise<T | void> {
    Object.assign(options, this._getCommonOptions());
    return axios
      .patch<APIResponse<T>>(`${this.BASE_URL}${endpoint}`, data, options)
      .then((res: AxiosResponse<APIResponse<T>>) => res.data.data)
      .catch((error: AxiosError<APIErrorResponse>) =>
        this._handleHttpError(error)
      );
  }

  _handleHttpError(error: AxiosError<APIErrorResponse>) {
    if (error?.response?.data) {
      const { statusCode } = error?.response?.data;

      const requestUrl = error.response?.config.url;

      if (
        statusCode !== 401 ||
        requestUrl?.endsWith("/api/auth/login") ||
        requestUrl?.endsWith("/api/auth/register")
      ) {
        throw error.response.data;
      } else {
        return this._handle401(error);
      }
    } else {
      throw error;
    }
  }

  _handle401(error: AxiosError<APIErrorResponse>) {
    this.get("/api/auth/refresh")
      .then(() => axios.request(error.config))
      .catch((e) => Router.push("/login"));
  }

  _getCommonOptions() {
    // const token = this.loadToken();

    // return {
    //   headers: {
    //     Authorization: `Bearer ${token}`,
    //   },
    // };
    return {};
  }

  //   get accessToken() {
  //     return this._accessToken ? this._accessToken : this.loadToken();
  //   }

  //   saveToken(accessToken : string) {
  //     this._accessToken = accessToken;
  //     return localStorage.setItem("accessToken", accessToken);
  //   }

  //   loadToken() {
  //     const token : string = localStorage.getItem("accessToken") as string;
  //     this._accessToken = token;
  //     return token;
  //   }

  //   removeToken() {
  //     localStorage.removeItem("accessToken");
  //   }
}

In this class, we expose the basic functions that are used in any http library: get, post, put, patch, and delete. In each function, we simply call the http library we would like to use. In this case, it is axios. You can easily use any other library you would like.

Since we are using NestJS, our API usually has a uniform response structure. We make sure to import and use the relevant interfaces so programmers who read our code can understand it more easily:

dto/api/api-response.ts

export interface APIResponse<T> {
  data: T;
}

dto/api/api-error-response.ts

export interface APIErrorResponse {
  statusCode: number;
  message: string;
  error?: string;
}

Another benefit we have from using this base class for our services is the ability to catch errors on any request sent in our application, and to apply a certain logic to it. For example, in case of authentication we might want to intercept any error with a status code of 401. In MyWay, I implemented the authentication with a JWT access token and a refresh token that are saved as cookies, so if I get a 401 response, I want to try to use my refresh token to get a new access token. You can see the logic applied in the _handle401 function. In addition, you can see in the commented code how to implement a strategy which saves the tokens in local storage.

Once we have this base class set up, we can now create the authentication service class:

services/auth.service.ts

import { LoginDto } from "../dto/auth/login.dto";
import { RegisterDto } from "../dto/auth/register.dto";
import { SessionUserDto } from "../dto/auth/session-user.dto";
import BaseHttpService from "./base-http.service";

export default class AuthService extends BaseHttpService {
  async login(loginDto: LoginDto): Promise<SessionUserDto> {
    return (await this.post<SessionUserDto>(
      "/api/auth/login",
      loginDto
    )) as SessionUserDto;
  }

  async register(registerDto: RegisterDto): Promise<void> {
    return await this.post("/api/auth/register", registerDto);
  }
}

This code is quite self explanatory, so we'll move right to creating our UserStore class.

stores/user.store.ts

import { makeAutoObservable } from "mobx";
import { RootStore } from ".";
import { LoginDto } from "../dto/auth/login.dto";
import { RegisterDto } from "../dto/auth/register.dto";
import { SessionUserDto } from "../dto/auth/session-user.dto";
import AuthService from "../services/auth.service";

export default class UserStore {
  user: SessionUserDto | null;

  constructor(
    private readonly rootStore: RootStore,
    private readonly authService: AuthService
  ) {
    this.user = null;
    makeAutoObservable(this);
  }

  async login(loginDto: LoginDto): Promise<void> {
    this.user = await this.authService.login(loginDto);
  }

  async register(registerDto: RegisterDto): Promise<void> {
    await this.authService.register(registerDto);
    const { email, password } = registerDto;
    const loginDto: LoginDto = { email, password };
    this.user = await this.authService.login(loginDto);
  }
}

In each store, we can create the state that we would like to expose to components which use it. In this case, the state contains the user which is currently logged in. You can also see how decoupling the logic from the components helps us to avoid code duplication: in the register function, instead of re-writing the same logic of sending an API call to the server, and handling the possible errors all over again, we simply use the login function which is already in the same store. In addition, in case we wanted to use some logic from another store, we would simply do so like this:

this.rootStore.someOtherStore.someFunction();

Remember that through the rootStore field we can access all the other stores in our application.

Now that this is covered, let's see how we use the stores and services we created in our components. Let's take the LoginForm component as an example:

components/auth/login.form.component.tsx

...
 import { useStores } from "../../stores";
 import { APIErrorResponse } from "../../dto/api/api-error-response";
import { observer } from "mobx-react-lite";

 const LoginForm = observer(function LoginForm() {
   const { userStore } = useStores();

   return (
     <Formik
       initialValues={{
         email: "",
         password: "",
       }}
       onSubmit={(values, { setSubmitting, setStatus }) => {
         userStore
           .login(values)
           .then(() => {
             setStatus({ message: "You have logged in successfully." });
             setTimeout(() => Router.push("/"), 2000);
           })
           .catch((e: APIErrorResponse) => {
             setStatus({ error: e.message });
           })
           .finally(() => setSubmitting(false));
       }}
...

export default LoginForm;

The only change we have made is to declare a userStore variable taken from the useStores() function call. With this store, we can use all the functions it exposes, as well as read its state like this:

const { user } = userStore;

That's it!

We have managed to create a service oriented project structure that can help us maintain organization in our project, separating logic and state from our components, so they can take care of only the view layer, avoid code duplication, and help us avoid runtime errors.

This project is still a work in progress, so you can see in later commits examples of more services and stores.

I hope that this post has been somewhat helpful to you, and feel free to leave some feedback. I'd love to hear from you.

I'd like to thank Shmuel Shoshtari for both motivating me to write this post, and for valuable feedback regarding this post and the project.