DEV Community: Kanstantsin

Building Solo: Errors

Kanstantsin — Fri, 30 May 2025 18:05:52 +0000

Introduction

In Part 2, I wrote about how I implemented authentication, next, I want to discuss errors, a rather ambiguous topic, especially challenging when the backend and frontend are developed separately. However, I already had my own plan and vision for how to implement this to make it as convenient as possible on both sides. The advantage is that I'm working alone and don't need to convince anyone else. So, let's begin.

The main issue is that some developers rely on status codes, while others always return a 200 code with is_success: true/false and include the error text in the body. I don't particularly like either approach because, over time, it all turns into spaghetti code, especially in large projects. The essence of the idea is to have an enum on the backend that clearly indicates the type of error, so there's no need to look at the status or message. If desired, everything can be tied to the backend and take a step towards Backend-Driven UI, but I decided to do it a bit differently: only the type is on the backend, while the frontend maps error types to specific classes with messages and other information.

Backend (FastAPI)

Often, the code looks like this:

@auth_router.post(
 "/register",
   auth_required=False,
   status_code=status.HTTP_201_CREATED,
   description="API endpoint for user registration",
   response_model=UserData,
)
async def register(
   data: UserCreateSchema,
   auth_controller: AuthController = Depends(get_auth_controller),
   settings: AppSettings = Depends(get_settings),
) -> JSONResponse:
   logger.info(f"Register customer {data.email}")
   try:
       result = await auth_controller.register(data)
   except CustomException_1 as exc:
       ...
   except CustomException_2 as exc:
       ...
   except CustomException_N as exc:
       ...

This leads to a long list of exceptions and corresponding status codes and messages. The drawbacks are evident.
FastAPI allows for a well-structured error architecture using exception handlers. My proposal is to define error types and a base class that stores the desired status code to return to the client.
Error Type

class ErrorType(StrEnum):
   unauthorized = "unauthorized"
   bad_request = "bad_request"
   user_exists = "user_exists"
   forbidden = "forbidden"

Error Class

class ApplicationError(Exception):
   message: str
   code: int
   error_type: ErrorType


   def __init__(self, message: Optional[str]):
       self.message = message or self.message


   @property
   def text(self) -> str:
       return self.message

We can then declare an exception handler:

async def application_error_handler(
   req: Request, exc: ApplicationError
) -> JSONResponse:
   logger.error(f"Application error - msg={exc.text}, type={exc.error_type}")
   return JSONResponse(
       {"detail": exc.text, "error_type": exc.error_type},
       status_code=exc.code,
       headers={REQUEST_UID: get_request_id()},
   )

And add it during application initialization:

def init_exc_handlers(application: FastAPI) -> None:
   application.add_exception_handler(ApplicationError, application_error_handler)

This setup allows us to declare any error types, raise them at various levels of the application (be it RepositoryError, ServiceError), and eliminates boilerplate in handlers. Additionally, we can configure alerting in Slack/Telegram within this handler.
Now it looks like that:

@auth_router.post(
 "/register",
   auth_required=False,
   status_code=status.HTTP_201_CREATED,
   description="API endpoint for user registration",
   response_model=UserData,
)
async def register(
   data: UserCreateSchema,
   auth_controller: AuthController = Depends(get_auth_controller),
   settings: AppSettings = Depends(get_settings),
) -> JSONResponse:
   logger.info(f"Register customer {data.email}")
   return await auth_controller.register(data)

Frontend(NextJS)

As an advocate of OOP, I wanted a base error class and a client class to handle errors. Since I decided to keep some logic on the frontend, it's necessary to process the errors defined on the backend.

We declare error types:

export type ErrorTypes =
   | "unauthorized"
   | "bad_request"
   | "forbidden"
   | "not_found"
   | "invalid_credentials"

Error Class

export interface ApiError {
   message: string;
   code: number;
   error_type: ErrorTypes;
}

API Client

export class ApiClient {
  private client: AxiosInstance;

  constructor() {
    this.client = axios.create({
      baseURL: API_URL,
      paramsSerializer: { indexes: null },
    });
    this.client.defaults.headers.post["Content-Type"] = "application/json";
    this.client.defaults.withCredentials = true;
    this.client.defaults.maxRedirects = 1;
  }

  private async callApi(method: Method, url: string, requestData?: any, params?: any): Promise<AxiosResponse> {
    try {
      return await this.client.request({ method, url, data: requestData, params });
    } catch (error) {
      if (isAxiosError(error)) {
        const errorCode = error.response?.status || 500;
        const errorMessage = error.response?.data?.detail || "An error occurred";
        const error_type = error.response?.data?.error_type || "unknown";
        throw {
          message: errorMessage,
          code: errorCode,
          error_type,
        } as ApiError;
      }
      throw {
        message: `Unexpected error: ${error}`,
        code: 500,
        error_type: "unknown",
      } as ApiError;
    }
  }

  public async registerUser(data: UserCreateSchema): Promise<UserData> {
    const response = await this.callApi("POST", "/register", data);
    return response.data;
  }
}

Next, we'll map and implement errors based on their types. I chose to display errors in a modal window, which I find most convenient. Of course, I'm not a UX expert, so this is based solely on my experience. I divided all errors into two types: common ones, where the user can only close the window, and those that allow the user to take some action—renew a subscription, navigate to another page, etc. This approach seems to ease the user's experience, reducing the time/actions needed to correct an error.

Implementation for common errors:

import Button from "@/src/components/shared/Button";
import { Dialog, DialogBackdrop, DialogPanel, DialogTitle } from "@headlessui/react";
import { ExclamationCircleIcon, XMarkIcon } from "@heroicons/react/24/outline";
import React from "react";

export interface DefaultProps {
   message: string;
   title: string;
}

interface ModalError {
   isOpen: boolean;
   onClose: () => void;
}

class CommonError extends React.Component<ModalError> {
   protected defaultData: DefaultProps = { message: "", title: "" };


   render() {
      return (
         <Dialog
            open={this.props.isOpen}
            onClose={this.props.onClose}
            className="relative z-50 transition duration-300 ease-out data-[closed]:opacity-0"
            transition
         >
            <DialogBackdrop className="fixed inset-0 bg-black/30" />
            <div className="fixed inset-0 flex w-screen items-center justify-center">
               <DialogPanel className="w-5/6 md:w-3/6 lg:w-2/6 bg-white flex flex-col space-y-3 rounded-xl p-4 pb-5">
                  <DialogTitle className={"text-gray-600 "}>
                     <div className={"flex flex-col items-center"}>
                        <div className={"w-full flex justify-between items-center"}>
                           <p className={"font-bold font-display text-base px-2"}>{this.defaultData.title}</p>
                           <XMarkIcon className={"size-5 hover:opacity-75 hover:cursor-pointer"} onClick={this.props.onClose} />
                        </div>
                     </div>
                  </DialogTitle>
                  <div className={" flex-row flex text-gray-600 space-x-1 items-center py-2 px-3 bg-gray-100 rounded-xl"}>
                     <ExclamationCircleIcon className={"size-4"} />
                     <div className={"font-arimo text-sm "}>{this.defaultData.message}</div>
                  </div>
               </DialogPanel>
            </div>
         </Dialog>
      );
   }
}

Now we can define errors as classes:

export class BadRequestError extends CommonError {
   protected defaultData: DefaultProps = {
      title: "Bad Request",
      message: "The request was invalid. Please check and try again.",
   };
}


export class ForbiddenError extends CommonError {
   protected defaultData: DefaultProps = {
      title: "Access Denied",
      message: "You do not have permission to perform this action.",

Implementation for errors requiring action:

export interface DefaultActionProps extends DefaultProps {
   href: string;
   buttonText: string;
}

class ActionRequiredError extends CommonError {
   protected defaultData: DefaultActionProps = {
      message: "",
      title: "",
      href: "",
      buttonText: "",
   };
   render() {
      return (
         <Dialog
            open={this.props.isOpen}
            onClose={this.props.onClose}
            className="relative z-50 transition duration-300 ease-out data-[closed]:opacity-0"
            transition
         >
            <DialogBackdrop className="fixed inset-0 bg-black/30" />
            <div className="fixed inset-0 flex w-screen items-center justify-center">
               <DialogPanel className="w-1/4 bg-white flex flex-col space-y-3 rounded-xl p-4 pb-5">
                  <DialogTitle className={"text-gray-600 "}>
                     <div className={"flex flex-col items-center"}>
                        <div className={"w-full flex justify-between items-center"}>
                           <p className={"font-bold font-display text-base px-2"}>{this.defaultData.title}</p>
                           <XMarkIcon className={"size-5 hover:opacity-75 hover:cursor-pointer"} onClick={this.props.onClose} />
                        </div>
                     </div>
                  </DialogTitle>
                  <div className={" flex-row flex text-gray-600 space-x-1 items-center py-2 px-3  rounded-xl"}>
                     <ExclamationCircleIcon className={"size-4"} />
                     <div className={"font-arimo text-sm"}>{this.defaultData.message}</div>
                  </div>
                  <div className={"w-full py-1"}>
                     <Button className={"w-full rounded-xl"} href={this.defaultData.href} color={"sky"}>
                        {this.defaultData.buttonText}
                     </Button>
                  </div>
               </DialogPanel>
            </div>
         </Dialog>
      );
   }
}

export class SubscriptionError extends ActionRequiredError {
    protected defaultData: DefaultActionProps = {
        title: "Action is Not Allowed",
        message: "You don't have an active subscription.",
        href: "/prices",
        buttonText: "Subscribe",
    };
}

I map error types to their corresponding UI classes using a factory:

type ErrorType = typeof CommonError;


class ErrorFactory {
   private static errorMapping: Record<ErrorTypes, ErrorType> = {
      unauthorized: UnauthorizedError,
      bad_request: BadRequestError,
      forbidden: ForbiddenError,
      not_found: NotFoundError,
      ...
   };


   protected static getError(errorType: ErrorTypes): ErrorType {
      return this.errorMapping[errorType] || UnknownError;
   }
   public static getErrorComponent(errorType: ErrorTypes, isOpen: boolean, onClose: () => void): React.JSX.Element {
      const Error = this.getError(errorType);
      return <Error onClose={onClose} isOpen={isOpen} />;
   }
}

export default ErrorFactory;

Here’s how it integrates into a real form:

const AuthForm = () => {
  const [error, setError] = useState<ApiError | null>(null);
  const [openError, setOpenError] = useState<boolean>(false);

  const onSignUp: SubmitHandler<LoginSchema> = async (data) => {
    try {
      await backendClient.loginUser(data);
    } catch (error) {
      setError(error as ApiError);
      setOpenError(true);
    }
  };

  return (
    <form onSubmit={handleSubmit(onSignUp)}>
      {error &&
        ErrorFactory.getErrorComponent(error.error_type, openError, () => {
          setOpenError(false);
        })}
      ...
    </form>
  );
};

How it looks like:

Final Thoughts

This error-handling architecture strikes a solid balance between structure, flexibility, and UX. While not without trade-offs, it’s proven scalable and productive for a solo developer environment or small teams.

✅ Pros

Clear Error Typing. (Enums ensure consistent, predictable error handling across the app)
Frontend Ownership of UX (Full control over how each error is presented and localized)
Extensible with OOP. (Easy to add new error types via class inheritance and centralized mapping)
Centralized Backend Handling. (One exception handler for all application errors, reducing duplication and adding observability hooks (like Slack alerts))

⚠️ Cons

Manual Sync Between Frontend/Backend. (Error types must be updated in both codebases unless automated).
Tied to Class-Based Components. (Modals are built with class components, which may limit future React upgrades or hook integrations)

From Prompt Chaos to Presets

Kanstantsin — Thu, 22 May 2025 08:32:00 +0000

InkLytic was created as an AI Content Lab to solve a specific problem: the endless loop of prompt tweaking in modern LLM-driven content creation.

Prompt engineering works — until it has to scale. A single prompt might produce decent output for a blog post, but when the format changes, or the tone needs adjustment, or the audience shifts, the process starts over: rephrase, test, tweak.
What begins as a productivity boost turns into a bottleneck.

The Problem: Prompt Engineering Doesn’t Scale

Here’s a typical example from early experimentation:

Write a short and engaging social media post about Lionel Messi’s recent goal in the MLS. Use an excited and informal tone. Add a light-hearted emoji or two. The message should be no more than 280 characters. End with a question to encourage comments from fans.

It works — once, but then comes the need for a shorter version, more formal version for Facebook, an adaptation for a newsletter or a completely different use case.
Each variation requires rewriting or heavy editing. Multiply that across content formats and use cases, and it becomes clear: prompt engineering is not sustainable for teams or individuals trying to move fast and stay consistent.

Dynamic Presets: The Foundation of a Structured Prompt System

To solve this, InkLytic was built around dynamic presets — a modular input system designed to streamline AI-powered content workflows.
Instead of crafting detailed prompts manually, users define intent and structure using presets:

Tone: casual, formal, neutral
Length: short, medium, long
Audience: general readers, experts, internal teams
Intent: inform, inspire, sell, instruct
Format: markdown, plain text
Complexity: basic, advanced, intermediate

Each preset shapes the final prompt behind the scenes, instead of writing from scratch every time, users select presets and InkLytic builds the right prompt behind the scenes.

Content Categories Add Context

For sure presets alone aren’t enough. Writing an email is different from writing a blog post, even with the same tone or length. So we added another structural layer: content categories.
We decided to start from this:

Blog Content
Ad Copy
Email Content
Social Media Posts
Product Descriptions
Guides and Tutorials
Storytelling
Text Editing
General Use

Each category carries specific logic and preset defaults that match real-world use cases, e.g “Formal + Inform + Email” is very different from “Neutral + Inspire + Blog” and the system handles that without user micromanagement.
This makes the process accessible to non-technical users while keeping structure and intent intact.

Model-Agnostic by Design

LLMs evolve quickly, and locking into a single model or provider would create unnecessary limitations. With more models available, users can compare results and choose the one that best fits their specific needs. Every provider is optimizing their models to stand out in the market — so as users, we benefit the most when we can take advantage of their strengths, not stay tied to just one.

What’s Next

InkLytic is still in active development, but it already handles content creation tasks that used to require endless tweaking and prompt crafting. The results are more consistent, and the process is faster — even across different content formats.
It is not just a tool — it’s a structured approach to AI-powered content workflows.

In upcoming posts, we’ll share more about:

How we defined the preset system
How we structured the content categories to reduce confusion and support real use cases

If you’ve ever spent too much time rewriting prompts for similar tasks, we think you’ll find something familiar here — and maybe something useful.

— The InkLytic team

Want a closer look at the structure?
👉 Explore the live demo.

First Step Building Solo: Authentication

Kanstantsin — Tue, 20 May 2025 09:36:23 +0000

In Part 1, I wrote about how I transitioned from working with a team to building solo. Once I made that decision, I needed to start somewhere - and for me, that was authentication.

This post covers how I approached it using FastAPI, why I avoided localStorage, and how I made authentication declarative with a custom router.

There are many ways to handle authentication, but I chose the most popular and relatively reliable approach: JWT auth. The spec generally assumes two endpoints:

One to get an access + refresh token
One to get a new access token if the previous one has expired

The client needs to store these tokens somewhere and send them with each request—usually in headers. They're often stored in localStorage, which isn’t very secure.

But I wasn’t as concerned with security (this isn’t a banking app) as I was with client-side friction. So I decided: let’s store everything in cookies, and have the backend manage all the token logic.

The client doesn’t need to know anything about tokens

The frontend code is super simple, I use axios:

export class ApiClient implements BackendClient {
  private client: AxiosInstance;

  constructor() {
    this.client = axios.create({
      baseURL: API_URL,
      paramsSerializer: {
        indexes: null,
      },
    });
    this.client.defaults.headers.post["Content-Type"] = "application/json";
    this.client.defaults.withCredentials = true;
    this.client.defaults.maxRedirects = 1;
  }
}

All you need is withCredentials = true.

Cookies have CORS restrictions
Different domains can cause trouble
You'll likely need CSRF protection
The backend implementation becomes more involved

My main programming language is Python, so I chose FastAPI. The good (or bad) news is—it doesn't include built-in authentication.
I didn’t want to use third-party libraries either—they're often poorly maintained and cause more problems than they solve.

You can use FastAPI’s Depends and add middleware to specific routers, but:

It locks down all endpoints in that router
It's not very flexible or intuitive when you need fine-grained control

I also wanted a declarative syntax, so I could explicitly say whether an endpoint requires authentication or not.
That’s why I decided to modify the API Router slightly to implement what I had in mind.

I needed a middleware that:

Parses tokens from the request
Validates them
Issues a new access token if needed
Verifies that the user exists
Attaches the user’s info to the request state

Usage example:

@users_router.get("/subscription_info", auth_required=True)
async def get_subscription_info(
    user: User = Depends(get_user),
    sub_service: SubscriptionService = Depends(get_subscription_service),
):
    ...

Here's what the middleware looks like:

class AuthMiddleware(BaseHTTPMiddleware):
    settings: AuthSettings
    _routes: List[CustomRoute]

    def __init__(self, app: ASGIApp, settings: AuthSettings, routes: List[HarmoniAIRoute]):
        super().__init__(app)
        self.settings = settings
        self.app = app
        self._routes = routes

    async def dispatch(self, request: Request, call_next: RequestResponseEndpoint) -> Response:
        for route in self._routes:
            # Skip non-API paths
            if not request.url.path.startswith("/api/v1"):
                return await call_next(request)

            # Strip prefix to compare route pattern
            prefix, path = request.url.path.split("/api/v1")

            if route.path_regex.match(path) and route.auth_required:
                service = AuthService(self.settings)

                # Extract tokens from cookies
                access, refresh = self.get_tokens(request)

                if not refresh:
                    # No refresh token, reject request
                    return JSONResponse(
                        status_code=401,
                        content={
                            "detail": "Unauthorized",
                            "error_type": ErrorType.unauthorized,
                        },
                    )

                # Authenticate and refresh tokens if needed
                auth_result = await service.authenticate(access, refresh)
                # This checks token validity, fetches the user,
                # and optionally issues a new access token

                # Attach user info to request state
                request.state.app_state.user = RequestUser(
                    user_id=auth_result.user_id,
                )

                # If token hasn't changed, continue
                if access == auth_result.access:
                    return await call_next(request)

                # Otherwise, update access token in response cookie
                response = await call_next(request)
                response.set_cookie(
                    key=TokenTypes.ACCESS,
                    value=auth_result.access,
                    httponly=True,
                    expires=self.settings.authentication.access_token_expires,
                    secure=self.settings.authentication.secure,
                )
                return response

        # If no auth required or no route match
        return await call_next(request)

    @staticmethod
    def get_tokens(request: Request) -> Tuple[str | None, str | None]:
        token = request.cookies.get(TokenTypes.ACCESS)
        refresh_token = request.cookies.get(TokenTypes.REFRESH)
        return token, refresh_token

Custom Route:

class CustomRoute(APIRoute):   
    auth_required: bool

    def __init__(self, path: str, endpoint: Callable[..., Any], *, auth_required: bool = False, **kwargs):
        super().__init__(path, endpoint, **kwargs)
        self.auth_required = auth_required

    def __repr__(self) -> str:
        class_name = self.__class__.__name__
        methods = sorted(self.methods or [])
        return f"{class_name}(path={self.path!r}, name={self.name!r}, methods={methods!r}, auth_required={self.auth_required!r})"

Custom Router:

class CustomRouter(APIRouter):
    routes: list[BaseRoute]

    def __init__(self, *args, **kwargs) -> None:
        super().__init__(*args, **kwargs)
        self.route_class = CustomRoute

    def __iter__(self):
        return self.routes.__iter__()

    def put(self, path: str, *, auth_required: bool = True, **kwargs):
        return self.api_route(path=path, auth_required=auth_required, methods=["PUT"], **kwargs)

    def delete(self, path: str, *, auth_required: bool = True, **kwargs):
        return self.api_route(path=path, auth_required=auth_required, methods=["DELETE"], **kwargs)

    def patch(self, path: str, *, auth_required: bool = True, **kwargs):
        return self.api_route(path=path, auth_required=auth_required, methods=["PATCH"], **kwargs)

    def get(self, path: str, *, auth_required: bool = True, **kwargs):
        return self.api_route(path=path, auth_required=auth_required, methods=["GET"], **kwargs)

    def post(self, path: str, *, auth_required: bool = True, **kwargs):
        return self.api_route(path=path, auth_required=auth_required, methods=["POST"], **kwargs)

    def api_route(self, path: str, *, auth_required: bool = True, **kwargs):
        ...

    def add_api_route(self, path: str, endpoint: Callable[..., Any], *, auth_required: bool = False, **kwargs):
        ...

    def include_router(self, router: Union["APIRouter", "CustomRouter"], *, **kwargs):
        ...

Yes, I had to pass a new parameter (auth_required) through several layers. And yes, there’s some duplication. But the result is:

Transparent token management
Zero frontend token logic
Full backend control
Clean, declarative route configuration

Final Thoughts

Handling authentication myself gave me more control, forced me to think through the user flow, and set the tone for how I want the rest of the system to work: clean, minimal, and backend-driven.

There’s probably a cleaner way to do parts of this. I might revisit it later. But for now, it works, and it keeps the frontend lightweight.

From Idea to Reality: Why I Stopped Waiting — and Started Building Solo

Kanstantsin — Mon, 19 May 2025 07:40:00 +0000

My Journey

Like many developers, I’ve had more side projects die than succeed, but one of them changed my approach entirely. In this series, I'll share my story of how a personal project, initially started as a learning experience, transformed into a small startup idea.

I've always been fascinated by the concept of Profi.ru, a platform that connects customers with local service providers. When I moved to the Netherlands in 2022, I saw an opportunity to create something similar. I conducted some research, created a survey, and even assembled a team of friends to help me with the project. We had a backend developer, a frontend developer, and I was handling the overall architecture. But, as it often does, life got in the way, and our collective motivation began to wane.

After building user and service provider registration systems and implementing multilingual support, momentum started dying out. Some struggled without mockups, while others found more pressing matters to attend to. It was a hard lesson to learn, but I realized that I couldn't rely on others to drive my project forward.

Lesson Learned

What did I take away from this experience? Should I become a better motivator? Find more reliable partners? No. I realized a simple truth: if you want to see an idea through, be prepared to carry it yourself.

This reminded me of "Naruto." In the series Indra relied on talent, Asura on teamwork. I realized that in real life, motivation rarely scales - so Indra usually wins..

Around then, ChatGPT appeared. I already knew a bit of React (I once tried building a poker web site). But I was still coding into the void, I decided to eliminate my weakest link - frontend development. Without illusions: my knowledge was limited to the boundaries of my previous projects. The next project, I would write entirely by myself.

In the next parts, I’ll share how I turned that solo project into something concrete and where I hit my next wall.