Forem: Sebastian Pavel

I was tired of arcane query syntax and tab switching, so I built Loguro

Sebastian Pavel — Sat, 28 Mar 2026 21:46:00 +0000

I personally had a pain point with logs. I never understood the complicated UIs, all the charts, all the metrics, everything the premium tools throw at you.

I still had to install an SDK. I still needed to learn some arcane query syntax just to filter logs. Debugging should be easy, we already break our heads writing code, making it understandable by others, dealing with deadlines. The last thing I want is to read docs when something breaks on my production, or worse, on a client's production.

That's why I built Loguro. My debugging partner should understand English — almost as if I was talking to myself.

level:error|critical message:"database timeout" @today
Simple, on point. No docs needed.

I don't like noise. I might have 1k logs from a single error — a lot of rows to scroll through. Loguro transforms repeated patterns into groups, so I see 1000x and can expand them directly.
I need to see how it happened. There are tools that replay UI interactions, but what about the backend? Server started hiccuping, then something else happened, then dead. Normally I end up hunting traces and timestamps across 10 tabs.

from:"1 hour ago" to:"5 minutes ago" --replay
Renders a widget, I watch my logs come back in sequence like a time machine. No tabs, no traces, just the story.

I have the error. I know how it happened. Now I need to create a task. Normally I open Jira or Linear, navigate to the right project, create the issue, switch tab, copy the log message, paste it as the title, go back for context, go back again, submit, copy the URL, open Slack, post to the team channel... you see where this is going.

--task:jira --send:slack#team
I add the relevant logs to context, hit the command or type it in the same query bar, press cmd+enter. That's it. Task created, Slack notified with the link and details. I can go to sleep.

And that log? It lives forever, even if the retention is 24 hours, a log that becomes a task never gets deleted.

Months have passed. I consider myself a decent developer, but that goddamn error is back, and it brought friends. Normally I go hunting. Search through thousands of issues, hope it sounds familiar, spend minutes or hours finding the first occurrence. Then switch back to the logging tool, compare, check if it's the same pattern, check if the old fix still applies...

In Loguro, when a log was tasked, it remembers. New logs matching the same pattern are automatically marked as "seen before." I click it, see the original task, the comments, the context, the smart dude who "fixed" it last time — and decide what to do next. No hunting, no tab switching, no déjà vu.

One more thing — as a good dev, I sometimes send logs with stringified JSON inside the message field. Perfectly normal, yea? Loguro handles it with --separate::message, pulls that JSON out of the message and puts it where it belongs, in the context. Clean log, no noise.

Everything is managed from a command palette — my account, billing, usage, API keys, notification channels and integrations. All of it, without touching the mouse.

Loguro is packed with a handful of features which I hope make it stand out and provide value on the already saturated market.

I would love some feedback — on the product, the landing page, and the docs. On the footer there's a link to the Discord server, I'm there if you need anything. And once inside the app, --feedback sends feedback directly from anywhere.

You can have a look too at loguro

How I Turned a Logging Dashboard into a Keyboard-First CLI-ish ⚡️

Sebastian Pavel — Tue, 10 Mar 2026 22:33:00 +0000

When building Loguro, I had a realization: developers don't want to click through 15 pages to find a log, configure an alert, or create a Jira ticket. We live in our terminals and IDEs, where we just hit Cmd/Ctrl + K and type what we want.

I decided to bring that exact experience to observability. Instead of building a complex "flight-simulator" dashboard with endless toggle switches and dropdown menus, I built Loguro around two core ideas that changed everything about how I interact with logs.

This is "The Loguro Way."

1. The "Smart" Input Bar

Most logging tools force you to build queries visually or force you to learn a proprietary syntax just to filter out the noise. In Loguro, the entire experience is anchored by a single input field that feels alive.

It's not just a search bar; it's a context-aware engine:

Natural Macros: Found a query that catches failed checkout attempts? You don't need to bookmark a URL. Just hit Cmd + S or --save:failed-checkouts to save it as failed-checkouts. The next time you type #fail..., inline ghost-text autocompletes the entire complex query for you, TAB and CMD ENTER it.
Dynamic Syntax Hints: As you type, the input animates placeholder queries and uses reactive state to show you context-aware syntax hints right below the bar. You never have to leave the page to read documentation.

2. A True Command Palette (The Global CLI)

The real magic is the command palette. By hitting Cmd + K, you don't just get a simple page jumping navigation tool.

If you type --, the palette transforms into a fully-functional CLI. It’s perfectly rigged with fast Tab-completion. It feels exactly like using a local terminal, allowing you to instantly jump between your Logs, Alerts, or API Keys pages, and execute deep commands on the fly.

3. The Power of a Command-Driven Plugin Ecosystem 🧩

How do you keep the core UI completely minimalistic while offering enterprise features? You don't hardcode them. You build an isolated plugin architecture.

Every major action in Loguro is powered by isolated plugins that listen to your commands within the CLI. This means the UI only shows you the tools you need exactly when you ask for them:

Data Visibility (Timeline & Downloads): Need a visual representation of your filtered logs? Just type --timeline and a temporal graph instantly appears in your results panel. Need those logs for offline analysis? Type --download:csv or --download:parquet, provide an optional expiration time (e.g., 24h), and Loguro generates an optimized archive on the spot. You can even type --download:list to manage your previous exports.
Instant Security (API Keys): Rotating or generating keys shouldn't involve hunting through a deep settings page. Type --keys to view your active tokens, or simply type --keys:my-new-token to instantly create one without leaving the page. To revoke it, just type --keys:my-new-token:delete.
Instant Issue Tracking (Jira, Linear, GitHub): See a critical exception? Don't copy-paste the stack trace into a new browser tab. Just type --task:linear:LOG_ID directly in the command palette. Loguro will instantly parse the command, generate a task preview with the exact log context attached, and create the ticket the moment you hit Enter, include --send:slack to automatically send the ticket and details to the configured channel. Or type --tasks:list:jira to show all created Jira issues globally.
Frictionless Messaging (Slack, Discord): Need to notify the team about a spike in errors? Type --send:slack:"Hey team, seeing a lot of 500s here." Loguro will bundle the current context and push an alert straight to your configured channel. For setup, simply typing --config:slack brings up the zero-click configuration panel.

By treating operations like analyzing timelines, generating encrypted archives, and managing access tokens as isolated "commands," the dashboard stays completely out of your way until you summon it.

The Vision

The Loguro way is about treating your logging platform like your favorite code editor. It should be fast, keyboard-driven, and infinitely extensible through plugins, rather than bogged down by UI clutter.

While user-created custom plugins aren't available yet (you can't write your own in the dashboard), this foundation ensures that adding new integrations or custom commands natively in the future is just plugging them into the command registry.

If you're tired of reaching for your mouse every time an alert fires or you need to download a CSV, you might enjoy this approach.

You can give it a spin at loguro

Logging shouldn't feel like flying a spaceship 🚀

Sebastian Pavel — Wed, 04 Mar 2026 22:26:00 +0000

Why I Built Loguro: Logging Shouldn't Feel Like Flying a Spaceship 🚀

When I started building Loguro, I had one simple mission: Keep logging simple. That’s it.

Whenever I show it to people, the first thing I hear is: "But we already have Axiom, Datadog, and all these massive solutions." True. But those tools are built for a scale that often brings unnecessary friction. You end up paying for features you don't use, navigating "flight-simulator" dashboards, and learning proprietary query languages just to find a single error.

Loguro is the "no-noise" SaaS alternative. I wanted a tool where the tech stays out of the way so you can focus on the code.

🛠 The Philosophy: Focus on the Code, Not the Tool

The goal for Loguro is to stay out of your way. It is a tool where you don't need to hunt for buttons or navigate complex pages.

1. Human-First Querying

Write filters the way you'd explain them to a colleague. No syntax manuals needed.

Syntax	What it does	Example
`level:`	Filter by severity	`level:error`
`@`	Natural time	`@today` or `@10minutesago`
`from: and to:`	Still natural time	`from:"10 days ago" to:"yesterday"`
`!message:`	Exclude the noise	`!message:"cache miss"`
`context.`	Deep-dive fields	`context.user_id:42`
`trace.`	Follow a trace send with `X-Request-ID` header	`trace."uuid"`

2. The "Mouse-Free" Workflow ⌨️

I’m obsessed with keeping you on the keyboard. If you have to reach for your mouse, I’ve failed as a designer.

Autocompletion: It’s smart and it’s fast. Hit Tab and it’s there for you.
Saved Views: Cmd/Ctrl + S to save a complex query, Cmd/Ctrl + B to browse them.
Command Palette: Cmd/Ctrl + K to jump between Logs, API Keys, and Alerts instantly.
Focused and don't know a query?: Cmd/Ctrl + / opens the help from the advanced search.

⚡️ Performance that Bites

Don't let the "simple" UI fool you. Under the hood, the engine is a beast:

Sub-500ms query times on 50M+ logs.
45k+ req/s ingestion on single requests.
500k+ logs/s in batch mode.

🎯 Key Features at a Glance

Signal Monitors (Alerts): Set up a per-project alert in 5 clicks from the UI, or 2 clicks directly from a log line you’re currently investigating.
Trace Discovery: Traces are first-class citizens. Click a trace ID to instantly follow the entire request lifecycle.
Log Detail View: One-click copy for Trace IDs, IDs, or the full JSON context. Visual styling changes based on log severity so you can spot errors in a sea of info. Find anything inside the context with the advanced search and jump between entries with just Enter.

The Vision

Loguro is for the developer who wants to Find the bug. Fix it. Move on. ☕️

I’m constantly adding features to keep the experience as simple and mouse-free as possible. If you've ever felt overwhelmed by the complexity of modern observability, Loguro might be the breath of fresh air you need.

There are a lot of ideas i have in my head waiting for me to put them on Loguro, like:

Secure, "No-Login" Sharing

We've all been there: a Product Owner asks why payments are failing. Instead of taking a sketchy screenshot, Loguro will let you generate a secure, shareable link to a specific log entry or view. They get the context they need; you don't have to manage a new user account for them. Just to let the PO know why the revenue stopped—just saying.

BYOS

There are companies which do not want to store the logs on my servers, or they just want to avoid paying the storage(which BTW is cheap because of the parquet compression i am using), so i shall be able to provide them a way to add credentials for whatever storage provider they want, S3, R2, whatever, and just push the logs there while the queries will still happen on my own dashboard but without me having a single piece of log from them on my server.

What’s the one thing that drives you crazy about your current logging setup? Let’s chat in the comments.

While i still work on it, even if it's fully working at production level, there is only one plan, *FREE with generous limits. Something will change on the future, maybe the retention, but we'll see.

PS. It doesn't need to be used on web only, it can be used in any setup that provides a secure way for you to use an api key, even a plain server on which you need to have some logs and alerts.

You can give it a spin here: loguro

HookTunnel: A Modern Alternative to Ngrok for Webhook Development

Sebastian Pavel — Sun, 30 Nov 2025 21:12:00 +0000

HookTunnel: A Modern Alternative to Ngrok for Webhook Development

If you've ever struggled with webhook development, you know the pain: setting up tunnels that disappear on restart, losing webhook payloads when your local server is down, and the endless cycle of debugging in production.
I built HookTunnel ('tsuu') to solve these problems and make webhook testing as seamless as local development.

The Problem with Current Webhook Tools

Traditional tools like ngrok are fantastic for quick HTTP tunneling, but they fall short for serious webhook development:

Ephemeral URLs: Every restart gives you a new endpoint
No offline handling: Webhooks are lost if your local server is down
Limited inspection: Basic request logging without replay capabilities
No persistence: Hard to debug historical webhook payloads

HookTunnel addresses these pain points with a complete webhook development platform.

What HookTunnel Does

HookTunnel provides everything you need for modern webhook development:

🔗 Persistent Relay URLs
Create endpoints that stay the same across sessions. No more updating webhook URLs in external services.

📡 Offline Queueing
Webhooks are automatically queued when your local server is offline. When you reconnect, they stream in real-time.

⚡ Real-time Forwarding
WebSocket tunnels forward webhooks instantly to your localhost development environment.

🔍 Inspection & Replay
Full webhook inspection with headers, body, query parameters, and metadata. Replay any webhook for testing.

📊 Modern Dashboard
A clean web interface to manage endpoints, view webhook history, and monitor activity.

How It Works

Create Your Endpoint
Get a persistent URL like https://hooktunnel.dev/api/r/your-user-id/your-slug
Connect Locally
Use WebSocket tunnels to establish a secure connection to your development server.
Receive Webhooks
External APIs send webhooks to your HookTunnel URL, which forwards them to your local environment.
Inspect & Debug
View all incoming webhooks in the dashboard with full request details.
Replay for Testing
Resend webhooks to test different scenarios or debug edge cases.

Tech Stack

HookTunnel is built with modern web technologies:

Frontend: Next.js 16 (App Router) + React 19
Backend API: Hono framework for high-performance routing
Database: Turso (SQLite) + Drizzle ORM
Authentication: Better Auth with OAuth support
Payments: Stripe integration for premium features
Real-time: WebSocket tunnels for instant forwarding
UI: TailwindCSS 4 + shadcn/ui components

Getting Started

HookTunnel is currently in alpha, so things might be a bit rough around the edges while I iterate. But if you're ready to try it:

Visit hooktunnel.dev (https://hooktunnel.dev)
Sign up for an account
Create your first endpoint
Start receiving webhooks locally

Why I Built HookTunnel

As a developer working with webhooks daily, I got tired of the friction in the development workflow. HookTunnel started as a personal tool to scratch my own itch, but I believe it has broader value for the developer community.

The goal is to make webhook development feel native to your local environment - no more context switching, no more lost payloads, no more production debugging nightmares.

Current Status

HookTunnel is a work-in-progress personal project. I'm actively building features, fixing bugs, and iterating based on feedback.

What webhook development pain points do you face? I'd love to hear your thoughts and feedback!

HookTunnel is my latest indie project - a modern webhook development platform built with Next.js, Hono, and WebSocket magic. Currently in alpha, but already making webhook testing much more enjoyable.

efri, the_framework

Sebastian Pavel — Thu, 13 Feb 2025 09:07:30 +0000

Hey codeholics! 👋

I'm a huge fan of Laravel, but let's be real - PHP can be a pain sometimes, right? That's why I built Efri, my take on bringing Laravel's awesomeness to TypeScript.

The framework is coming along nicely - it's built on Bun with lots of TypeScript goodness baked in. I've been running some speed tests against other JS/TS frameworks, and trust me, this thing flies! 🚀

What's in the Box?

Got all the good stuff you'd expect:

Plugin system to extend everything
Config management
Middleware support
Its own logger (because why not?)
Gates, validators, models, controllers
CLI commands
And more goodies!

Here's the thing that always bugged me - writing database code over and over for different DBs. Like, why can't everything be as smooth as Laravel's Eloquent? That's where Knex comes in - write once, run anywhere (with a bit of config magic)!

Want to take it for a spin? Just run:

bunx create-efri@latest
bun dev

Need to see what commands are available? Just hit:

bun efri

Check out the docs at efri.sepavl.com if you want to dive deeper!

Did you encountered any issue? Here is the Github, feel free to drop me an email or contact me on my socials too if needed.

Shared form with config files in NextJs

Sebastian Pavel — Thu, 09 Jan 2025 22:32:41 +0000

Working with forms has always been one of the most challenging aspects of development—not because creating a form is inherently difficult, but because of the sheer amount of code required to make a truly good one.

Recently, I became a father! The play time has shortened, but I found myself with a bit still to tackle this challenge head-on. So, I decided to build a way to assemble forms faster in React (Next.js, of course). Let's dive in and explore the solution.

I will act like you already have everything prepared and you are ready to build a shared form solution for your future projects.

1. Build a zod schema.

It can be whatever you want, i will go with something simple, a user schema.

userSchema.ts

export const userSchema = z.object({
  id: z.string().optional(), // we don't want it to complain about adding an id in the frontend i assume
  name: z.string(),
  email: z.string(),
  image: z.string(),
});

We can add lots of fields here but it will remain on you to add more based on your needs.

2. Add the schema configuration

Have a look at this gist to add the schema configuration that handles some of the magic.

3. Add the configuration specific to your zod schema.

export const productFieldConfigs = () =>
  createFieldConfigs(userSchema, {
    name: {
      type: "text",
      placeholder: "Johnny Doe",
      className: "w-full",
      inputClassName: "text-sm",
      rules: {
        required: {
          value: true,
          message: "This field is required",
        },
      },
    },
    image: {
      optional: true,
      label: "Some label whatever you want",
      className: "w-full",
      inputClassName: "text-sm text-center",
      type: "image",
      onImageLoad(value) {
        console.log(value, "loaded");
      },
      previewClassName: "w-full h-48 border rounded-xl overflow-hidden",
      uploadAreaClassName: "max-w-md mx-auto",
    },
    email: {
      type: "text",
      placeholder: "Email",
      className: "w-full",
      inputClassName: "text-sm",
      rules: {
        required: {
          value: true,
          message: "This field is required",
        },
      },
    },
  });

This seemed pretty simple, let's go further and see how do we render this form on the screen.

4. Add the shared form component.

Here we have the shared form component, it is not perfect, but it did the job for me and i think it will for others too. On the same gist, you can see all the other components I made to cover my needs.

You can combine those fields as you wish, here a small example:

Assume the user has to chose between 3 subscriptions.

export const userSchema = z.object({
  subscription: z.string()
})

export const productFieldConfigs = () =>
  createFieldConfigs(userSchema, {
    subscription: {
      type: "select",
      options: [
        {
          label: "Subscription 1",
          value: "sub-1",
        },
        {
          label: "Subscription 2",
          value: "sub-2",
        },
        {
          label: "Subscription 3",
          value: "sub-3",
        },
      ],
      rules: {
        required: {
          value: true,
          message: "This field is required",
        },
      },
    },
  });

It does not have a documentation yet, but, i am preparing for something, i have limited time, as i am father now, but i still managed to find time to buy a cheap a* domain to push on it a documentation for this and for a badass multi-step form, stay close and you'll see it.

Laravel Debugbar for Next.js

Sebastian Pavel — Sat, 04 Jan 2025 19:52:33 +0000

Laravel Debugbar for Next.js

Working with Next.js as the frontend and Laravel as the backend, I wanted to optimize my queries or at least better understand what is happening with the speed after creating and implementing Queryfi.

Without further ado, here we have it: a Debugbar integration built on top of Laravel Debugbar for Next.js. While there is still a long way to go for it to be perfect, it works for me and the project I am currently working on.

There is no package yet, but if I will have time, I will create a package in the future.

I’ll try not to paste a lot of code here since the files are pretty big. Instead, there are links to GitHub Gists for the code (follow the this keywords). 😁

Implementation

Laravel Setup

Install Debugbar in your Laravel project:

   composer require barryvdh/laravel-debugbar --dev

Create a middleware called InjectDebugBarData and add the following code to inject Debugbar data into your Laravel API responses:

   <?php  

   namespace App\Http\Middleware;  

   use Barryvdh\Debugbar\Facades\Debugbar;  
   use Closure;  

   class InjectDebugBarData  
   {  
       public function handle($request, Closure $next)  
       {  
           $response = $next($request);  

           if ($response->headers->get('Content-Type') === 'application/json' && Debugbar::isEnabled()) {  
               $debugbarData = Debugbar::getData();  

               // Decode the existing JSON response  
               $originalData = json_decode($response->getContent(), true);  

               // Update accordingly as for me `data` is a default  
               if (isset($originalData['data'])) {  
                   // Inject debugbar into the existing 'data' key  
                   $originalData['data']['debugbar'] = $debugbarData;  
               } else {  
                   // Fallback: Add debugbar separately if 'data' key doesn't exist  
                   $originalData['debugbar'] = $debugbarData;  
               }  

               // Set the modified response content  
               $response->setContent(json_encode($originalData));  
           }  

           return $response;  
       }  
   }

Apply this middleware to your routes.

Next.js Setup

Create a file named debugBar.ts in your utilities folder and add the code to handle Debugbar responses.
Make sure you have shadcn as the component is built with it.
Create a service provider to manage Debugbar data and add this.
Create a component for the Debugbar to display and add this.

Using the Debugbar

Wrap your app layout with the service provider to include the Debugbar component:

<DebugBarProvider>  
    {children}  
    <DebugBar />  
</DebugBarProvider>

In your API responses, use the hook from the DebugBar provider:

const { addResponse } = useDebugBar();  
addResponse(data.debugbar);

Final Notes

Following these steps, if you log something in your Laravel app, you will see the logs in the browser console. The component will be similar but simpler compared to the one provided by the official Laravel Debugbar package.

Designing a Scalable Repository Structure in Laravel with queryFi

Sebastian Pavel — Mon, 16 Dec 2024 23:02:35 +0000

Introduction

When I was starting a new Laravel project, I often wondered what structure I should use.
Laravel is very well-structured, don't get me wrong, making it hard to mess things up.
However, there is a catch, how do we avoid putting all the logic we need into a controller, such as UserController.php?
In this article, we'll focus on this issue. I'll share my preferred structure to cover my use cases, along with some best practices, and explain how to integrate queryFi.

Getting started

Since you’re here, I’ll assume you already have a Laravel project or know how to create one, so we can skip that step. Just make sure the API is set up.

We’ll be using the following structure:

app
├── Repositories
|   ├── Interfaces
|   |   ├── EloquentRepositoryInterface.php
|   └── Eloquent
|       ├── BaseRepository.php
|       └── UserRepository.php
├── Resources
    ├── BaseResource.php
    └── ExtendedJsonResource.php

You can find the Resources folder here, plus a custom logger.

1. Install queryFi

# Backend
composer require z3rka/queryfi

# Frontend
npm i queryfi

2. Add repository Interfaces

<?php

namespace App\Repositories\Interfaces;

use Illuminate\Http\Resources\Json\JsonResource;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Http\Request;

interface EloquentRepositoryInterface
{
    public function create(array $attributes = [], ?string $successMessage, ?string $errorMessage): JsonResource;

    public function all(Request $request, ?string $errorMessage): JsonResource;

    public function one(Request $request, Model $model, ?string $errorMessage): JsonResource;

    public function update(Request $request, Model $model, ?string $successMessage, ?string $errorMessage): JsonResource;

    public function destroy(Request $request, ?string $successMessage, ?string $errorMessage): JsonResource;
}

3. Add the base repository class

I’ll add only three methods here to keep things clean and avoid cluttering the space with repetitive code.
You can find the rest here.

<?php

namespace App\Repositories\Eloquent;

use Z3rka\Queryfi\HasRelations;

class BaseRepository implements EloquentRepositoryInterface {
    use HasRelations;

    public function __construct(protected Model $model)
    {
        //
    }

    public function create(array $attributes = [], ?string $successMessage, ?string $errorMessage): BaseResource
    {
        try {
            return new BaseResource(
                true,
                $successMessage,
                $this->model->create($attributes)
            );
        } catch (Exception $e) {
            return new BaseResource(
                false,
                $errorMessage,
                [
                    'error' => $e
                ]
            );
        }
    }

    public function all(Request $request, ?string $errorMessage): BaseResource
    {
        try {
            return new BaseResource(
              true, 
              'Success', 
              $this->processModel($request, $this->model)
            );
        } catch (Exception $e) {
            $this->spitError($e);
            return new BaseResource(
                false,
                "Fail",
                $this->model->get(),
                [
                    "error" => $e,
                ]
            );
        }
    }

    public function one(Request $request, Model $model, ?string $errorMessage): BaseResource
    {
        try {
            return new BaseResource(
              true, 
              "success", 
              $this->processModel($request, $model)
            )
        } catch (Exception $e) {
            $this->spitError($e);
            return new BaseResource(
                false,
                "Fail",
                $model,
                [
                    "error" => $e,
                ]
            );
        }
    }
}

Normally, to return something from a model you have to ->get() or to find and ->first(), that’s not the case here as we are using the queryFi package and we can do this:

$this->processModel($request, $this->model)

This automatically covers ->get() by default if no getter(check the getters here) is configured in the query.

4. User repository

<?php

namespace App\Repositories\Eloquent;
use App\Models\User;
use Z3rka\Queryfi\HasRelations;

class UserRepository extends BaseRepository
{
    use HasRelations;

    public function __construct(User $model)
    {
        parent::__construct($model);
    }
}

5. User controller

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Repositories\Eloquent\UserRepository;

class UserController extends Controller
{
    public function __construct(public UserRepository $userRepository)
    {
    }

    public function index(Request $request)
    {
      return $this->userRepository
                  ->all($request, "Ooops, there was an error fetching all the users.")
    }

    public function show(Request $request, User $user)
    {
      return $this->userRepository->one(
            $request,
            $user,
            "Ooops, there was an error fetching the user."
        );
    }
}

6. The api route

Route::resource('users', UserController::class)->only(['index', 'show'])

Once we have everything set up, we can make requests from the browser by passing query parameters directly, like:

url?where[name]=john&select=name&getter=first

Alternatively, we can use the queryFi TypeScript package on the frontend for a cleaner approach.

import { createQuery } from "queryfi";

const query = createQuery('/api/users', {
    baseUrl: "http://localhost:8000"
  })
  .where({
    id: 1
  })
  .first() // will return an object with the user if it exists.

The generated query will look like

http://localhost:8000/api/users?where[id]=1&getter=first

This piece of code will return the user with id = 1.
When you use .find(), the response will automatically be an object.
If you use .get(), it will return an array.

You can try it out in the playground to see how the response looks.

Since we’re using the HasRelations trait, we can chain frontend queries to transform the data directly on the backend before it’s returned, as shown here.

import { createQuery } from "queryfi";

const query = createQuery('/api/users', {
    baseUrl: "http://localhost:8000"
  })
  .where({
    id: 1
  })
  .select(['email', 'id', 'name'])
  .get() // will return an array with one entry if it exists.

For more methods you can use, check out the the queryFi documentation

END

And that’s it! 🎉 Now you’ve got a solid and powerful starting point to build your APIs like a pro.
Go ahead, flex those coding muscles, and make something awesome! 🚀💻

Get in touch github, Linkedin, queryFi