DEV Community: Chirag Aggarwal

How utopia-php/client keeps fixing our memory leaks

Chirag Aggarwal — Wed, 05 Aug 2026 06:36:19 +0000

Originally published on my site, where the three diagrams are interactive.

One of our billing workers kept dying.

It would sit flat for hours, then climb into its memory limit in about four minutes and get killed. Kubernetes restarted it, and later the same day it happened again. Six times a day, every day.

The obvious first move is to look at what PHP is holding on to, and that's where it got strange. When PHP runs out of memory it tells you: a fatal error, a stack trace, the allocation that tipped it over. We had none of that. memory_get_usage() reported a flat 6 MB the entire time, right up to the moment the process vanished.

Those two facts together are the whole puzzle. Something was eating memory, and it wasn't the PHP heap. It was cURL, two sockets at a time, and the cause turned out to be a missing keyword.

We've chased this same shape in more than one Appwrite service now, and the fix has been the same every time: stop building a new HTTP client for every call, and move the library onto utopia-php/client.

What was actually leaking

The worker idles at ~330 MB against a 512Mi limit, which is the flat stretch below. Once a day the newly-due invoice batch runs, about a thousand invoices with several Stripe calls each, and it goes from comfortable to dead in roughly four minutes.

Memory as a percentage of the container limit; the axis starts at 45% because nothing happens below it. Six hours flat around 60%, then the batch starts and the line goes vertical: 332 MB, 374, 450, 533, against a 536 MB ceiling.

Luke traced it, and the code turned out to be completely unremarkable. Pay\Adapter::call() built a new Utopia\Fetch\Client for every request. In a one-shot FPM request that's fine; the process exits and the OS reclaims everything. In a long-lived worker it's a slow bleed, and the reason is a reference cycle that has nothing to do with the PHP heap.

curl_setopt stores your write callback on the CurlHandle. A closure declared inside an instance method captures $this. So the handle holds the closure, the closure holds the adapter, and the adapter holds the handle. Nothing can be freed by refcounting, and __destruct, with its curl_close, only runs when PHP's cycle collector fires. By default that means after 10,000 cycle roots have piled up. Until then every request strands an open keep-alive connection.

Reduced down, that's this:

final class Curl
{
    private ?CurlHandle $handle = null;   // the adapter holds the handle

    public function send(Request $request): Response
    {
        $body = '';

        // Nothing in here mentions $this. Declaring a closure inside an
        // instance method binds it anyway, and curl_setopt parks the
        // closure on the handle: adapter -> handle -> closure -> adapter.
        curl_setopt(
            $this->handle,
            CURLOPT_WRITEFUNCTION,
            function ($ch, string $chunk) use (&$body): int {
                $body .= $chunk;

                return strlen($chunk);
            },
        );

        // ...
    }
}

The fix is one keyword:

static function ($ch, string $chunk) use (&$body): int {

A static closure gets no $this, so the last edge never forms and refcounting frees the handle as soon as the adapter goes out of scope. Neither callback used $this in the first place, which is what makes the change safe and also what makes it so easy to miss.

Two file descriptors and roughly a megabyte of native TLS buffers per request, none of it visible to memory_get_usage(). Descriptors are capped per process too, so whichever ceiling you reach first decides how the thing dies: the kernel OOMKills you, or you start refusing connections with Too many open files. I've written that exact closure before, probably more than once, and it would never have occurred to me that static was load-bearing. Adding it to both callbacks in utopia-php/fetch took 150 sequential requests from 309 fds and 183 MB RSS to 9 fds and 31 MB, flat.

We shipped that and moved on, which was the wrong instinct. It fixed the symptom in one library and left three others still hand-rolling their own transport, each free to reinvent the same bug.

What the library is

utopia-php/client is a PSR-18 HTTP client for PHP 8.5. It's about 2,400 lines including both transports, and it doesn't try to be clever:

Every layer implements the same Adapter interface, so they stack in any order and a caller can replace any of them with a stub.

Utopia\Client itself does almost nothing at request time. It resolves the URI against a base, fills in default headers, optionally stamps a traceparent, and hands the request to an adapter. Connection lifetime, TLS, timeouts and error classification all live in the adapter. Anything policy-shaped lives in a decorator.

$client = new Client(new CurlAdapter())
    ->withBaseUri('https://api.stripe.com/v1')
    ->withBearerAuth($secret)
    ->withConnectionReuse()
    ->withTimeout(30);

$response = $client->sendRequest(
    new Request\Factory()->form(Method::POST, 'customers', ['email' => $email]),
);

Which specs it holds itself to

Writing your own HTTP transport in five places means reading the specs badly in five places. Here's what the shared one is on the hook for.

Spec	What it decides
PSR-18	`4xx`/`5xx` are responses; the two-branch exception contract
PSR-7 / PSR-17	Immutable messages and the factories that build them
RFC 9110	Idempotency, `Retry-After`, `Authorization`, content negotiation
RFC 9112	HTTP/1.1 framing, chunked bodies, status-line parsing
RFC 9113	HTTP/2, which APNs requires and HTTP/1.1 can't satisfy
RFC 3986	Base-URI resolution and dot-segment removal
RFC 6750 / 7617	`Bearer` and `Basic` credential formats
RFC 7578 / 2046 / 2183	`multipart/form-data`, boundaries, `Content-Disposition`
RFC 1951 / 1952 / 7932 / 8878	deflate, gzip, br, zstd content codings
RFC 8446	TLS 1.3, and the floor you can pin below it
W3C Trace Context	`traceparent` propagation

PSR-18 decides what counts as an error

The sentence that does the most work:

A Client MUST NOT treat a well-formed HTTP request or HTTP response as an error condition. For example, response status codes in the 400 and 500 range MUST NOT cause an exception and MUST be returned to the Calling Library as normal.

A 429 is not a failure, it's an answer. So sendRequest() returns it, and only genuine "there is no response" conditions throw. PSR-18 splits those into two branches: RequestExceptionInterface for a malformed request or response, NetworkExceptionInterface for a transport that failed. The type answers one question, which is the only one you have at the catch site. Would trying again help?

The library's own hierarchy keeps that property all the way down.

ClientExceptionInterface
├── NetworkExceptionInterface — retrying may help
│   └── NetworkException
│       ├── DnsException, TimeoutException, ProtocolException, ProxyException
│       └── ConnectionException
│           └── TlsException
└── RequestExceptionInterface — retrying is pointless
    └── RequestException
        ├── InvalidUriException, InvalidResponseException
        └── AdapterPreconditionException, AdapterInitializationException

Each adapter maps its native error codes into that tree. The cURL adapter matches on CURLE_* constants, guarded by defined() so a libcurl build without HTTP/3 doesn't fatal at load.

Another line from the spec you can find in the code almost verbatim:

If a Client chooses to decompress the message body then it MUST also remove the Content-Encoding header and adjust the Content-Length header.

Both adapters negotiate compression for you: the request advertises whatever codecs the transport can decode, and the response arrives as plaintext. Which means the Content-Encoding: gzip and Content-Length the server sent are now lies about the body you're holding, so the adapter drops both. Set your own Accept-Encoding and it gets out of the way entirely.

Retrying, and why only some requests get to

Retry is a decorator, and its default Backoff strategy reads almost directly off RFC 9110. Only idempotent methods (§9.2.2) are retried, so a lost response can't turn into a double charge. Only transient outcomes are retried: a NetworkExceptionInterface, or a 429 / 502 / 503 / 504. A numeric Retry-After (§10.2.3) beats the computed delay, because the server knows things the client doesn't.

With no Retry-After, the wait is exponential with full jitter: a value drawn uniformly from [0, ceiling) rather than the ceiling itself.

Our workers run as a fleet. A fleet that backs off deterministically comes back at a struggling upstream in lockstep and keeps it struggling.

Every one of those decisions lives behind a single method, so a library with different rules writes its own:

interface Strategy
{
    public function delay(
        RequestInterface $request,
        int $attempt,
        ?ResponseInterface $response,
        ?ClientExceptionInterface $error,
    ): ?float;
}

utopia-php/storage does exactly that. S3 signals throttling in an XML body as often as in a status code, so S3\RetryStrategy parses the body first and retries SlowDown, ServiceUnavailable, Throttling and RequestThrottled. It also refuses to retry a 503 whose body parses cleanly into some other error code, which is the case a status-code-only rule gets wrong.

`withBaseUri()` is not string concatenation

It looks like a convenience until you send ../v2/users and find out which one your client implements. This one does dot-segment removal, and only applies the base when the request URI is actually relative. An absolute URI passes through untouched.

Everything else is a header you'd otherwise hand-roll

withBasicAuth() is RFC 7617's base64(user:pass). withBearerAuth() is RFC 6750's Bearer <token>. Part::file() builds an RFC 7578 part with its RFC 2183 Content-Disposition. withMinTlsVersion(Tls::V1_2) is an enum each adapter maps to CURLOPT_SSLVERSION or Swoole's ssl_protocols. withTracePropagation() forwards the active utopia-php/span trace as a traceparent, and refuses to overwrite one that's already on the request.

None of these are hard. They're just wrong in slightly different ways in every library that rolls its own.

The four rules underneath

Reuse over recreate

withConnectionReuse() keeps one connection alive per client and reuses it for every request to the same origin. curl_reset() clears per-request options while preserving the handle's connection cache; the Swoole adapter keeps a kept-alive coroutine client keyed by origin. It's opt-in, on the theory that a client built for one call shouldn't sit on a socket. Any long-lived service wants it on.

For Pay, that one change was the entire fix. Four hundred requests against a local echo server, before and after:

	fds	RSS
client per call	+800	+21 MB
reused connection	+0	+48 kB

When you need concurrency rather than sequence, Client\Pool borrows a client from a utopia-php/pools pool per request and reclaims it afterwards, so N coroutines share a bounded set of connections instead of opening N of their own.

Every `with*()` returns a clone

In Swoole that's not a style preference. A shared client you can mutate is a cross-request bleed waiting to happen, and cloning means there's no way to reconfigure someone else's client from inside a request handler.

A default is also only ever a default. withHeaders() fills in a header the request doesn't already carry and nothing more, so a per-request Content-Type beats the client-wide one.

Policy lives in decorators

Retry implements the same Adapter interface it wraps, forwards every configuration helper inward, and overrides only sendRequest() and stream(). So retries, pooling and whatever you add stack in any order, and none of them turn into constructor flags on the transport.

The stream() override is my favorite detail in the library. It counts bytes handed to the sink, and once a single byte has been delivered it stops retrying, because replaying would duplicate data the caller already processed.

Bounded memory by default

stream() hands each chunk to a sink as it arrives, so SSE and LLM token streams cost the same memory as a ping. Uploads go the same way: cURL pulls the body through a read callback, Part::file() reads lazily, and Swoole sends files with zero-copy sendfile(). A seekable body gets rewound before each attempt, which is what makes a streamed upload safe to retry at all.

Where it ended up

Package	Before	Now
`utopia-php/pay`	`new Fetch\Client` per call	one injected client, `Adapter::call()` deleted
`utopia-php/messaging`	raw `curl_*` and `curl_multi`	PSR-18, plus a Swoole pool for batched FCM/APNs
`utopia-php/storage`	ad-hoc HTTP in the S3 devices	default client with a stall watchdog and `S3\RetryStrategy`
`utopia-php/fastly`	—	built on it from day one
`appwrite/appwrite`	per-service HTTP wiring	`jobs` and `screenshots` clients in the DI container

The Pay migration was net -55 lines. Adapter::call(), handleError(), and nine METHOD_* constants went with it — seven of the nine had no caller. A PSR-18 client and a PSR-17 factory already mean "build a request, send it"; the indirection was only ever a second vocabulary for HTTP.

Messaging is the one worth reading if you're doing this yourself. It kept every adapter's public API identical while swapping curl_multi for Swoole coroutines over a bounded pool, and added a Closure(): ClientInterface factory so a caller can inject retries, a proxy, or a stub. The one constraint it documents loudly: your factory must produce a client that can negotiate HTTP/2, because APNs rejects HTTP/1.1 outright.

What we grep for now

Climbing RSS with a flat PHP heap. Count fds, not memory_get_usage(). ls /proc/<pid>/fd | wc -l in a loop finds this in five minutes.
new Client() or curl_init inside a request path. In a long-lived process a client is a resource with a lifetime, not a local variable.
Non-static closures handed to curl_setopt. If it doesn't touch $this, make it static. Costs nothing, and it's the whole bug.
Any utopia library still carrying its own private HTTP stack. That's the rest of the work list.

Repo: utopia-php/client, though development happens in the monorepo. @lukebsilver wrote it and did the Pay migration. I did messaging, which is how I ended up with opinions about APNs.

fetch(...) per Stripe API call, with a paste showing rss=63212kB fds=7 at start and rss=64696kB fds=47 at i=40, exactly +1 fd per fetch, RSS monotonic, PHP heap flat at 6.0MB throughout. Solution is to migrate to utopia-php/client. Reply: the astronaut meme, wait, solution is migrate to utopia-php/client? always has been." width="799" height="541">

Internal consensus, after the third identical incident. The paste is the diagnostic: fds climb one per call, RSS follows, the PHP heap never moves.

Reference

Term	What it means here
file descriptor (fd)	The integer the kernel gives a process to refer to something it has open. Every live socket holds at least one, and each process has a cap (`ulimit -n`).
RSS	Resident set size: the physical memory a process actually occupies, native allocations included. This is what the kernel measures when it decides to kill you.
OOMKilled	The kernel terminating a process for exceeding its memory limit. It happens outside PHP, so there's no fatal error and nothing in the logs.
PHP heap	The pool the Zend allocator manages, which is what `memory_get_usage()` reports and `memory_limit` caps. cURL and OpenSSL allocate outside it.
reference cycle	Objects holding each other so no refcount ever reaches zero. Only PHP's cycle collector can free them, and it runs on its own schedule.
idempotent method	A request that can be sent more than once without changing the outcome. `GET`, `HEAD`, `PUT`, `DELETE`, `OPTIONS`, `TRACE` qualify; `POST` doesn't.
full jitter	Backoff where the wait is drawn uniformly from `[0, ceiling)` instead of being the ceiling, so a fleet retrying together spreads out.
coroutine	Swoole's userland concurrency. One worker process interleaves many in-flight requests, which is why connection lifetime matters so much.
sink	The callback `stream()` hands each response chunk to as it arrives, instead of buffering the whole body.
APNs / FCM	Apple and Google's push notification services. APNs is the one that rejects HTTP/1.1.

The specs

HTTP semantics in RFC 9110, message framing in RFC 9112, HTTP/2 in RFC 9113, and 429 in RFC 6585
PHP-FIG: PSR-18 for clients, PSR-7 for messages, PSR-17 for factories
URIs in RFC 3986; credentials in RFC 6750 and RFC 7617
Multipart in RFC 7578, building on RFC 2046 and RFC 2183
Content codings: deflate, gzip, br, zstd
TLS 1.3 and W3C Trace Context

The code

utopia-php/client, developed in the monorepo package, on top of utopia-php/psr7 and utopia-php/pools
fetch#22 — the reference cycle, with the fd and RSS measurements
pay#32 — the migration that fixed the OOMKills, and the before/after numbers
messaging#137 — curl_multi swapped for Swoole coroutines over a pool

Background

AWS, Exponential Backoff and Jitter, which is where the full-jitter formula comes from
PHP manual, Collecting Cycles, on when the collector actually runs

Cross-posted from chirag.appwrite.network.

How I built the Appwrite MCP server (and decided to hide most of its capabilities)

Chirag Aggarwal — Tue, 04 Aug 2026 03:37:36 +0000

When Anthropic introduced the Model Context Protocol on November 25, 2024, it got everyone's eyes on it, including Christy, who was Appwrite's Engineering Lead back then. I had just started my role as an "Engineering Intern" and had no idea what a whole new protocol meant, or why it was such a big deal.

Looking at the surface, I wasn't entirely wrong. MCP is JSON-RPC with a schema and a handshake stapled on. What took us sixteen months was everything stapled around it.

Streamable HTTP did not exist when MCP launched. It replaced HTTP+SSE in the 2025-03-26 revision.

The stdio years

Christy had a working stdio server in the repo by February 26, 2025. We already had API keys, so the wiring was simple:

claude mcp add appwrite \
  --env APPWRITE_PROJECT_ID=<YOUR_PROJECT_ID> \
  --env APPWRITE_API_KEY=<YOUR_API_KEY> \
  --env APPWRITE_ENDPOINT=https://cloud.appwrite.io/v1 \
  -- uvx mcp-server-appwrite

An API key is scoped to exactly one project by design, so the ceiling was baked into the credential. Switching projects meant editing your editor config. Creating a project was impossible. So was anything at the organization level.

The credential is the whole difference between the two transports, and everything hard about the hosted version follows from swapping it for a token that belongs to the user instead of the project.

Authorization ate the schedule

By the spec, authorization is genuinely optional:

Authorization is OPTIONAL for MCP implementations. [...] Implementations using an HTTP-based transport SHOULD conform to this specification.

For a service where one tool call can drop a database, we weren't comfortable treating it as optional. If you use Auth0 or WorkOS, this is a config screen. Appwrite keeps everything in-house, so Matej built the authorization server itself, and I built the resource server plus whatever Cloud was still missing before real clients would work.

Steps 2 through 6 are the part that makes "just paste this URL" work. Nothing is pre-provisioned.

Three RFCs carry that flow. Protected Resource Metadata (RFC 9728) is the only real MUST in the whole authorization spec:

{
  "resource": "https://mcp.appwrite.io/",
  "authorization_servers": ["https://cloud.appwrite.io/v1/oauth2/console"],
  "scopes_supported": ["..."],
  "bearer_methods_supported": ["header"]
}

Resource Indicators (RFC 8707) put our canonical URI into the token's aud, so a token minted for another service can't be replayed against us. Dynamic Client Registration (RFC 7591) is what lets a client self-register. Add PKCE with S256, RFC 8414 discovery, and you have the shape of it.

The RFCs are documented. What isn't documented is that every client reads them differently, and you find out in production:

Raycast was on the 2025-03-26 authorization spec, which looks for /.well-known/oauth-authorization-server instead of the protected-resource route. I only found it by putting a logging proxy in front of the server and watching what it actually asked for.
Claude Code re-authenticated every single run. It listens on an ephemeral loopback port, so the redirect URI never matched. OAuth's native-app BCP (RFC 8252 §7.3) says you must allow any port on 127.0.0.1. We weren't.
Our own scope catalog broke the flow. All ~118 granular scopes produced a scope parameter of ~2,680 characters against a validator capped at 2,048. Nobody ever reached a consent screen.

One warning if you're about to build this: RFC 7591 went from SHOULD to MAY in 2025-11-25 and is deprecated as of 2026-07-28, replaced by Client ID Metadata Documents. We shipped that too. This part of the spec is still moving.

Sessions, and then no sessions

The 2025-06-18 spec let a server hand out an Mcp-Session-Id alongside the InitializeResult, with DELETE to terminate and Last-Event-ID for resumability. We skipped all of it:

StreamableHTTPSessionManager(app=server, json_response=False, stateless=True)

Every request carries a bearer token. Verify it, build a client from it, serve the call. Nothing to store, nothing to lose on restart, nothing to make sticky across replicas.

That turned out to be the right bet for a reason I can take no credit for. The 2026-07-28 revision removed sessions from the protocol entirely. Mcp-Session-Id, the initialize handshake, the GET SSE stream: all gone. What we do carry is version negotiation, because you don't get to pick your clients' protocol version.

Off-topic, but why not REST?

Many intellectuals like myself must have wondered why MCP exists at all. Can't this be 100x simpler with, I don't know, REST?

The model only knows its training data plus whatever you hand it at runtime. If it has never seen Appwrite, it will never guess this:

POST https://<REGION>.cloud.appwrite.io/v1/tablesdb
X-Appwrite-Project: <PROJECT_ID>
X-Appwrite-Key: <API_KEY>
Content-Type: application/json

{ "databaseId": "unique()", "name": "Production" }

The endpoint, the header names, the fact that unique() is a magic value. With MCP the same operation shows up self-describing:

{
  "name": "tables_db_create",
  "description": "Create a database in an Appwrite project",
  "inputSchema": {
    "type": "object",
    "properties": {
      "databaseId": { "type": "string" },
      "name": { "type": "string" }
    },
    "required": ["databaseId", "name"]
  }
}

You can be happy knowing AI needs a lot more handholding than you do (for now).

Tool choice

Every MCP server I looked at ships a small, curated set. Appwrite generates one tool per SDK method, which lands at 981 methods across 38 services.

Counts as of August 2026. GitHub's 90 are grouped into 22 toolsets with 5 on by default.

There's no version of "expose them all" that works, for two unrelated reasons.

The clients won't take them. In early 2025 Cursor documented that it "will only send the first 40 tools to the Agent" and truncated silently. Windsurf refused outright above 50.

Discord, liviu74, Mar 14 2025. Windsurf refused it; Cursor accepted it and silently dropped tools 41 onward.

That was with per-service flags already in place, which is the part that stings. A community user opened issue #17, "Please reduce the number of tools":

Cursor has 40 MCP tools limit to use, but Appwrite solely has 195 tools, so it cannot be used with other tools nor even all of Appwrite tools.

I pointed out you could narrow it with --databases. The reply:

That's quite non-sense. Then do I have to edit MCP parameter settings for each time whenever I do another jobs...? And anyway, --databases solely has 42 tools, which already exceeds Cursor's recommended limit (40).

Quality falls off well below the caps. The numbers converge from unrelated directions. Anthropic puts degradation at "once you exceed 30-50 available tools". OpenAI says "fewer than 20 functions at the start of a turn". Block's Goose recommends 50 or fewer. And the fix measures well: Anthropic's advanced tool use work takes Opus 4 from 49% to 74% on MCP tool-use evals with a search tool enabled, and Opus 4.5 from 79.5% to 88.1%, with 85% fewer tokens on definitions. RAG-MCP more than triples selection accuracy (43.13% against 13.62%).

The caveat, because it cuts against me: MCPVerse found some agentic models handle big action spaces fine. Claude-4-Sonnet scored 62.3 with an oracle tool set and 62.4 with ~220 tools. Big catalogs aren't fatal. They're a tax you're paying for nothing when the agent needs three tools out of 981.

Four tools over 981

appwrite_get_context answers where you are and which projects you can see
appwrite_search_tools searches the hidden catalog in natural language
appwrite_call_tool calls one of them by name
appwrite_search_docs searches the Appwrite docs semantically

Search narrows at request time, which is why the per-service flags could be deleted entirely. Mutations require confirm_write: true, and results too large for the conversation become MCP resources instead.

The scoring behind appwrite_search_tools is deliberately dumb: token and substring matching against the tool name, description, service and resource, a bonus when the query's inferred verb matches the tool's, a penalty when it doesn't. No embeddings, no index to rebuild, no inference call in the hot path.

Here's what a client sees:

981 methods behind 4 tools and 1 resource. The "Logout" link is the OAuth session.

What made me stop second-guessing the design is that we weren't alone. Stripe put its whole API behind stripe_api_search. Sentry exposes 9 of 46 through search_sentry_tools. GitHub removed its dynamic toolset tools and looks to be building a search replacement. Three companies with no reason to coordinate landed on search-then-execute in the same window.

Where it landed

claude mcp add --transport http appwrite https://mcp.appwrite.io/

No API key, no project ID, no config editing to switch projects. Projects and organizations are parameters on the call now instead of properties of the credential.

stdio didn't go away. I removed it in the hosted refactor and put it back two days later, because self-hosted users need it. It runs on a project API key and gets 647 of the 981 methods, since a project key can't reach console-level operations anyway.

Behind that URL there's also OpenTelemetry, Sentry, Grafana dashboards, and region routing so a project in another Cloud region doesn't return general_access_forbidden. You end up operating a service, not publishing a package. That's the part I underestimated most.

What I'd tell anyone building one

The transport is not where the time goes. The authorization spec and everything it pulls in is where the months disappear.

Test against real clients early and expect them to disagree. A logging proxy in front of your server was worth more to me than another pass through the docs.

Assume the spec moves under you. Between starting and shipping, sessions were removed, RFC 7591 was deprecated, and a stateless revision landed. Anthropic donated MCP to the Agentic AI Foundation in December 2025, so it isn't even one vendor's project anymore.

And don't hand your API surface over as your tool surface. The architecture this server has today came out of a bug report from a user who was annoyed with us, which I think is the correct way for this to have gone.

The server is open source at github.com/appwrite/mcp, and the hosted one is at https://mcp.appwrite.io/.

Managing multiple docker hub accounts using docker-use

Chirag Aggarwal — Mon, 25 May 2026 05:08:01 +0000

Most of the time I'm signed into my work Docker Hub account, and that's fine. Almost everything I build ends up there. Then one weekend I was playing around with openruntimes/orchestrator, an orchestration service for running containerized workloads with callbacks. I had a PR open with some small tweaks, and I wanted to publish release-candidate images so I could pull them down and actually test end-to-end.

I didn't want those RC images sitting in my work namespace. So for the first time, I actually needed to switch Docker Hub accounts on my machine, and there isn't a good way to do it. The official answer is docker logout, then docker login again. Docker does respect a DOCKER_CONFIG environment variable that points at a config directory, but you still have to set it yourself every time.

A few years ago I'd have spent the afternoon hunting for someone else's tool. In the age of AI, you can just build the one you wished existed. So I did.

The result is docker-use.

The idea

The fix is small. Docker already respects the DOCKER_CONFIG environment variable, and whatever directory it points at is treated as the active config. So the whole mechanism is:

Give every account its own config directory.
Let the shell flip DOCKER_CONFIG between them by name.

No patches to Docker, no daemon involvement, no new credential store. A directory per account, plus a shell function to switch between them.

What it looks like

# one-time per account
docker-use add appwrite -u my-appwrite-username
docker-use add personal -u chiragagg5k

# day-to-day
docker-use appwrite

docker-use personal
docker push chiragagg5k/job-sidecar:temp-appwrite-pr-4f081ed-20260521-r2

docker-use whoami   # which one am I on right now?
docker-use list     # all accounts

add shells out to a normal docker login, so 2FA and access tokens behave the way you already expect.

How it works

There are three pieces.

Each account lives in its own config directory, at ~/.docker-accounts/<name>/config.json. Names are validated against ^[a-zA-Z0-9][a-zA-Z0-9._-]{0,63}$ so they can't escape the directory or surprise the shell.

The trickier piece is a shell wrapper that mutates the parent shell. A child process can't change its parent's environment variables, so the binary on its own can't make DOCKER_CONFIG stick in your shell. The workaround is a shell function, generated by docker-use init zsh, that you source in your rc file:

eval "$(docker-use init zsh)"

The wrapper calls the binary, reads the printed config path, and assigns it to DOCKER_CONFIG in the current shell. It's a plain assignment, not an eval on the path itself, so a weird config name can't smuggle anything into your shell. zsh, bash, and fish all work.

The last piece is keeping Docker's credential helpers in place. When docker login finishes, the resulting config.json often contains "credsStore": "osxkeychain" (or secretservice on Linux). If you wipe that field, Docker Desktop's keychain integration breaks and the next push prompts you for a password. So during add, docker-use reads the config Docker just wrote and preserves the credential helper settings.

Things I'd flag if you read the source

A few decisions that weren't obvious going in.

The shell wrapper assigns the config path directly instead of eval-ing whatever the binary prints. Eval-ing user-controllable output tends to age badly.

Account names get validated before any filesystem operation runs. docker-use add ../etc -u … is not a debugging session I want to have.

remove asks for confirmation before deleting. It's a destructive action on credentials, so the extra keystroke is worth it.

Install

brew tap chiragagg5k/tools
brew install docker-use

Then drop this into your ~/.zshrc (or ~/.bashrc, or ~/.config/fish/config.fish):

eval "$(docker-use init zsh)"

Binaries for other platforms are on the releases page.

If you end up using it, I'd love to hear what works and what doesn't. Open an issue or reach out directly.

How we solved logging at Appwrite

Chirag Aggarwal — Sun, 19 Apr 2026 11:56:39 +0000

A few weeks back I came across a post by @boristane sharing a website he made, loggingsucks.com. It caught my eye because it had been shared by my favorite tech YouTuber, @theo. Like most people, I was really inspired by the article and shared it with my team. @lukebsilver, Appwrite's Engineering Lead, was also inspired by it and decided to work on a new PHP library, utopia-php/span, to fix logging throughout the Appwrite codebase.

What we had

Before this, Appwrite used a combination of two different libraries targeting logging in two different areas:

utopia-php/console — a very simple wrapper library around stdout logging using functions like Console::success(), Console::error(), etc.
utopia-php/logger — an adapter-based library to push error logs to monitoring systems like Sentry, AppSignal, Raygun, etc.

Combined, these libraries served their purpose for a long time, but we often ran into problems when debugging production issues, the same ones the original article discusses in detail. I'd highly recommend going through that article first so I don't repeat it all here.

Our solution

Funnily enough, the first tricky problem was deciding on a name. "Logger" was already taken, so we had to be creative. The word "Span" captured exactly what we were trying to solve: a fundamental unit of work with a named, timed operation alongside various attributes, errors, trace IDs, etc.

The first step was to move away from simple log lines to structured logging. Span enforces this by only exposing a single primary method, add(), which accepts a key-value pair.

Before:

Console::info("Deleting project {$project->getId()} (type={$type}, region={$project->getAttribute('region')})");

After:

Span::add('project.id', $project->getId());
Span::add('project.type', $type);
Span::add('project.region', $project->getAttribute('region'));

This massively improved the queryability of our logs — one of the things we struggled with most when going through logs in production.

We also wanted the library to be extremely simple to use. Earlier, with "logger", we had to hop through various dependency injection loops just to use it:

public function action(
    Message $message,
    Document $project,
    Log $log, // ← has to be injected just to add a tag
): void {
    $log->addTag('projectId', $project->getId());
    $log->addTag('type', $payload['type']);
    // ...actual work...
}

With Span, it's much simpler:

public function action(
    Message $message,
    Document $project,
): void {
    Span::add('projectId', $project->getId());
    Span::add('type', $payload['type']);
    // ...actual work...
}

Why not just make the logger methods static?

Because Appwrite's codebase leverages coroutines (via Swoole) for concurrency between requests, similar to goroutines in Go. A naive static implementation would leak state across concurrent requests. Span solves this by allowing you to choose the storage type:

Span::setStorage(new Storage\Coroutine());

Exporters

To combine both logger and console capabilities, Span exposes built-in Exporters, which, as the name suggests, export the logs to not just stdout but any supported adapter. The library currently supports three:

Stdout: basic usage. Dumps the output as plain JSON:

{
  "action": "worker.deletes",
  "span.trace_id": "7a3f9c2b4e1d8f06",
  "span.duration": 1.92,
  "project.id": "67f3a9",
  "project.type": "projects",
  "project.region": "fra"
}

Pretty: JSON dumps are very useful in production where you have OpenTelemetry or other monitoring set up, but locally you just want things to be readable:

worker.deletes · 1.92s · 7a3f9c2b

  project.id      67f3a9
  project.type    projects
  project.region  fra

  ────────────────────────────────

Sentry: since Sentry is primarily an error tracking system, Span also exposes a callable "sampler" that lets you filter which logs get exported to a particular exporter:

Span::addExporter(
    new Sentry(dsn: '...'),
    // Sampler: drop noisy expected errors, keep everything else.
    sampler: function (Span $span): bool {
        $error = $span->getError();
        return !($error instanceof ExecutorException) || $error->isPublishable();
    },
);

Before and after

One massive improvement we saw was with error logs. Before, we had very verbose and noisy errors that were often hard to make sense of:

[Error] Timestamp: 2026-04-17T10:32:16+00:00
[Error] Type: Utopia\Database\Exception\Timeout
[Error] Message: Query took too long
[Error] File: /usr/src/code/src/Appwrite/Cloud/Platform/Workers/Deletes.php
[Error] Line: 214
Trace: #0 /usr/src/code/app/worker.php(828): ...

Now:

{
  "action": "worker.deletes",
  "span.trace_id": "7a3f9c2b4e1d8f06",
  "span.duration": 2.14,
  "project.id": "67f3a9",
  "error.type": "Utopia\\Database\\Exception\\Timeout",
  "error.message": "Query took too long",
  "error.file": "/usr/src/code/src/Appwrite/Cloud/Platform/Workers/Deletes.php",
  "error.line": 214,
  "error.trace": [
    { "file": "/usr/src/code/app/worker.php", "line": 828, "function": "action" }
  ]
}

If you're writing PHP in 2026, give utopia-php/span a shot. And a massive shoutout to @lukebsilver, who actually built the library. I just learned from him and wanted to share what I picked up.

JStack + Appwrite: A Match Made in Heaven for Modern Web Development

Chirag Aggarwal — Sun, 06 Jul 2025 15:27:22 +0000

If I had a penny for each time a youtuber has launched his own tech stack, I would have 2 pennies, which isn't much but its weird that it happened twice.

I am talking about T3 Stack launched a while back by everyone's favourite Theo, but recently a new player has entered the market called JStack, by Josh who is the lead Devrel at Upstash. To be fair, its not even that recent, but as always ~~I am late to the party~~ I try to give a framework time to mature and gather feedback from community before giving it a shot.

So, did I prefer JStack over T3 stack? Did it have more compatibility with Appwrite, my favourite backend provider? Can it be hosted on Appwrite Sites? Let's find out.

Getting Started

Let's start with initialising the project:

bunx create-jstack-app@latest

Options selected:

┌   jStack CLI 
│
◇  What will your project be called?
│  testing-jstack-appwrite
│
◇  Which database ORM would you like to use?
│  None
│
◇  Should we run 'bun install' for you?
│  Yes

Using: bun

✔ testing-jstack-appwrite scaffolded successfully!

Let's just quickly run a dev server to see what we get out of the box:

cd cd testing-jstack-appwrite
bun dev

Initialising Project

On skipping the ORM option, the stack still sets up a /src/server folder with an example posts router. But it only mocks the DB using an array which does not persist:

// Mocked DB
interface Post {
  id: number
  name: string
}

const posts: Post[] = [
  {
    id: 1,
    name: "Hello World",
  },
]

We skipped the ORM option because Appwrite provides built-in schema management through its SDK, eliminating the need for a separate ORM layer. To get started, let's head over to https://cloud.appwrite.io to set up our project.

If you are using Appwrite for the first time, I highly recommend you check out our Start with Web docs.

Here is a quick setup guide:

Create a new project -

Add a new web platform and select Next.js -

Go to project overview and grab your project's ID and region-specific endpoint:

Create a new .env file in your project directory and paste in those values:

NEXT_PUBLIC_APPWRITE_PROJECT_ID=686a271700323696d223
NEXT_PUBLIC_APPWRITE_ENDPOINT=https://fra.cloud.appwrite.io/v1
NEXT_PUBLIC_APP_DOMAIN=localhost # we will change it later

Now, let's initialise the Appwrite SDK in the project using:

bun add appwrite

This covers up on how to initialize Appwrite in normal Next.js project. Now we need to configure our Appwrite databases according to the project. For this demo, let's create a Posts collection to shift the mock database JStack uses as an example to Appwrite.

Defining Schema

Go to the Appwrite Console > Databases > Create Database. We will call it main , and keep it' ID as main as well:

Similarly, create a collection posts and keep its ID as posts.
Each document in Appwrite already has an unique ID attached to it, so the only attribute we need is name for now:

Lastly, you will need to define who can access your collection. To learn more about it, check out the docs for Appwrite Permissions. For now, we will set it to any:

Syncing Types

That's it, we are all set with configuration on the Appwrite Console. Now let's set it up in our project. I will also take the help of the Appwrite CLI to help me set up things faster. You can learn more about how to install it by following the installation docs.

Once done, run:

appwrite init project

? How would you like to start? Link directory to an existing project
? Choose your organization 67610b8ee51f147ca943
? Choose your Appwrite project. [object Object]
✓ Success: Project successfully linked. Details are now stored in appwrite.json file.
Would you like to pull all resources from project you just linked? Yes

Once done, let's utilize the last Types Generation feature to sync our defined types:

appwrite types src/types       

ℹ Info: Detected language: ts
ℹ Info: Directory: src/types does not exist, creating...
ℹ Info: Found 1 collections: posts
ℹ Info: Found 1 attributes across all collections
ℹ Info: Added types to src/types/appwrite.d.ts
✓ Success: Generated types for all the listed collections

Result will look something like this:

import { type Models } from 'appwrite';

/**
 * This file is auto-generated by the Appwrite CLI. 
 * You can regenerate it by running `appwrite types -l ts src/types`.
 */

export type Posts = Models.Document & {
  name: string;
}

Obviously pretty small for now, but a really helpful feature once the project expands and more collections are defined.

Configuring Code

Final steps are to connect the Appwrite backend with our tech stack. For that let's create a simple appwrite.ts file in src/lib folder:

import { Client, Databases, ID } from "appwrite";

const client = new Client()
    .setEndpoint(process.env.NEXT_PUBLIC_APPWRITE_ENDPOINT!)
    .setProject(process.env.NEXT_PUBLIC_APPWRITE_PROJECT_ID!);

const databases = new Databases(client);

export { client, databases };

Now, we can modify the original post-router.ts file to use the defined database:

import { z } from "zod";
import { j, publicProcedure } from "../jstack";
import { databases } from "@/lib/appwrite";
import { type Posts } from "@/types/appwrite";
import { ID } from "appwrite";

const DATABASE_ID = "main";
const POSTS_COLLECTION_ID = "posts";

export const postRouter = j.router({
  recent: publicProcedure.query(async ({ c }) => {
    const posts = await databases.listDocuments<Posts>(
      DATABASE_ID,
      POSTS_COLLECTION_ID,
    );
    return c.superjson(posts.documents.at(-1) ?? null);
  }),

  create: publicProcedure
    .input(z.object({ name: z.string().min(1) }))
    .mutation(async ({ c, input }) => {
      const post = await databases.createDocument<Posts>(
        DATABASE_ID,
        POSTS_COLLECTION_ID,
        ID.unique(),
        {
          name: input.name,
        },
      );

      return c.superjson(post);
    }),
});

And done! Now your JStack application is using Appwrite as its backend provider.

Testing

Start the dev server if not already by running:

bun run dev

Your application should have started on: http://localhost:3000/
Create a new post.
You should be able to see it in recent posts:

Also, the data should be visible in your Appwrite Console:

Deploying your application

Until recently, to deploy your Next.js application, you had pretty low choices. But no more Appwrite Sites. Now, you can have your backend and frontend hosted on Appwrite.

Check out these docs on how to get started with Sites - https://appwrite.io/docs/advanced/self-hosting/sites

Let's deploy your application using Sites:

Go to Appwrite Console > Sites > Create Site.
You can upload a tar file directly, or connect to a GitHub repository (I prefer the GitHub option for automatic deployments).
Select the repository:

You can keep all the settings as the default ones, just make sure to upload the environment variables we defined earlier:

Depending on the domain you are assigned / plan to use, you also need to update the APP_DOMAIN variable we defined earlier. For me I will keep it:

NEXT_PUBLIC_APP_DOMAIN=jstack-appwrite-template.appwrite.network

Click on deploy.

And done! Your application should be live 🎉

You can checkout the demo application here - https://jstack-appwrite-template.appwrite.network/

Conclusion

Let's start by answering the question the blog began with: Do I prefer JStack over T3 Stack? I'm sorry, Theo, but I do.

JStack solves the fundamental problems I have always had with Next.js:

Using Hono instead of Next.js's inbuilt convention for defining API routes.
Using TanStack query out of the box. Trust me, you should start now if you are not using it.
Type safe and uses Zod.

The most noticeable difference between T3 Stack and JStack is how light they are, mainly due to the inclusion of the tRPC protocol in T3 Stack. Although JStack also uses tRPC, it seems like a much simpler implementation of it. Most projects do not require the complexity tRPC adds, and in my opinion it makes the code 10x more complicated to maintain.

So, give JStack a shot if you are starting with a new project (or want to spend a weekend migrating your existing stack to it). Huge shoutout to Josh for creating this wonderful stack. And lastly, give Appwrite a chance to be your next all in one cloud platform, both for your backend and frontend needs.

Sources:

JStack - https://jstack.app/
Appwrite Docs - https://appwrite.io/docs
Github repository - https://github.com/ChiragAgg5k/jstack-appwrite-template

Creating Knowledge bases using MindsDB

Chirag Aggarwal — Wed, 25 Jun 2025 03:35:39 +0000

Whenever we think we knowledge base, what is the first thing that comes to our mind?

For me it had always been a library.

Hundreds of thousands of meticulously organised lines of pure knowledge. In digital form, this knowledge is what we call as data. The internet is filled with data, and with the arrival of AI harnessing its power has become easier than ever before.

But what if you wanted your own library, your own knowledge base?

In this blog, we will discuss how you can do just that, and use this library of yours to ask anything you would like using simple natural language. We will create a knowledge base of various research papers, ask it some complex questions and for fun, stress test the hell out of it.

So let’s begin!

Creating a knowledge base

As an example lets create Scholar Map, an AI-powered research assistant where you can store any research paper and query for them in simple natural language.

To get started, first setup mindsdb self-hosted instance by following these docs - https://docs.mindsdb.com/setup/self-hosted/docker

Make sure the instance is available on http://127.0.0.1:47334.

Now,

Clone the repository:

git clone https://github.com/ChiragAgg5k/scholar-map.git
cd scholar-map

Install uv package manager if not already by following these installation docs.
Sync up dependencies:

uv sync

Start the application using:

uv run main.py

You should see this:

╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│  Scholar Map                                                                                                                                                                  │
╰───────────────────────────────────────────────────────────────── Research Paper Knowledge Management System ──────────────────────────────────────────────────────────────────╯
Connecting to MindsDB...
Attempting to connect to MindsDB server...
Connection established successfully!
Setting up research papers knowledge base...

The script will automatically run the configuration code and setup knowledge base.

Demo

From student to full-time Platform Engineer at Appwrite

Chirag Aggarwal — Sat, 21 Jun 2025 14:52:08 +0000

TLDR

For those who are not really interested in reading some random university student’s story, here is a short TLDR. I worked at Appwrite as an Engineering Intern for 6 months and just got offered a full-time position as a Platform Engineer, while still being in University for another year :D

The story ahead covers how while drowning in a sea of desperation a light of hope changed everything for me, how my experience was working for a fully remote OSS company, and the challenges I faced while working in PHP, a language I had never touched before this :p

Pre-Interview

Back in September-November 2024, I was kind of at the lowest point of my engineering journey yet. I had concluded my last internship around August when the project I was working on abruptly closed, and since then I was on a constant hunt for my next one.

Silence. From all the mediums I tried - LinkedIn, Upwork, AngelList, cold DMs, and what not.

The thing is that once you start “working”, although it was an unpaid one, it’s pretty hard to go back to doing… nothing. “Nothing” is the wrong word I guess, I was still working on OSS, building projects, and trying to learn new things. But if someone asked what I was up to nowadays… i drew a blank.

Then one day I was just hanging out on Discord and saw a notification from a bright red server I usually didn’t check much. Hey, it’s another job opening, so I applied like usual. Another month passed, silence again. But then I saw an email from Emma, our People’s person at Appwrite.

“We wanna have a chat with you.”

This was a very unusual email for me. Usually, companies like to give an assignment for the first round, but here it was a direct meeting scheduled… so I already knew something was different this time.

The Interview(s)

Of course, I am not allowed to share the entire interview experience without getting into a call with Emma after this is published. So, I just want to share one question that has stuck with me since then,

“Looking at your resume, you don’t seem to have much if any experience with PHP. And Appwrite’s entire backend is in PHP. Will you be able to handle this?” - Torsten, Product Engineer at Appwrite.

Stunned. Before going to the interview I did see the codebase was written in PHP. I had never touched it before. No contributions, No issues filed. So I assumed the position I was applying for might have nothing related to this codebase… maybe a new project altogether… right? Nope.

My answer? It was somewhere along the lines of “I will figure it out, trust me, bro”.

Very bad answer I know. But it was the best I could come up with. After the interview, I went on a grind. Reading the codebase, running it, and understanding its architecture (in that process I even wrote an article - Architecture Patterns for Beginners: MVC, MVP, and MVVM). Long story short I tried to learn as much about Appwrite’s codebase as was physically possible in that timeframe from the next interview scheduled.

And Tada~ It worked. I got the offer!

Experience

Working at Appwrite is unlike working in any other place. From the first day on, even though you are an Intern, you are never treated like one. I was introduced to the entire codebase in my first week and assigned to issues not from the pending log, but actual production issues that users were facing.

You can message anyone. At any point.

Work on any issue that you like.

There is a padding issue you saw on the website? Knock yourself out and raise the PR.

The beautiful thing about Appwrite being open source is that you could do this from the very start. It’s just now I could bug anyone on the team more freely if I was stuck on any issue.

It’s hard to summarise how much work I did in the past 6 months, but here are some notable ones:

200+ PRs merged in the Appwrite organization’s repositories, including main, website, SDK, MCP, etc. repositories.
Uptime monitoring for the Appwrite Assistant.
Adding a monthly limit to the number of free Phone OTPs allowed.
Fixing Amazon and Slack OAuth adapters. Add Figma OAuth adapter.
Making several changes to SDKs and making releases.
Adding Types generation to Appwrite CLI.
Worked on the DevKeys feature in the latest Appwrite release 1.7
Added 2 blogs on the website - self-hosting using coolify and announcement for DevKeys.
Taking leadership on the Synapse project, operating system gateway for remote serverless environments.
Adding new phone OTP adapter - Inforu, which reduces pricing for phone OTPs for Israeli users by 11x.
and… a lot more.

Honestly looking back at it, I never realized I worked on so much. It feels like I had just joined Appwrite yesterday.

Thank You

At last, I wanna thank the entire Appwrite team for treating me like part of the team since day one, and for giving me this opportunity. Let’s build like a team of hundreds_

You can check out my profile to learn more about me - https://www.chiragaggarwal.tech/

Hit me up on any socials if you have any doubts, I am always up for a chat :D

Automate anything - Making research analysis effortless

Chirag Aggarwal — Sat, 14 Jun 2025 05:13:48 +0000

Starting with a research project can be overwhelming.

There are so many data points to consider, so many hours of reading to do, and within all that chaos, the hardest piece of the puzzle to find is a starting point.

I faced this first hand when last year I had to work on multiple papers to earn a single credit point for my engineering degree. Unfortunately why universities force this pointless system is not the spotlight of today’s discussion.

Instead, we are going to discuss how you can cheat on this mundane activity using Runner H.

The article will redefine how you interact with AI, helping you put together analysis, execution, summarisation and integration with a single prompt.

So, let’s dive in.

Researcher’s Dilemma

Whenever you start with a research project, the first question that comes to mind is: "Has this been researched before?"

Answering this question is crucial for:

Avoiding duplication of work
Finding gaps in the existing study
Not claiming something as noble when it has already been done before

However, doing this is a very manual process, and requires hours and hours of find papers, reading them and doing accurate analysis.

Meet Runner H

Ever tried using Perplexity or ChatGPT in research mode?

Think of Runner H as that, but on steroids.

Runner H is an advanced AI-powered web automation tool that lets you perform multi-step online tasks using natural language instructions. It seamlessly integrates with services like Slack, Notion, Gmail, and Excel, enabling you to create complex workflows, no coding experience required.

For our purpose, we can use Runner H to:

Quickly identify similar research papers with a Google Scholar scan.
Assess similarities between them and your topic using AI.
Scan the internet to find gaps between the existing work.
Export the findings in a structured format.

The prompt

Below, I have crafted a prompt that you can copy and paste into Runner H, replace with the topic you need to research, and voila~, see the magic unfold:

Analyse if my research idea, {YOUR_RESEARCH_IDEA}, has been previously explored. Search Google Scholar for similar research papers. For each, extract the title, authors, publication date, abstract, journal/conference, and similarity percentage to my idea, and note any research gaps mentioned or left open. Create an Excel file summarising all findings.

Just replace {YOUR_RESEARCH_IDEA} with the idea you want to research on.

Demo

Let’s try researching on a topic:

“The impact of generative AI tools on student learning outcomes in higher education”

So Runner H after doing all the analysis and hard work for us was able to generate a structured output. Unfortunately, even though prompt specifically asks for Excel format, most of the times for me it generated a PDF format for me. Still Runner H is still in early phases and hopefully will be improved in future by the team.

So what makes Runner H different?

One of the most fascinating differentiations I found in Runner H compared to other agentic tools was its ability to search, summarise and synthesize as well. Instead of just dumping in raw results, it evaluates the relevance of each paper, highlights the overlaps and gaps in the study, and presents it in an actionable format.

Using Runner H has completely transformed my approach to starting a research topic. It has bridged me to the starting point where I used to struggle the most. For students, academic professionals, and anyone doing any sort of research work, Runner H is a game changer.

Happy researching! If you have questions or want to share your own experiences with Runner H, drop a comment below.

Vibe coding an Email Ticket Automater using Postmark

Chirag Aggarwal — Sat, 31 May 2025 02:44:00 +0000

This is a submission for the Postmark Challenge: Inbox Innovators.

What I Built

Support tickets…

Nobody really loves either writing or much worse reading them. And managing them is much much worse than managing my laundry, and that is a really high bar to pass.

So, in a world where we all are writing and summarising emails for the sake of maintaining formality, automating support tickets seems like the logical next step.

And sure there are companies that do this… not really going to name them, but my vision here was to just create something that takes the unorganized text and convert it to organized boxes, while still being pretty to look at… cough Jira cough.

Meet EmailTicket. Firstly hoping that marks are not being deducted for the lack of naming creativity, it's here to do exactly what it says. Create tickets based on emails. Sounds simple right? Well kind of… but with some headaches.

Historically, when creating tickets you would have to ask the user a bunch of information like whether it is a billing issue, a bug, or feedback, when did the issue start, etc.

After creation, you would have to manually keep track of information like how urgent is it. Has the ticket been closed or is it still in progress? etc. etc.

You know… the boring stuff.

Image captured during the pre-AI times (just kidding it was created using ChatGPT)

But with AI, we no longer need to take care of that stuff. Just give it a random block of text and out comes structured beauty (It’s like a dream come true for data scientists honestly).

This is pretty much what Email Ticket does for now. It’s highly inspired by platforms like HelpScout (an amazing tool btw do check it out) and in the future can extend a lot more if good guys like the ones from Postmark support it :D

Demo

Checkout the live link here - https://email-ticket-automator.vercel.app

If your emails are stuck on processing/waiting, It’s highly likely that I ran out of the 100 free emails. So… don’t sweat too much about it 😅

Code Repository

ChiragAgg5k / email-ticket-automator

AI-powered helpdesk platform leveraging email-parsing by Postmark

📧 Email Ticket

A modern, AI-powered helpdesk platform that transforms email support into an organized ticket management system. Built with React, TypeScript, Postmark, and Appwrite for seamless customer support experiences.

🏹 Quick Start

Prerequisites

Node.js 18+ and npm
Postmark account for email parsing
Appwrite account for backend services

Installation

Clone the repository

git clone https://github.com/ChiragAgg5k/email-ticket-automator.git
cd email-ticket-automator

Install dependencies
```
bun i # or npm install
```
Configure Appwrite
- Create an Appwrite project at cloud.appwrite.io
- Update the configuration in src/lib/appwrite.ts:
```
client.setEndpoint("YOUR_APPWRITE_ENDPOINT");
client.setProject("YOUR_PROJECT_ID");
```
Start the development server
```
bun dev
```
Open your browser Navigate to http://localhost:8080 to see the application

🛠️ Tech Stack

Frontend

React - Modern React with hooks and functional components
TypeScript - Type-safe development experience
Vite - Fast build tool and development server
Tailwind CSS - Utility-first CSS framework
shadcn/ui - High-quality, accessible UI components

Backend & Services

…

View on GitHub

How I Built It

So most of the application is vibe-coded using Lovable. Was it because I am lazy? Probably yes. But that’s not the exact reason. In my opinion tools like Lovable, V0, Firebase Studio (god there are so many now), etc. are perfectly fine to use to get an initial MVP of your idea up and running.

And in a world where AI is dominating the entire development process, not utilizing these tools is just slowing you down.

So let’s talk about the 10% of coding I actually did.

The first was integration with a database. Or more specifically a Backend as a Service because who codes their own backend nowadays? So naturally I went with Appwrite. Lovable refused to do this integration, but thankfully Appwrite is extremely easy to set up. I used it to implement Authentication flow, as well as Database for ticket storing and retrieval.

Next was the start of the application, Postmark. Postmark made the entire process of receiving an email, parsing it into JSON, and receiving it just via an API call so easy, I forgot dealing with emails was such an annoying task.

Firstly, I needed to A) Either get inbound domain forwarding setup, or B) Get my account approved to be able to send emails to the default inbound email address with no domain restrictions. I tried both techniques and luckily got my account approved in 2 days!

Not so luckily I was never able to set my inbound domain even tho I had my MX record set properly and could verify it using https://www.whatsmydns.net/ (You can check my comment here complaining about it - https://dev.to/chiragagg5k/comment/2o6hi). So something to note down @Postmark team.

To utilize the API seamlessly without ever needing to touch a single line of actual backend code, I came up with this flow:

Appwrite triggers a “create” document/ticket event.
The event triggers a function that then calls the Postmark’s API for sending an inbound email.
Postmark listens to the inbound email and triggers an email parsing flow.
After parsing is done it returns the output to a webhook URL which is just an Appwrite function.
The Appwrite function finally processes the parsed content and stores it back to the database.

Finally time for structured outputs. Almost all LLMs offer a way to generate structured outputs now in their APIs. Here are some docs I found for this:

and on and on…

(a small plug would be to check this repo I worked on which allows you to use any LLM with structured outputs and consistent syntax in PHP - https://github.com/utopia-php/agents)

You can check the repository code itself to see which one I picked because I might have changed it by the time you are reading it :p

That’s it then. Let me know in the comments how was your experience using EmailTicket Automater. You can reach out to me on any of my social media links if you have any queries or just wanna have a casual talk. A big shoutout to Postmark for arranging this contest and letting me have fun with their platform, as well as my company Appwrite for supporting the application’s backend :D

Bye!

Focus on the product, not the tech stack

Chirag Aggarwal — Wed, 14 May 2025 16:48:53 +0000

Recently I got this DM,

“Which tech stack should I learn?”

“Should I use Next.js or Svelte?”

“Is Python better for the backend than node?”

I am sure we have asked or been asked questions like this several times in our tech journeys. As someone who is just starting out, I think it seems like a very important thing to ask. You don’t wanna waste your time learning a technology that might become worthless soon? Or isn’t fast enough? or isn’t the “industry standard”… right?

Or should it matter?

Languages are just tools

Back in 2003 when Facebook was originally founded, its backend was written in PHP. Was it the lack of options? You can say so. Back then they certainly didn’t have a plethora of frameworks or hell even languages to choose from. But what about now? Realistically PHP should be dead by now…

Right?

But if you look at the statistics by Kinsta, around 79.2% of the internet still relies on PHP to some degree. Okay, but that number has to be declining for sure!

But wait...

Nope, it has been on a steady increase since 2011, peaking at 80.6% in 2015, and maintaining a steady line.

But how?

It’s because language is just a tool. It does not matter how many new bleeding edge languages enter the market increasing the performance metrics by some fractions of seconds, as long as a ~~tool~~ language sufficiently fulfills its job, it will stay relevant. PHP has done a great job at that. It’s constantly evolving as well, something which is direly required to stay alive in the software world.

So next time if someone asks you “Which language should I choose?”, ask them two things:

Which language are you more comfortable with?
Do the other languages provide a set of features more beneficial for your use case? Even if so are they worth the effort to learn? (arguments like uh it's 0.001sec faster should not be relevant)

It’s OK to not upgrade

Image from: https://foreverealize.me/posts/how-to-update-dependencies/

I was once asked, “Why is your website still at Next version 13 when 15 has arrived?”

To which I ask, why does it matter? Sure software is meant to be ever-evolving, but that doesn’t necessarily mean it's a good idea to always hop on the upgrade bandwagon without looking at the consequences.

This in this case will be a complete re-write since Next 15 introduces a ton of breaking changes.

And it's OK not to upgrade every time.

Judge a product by its usefulness, not complexity

A lot of people especially those building projects just for improving their resume will try to make them extremely complex. It will be a wobbly mess of high-end sounding technologies like SSR, TRPC, GraphQL, Kubernetes, Redis, etc.

Sure I do understand the thinking behind this, it does show your ability to work with complex technologies.

But in the age of AI and the really fast-moving pace of technology, it's pretty trivial for someone to learn technologies on the go and incorporate them into their project. Real engineering will always be that “solves a problem, not create one”. Solving problems always requires asking questions first:

Does your project really need TRPC or GraphQL? Why not just use REST like everyone does bruh?
Do I really need Kubernetes for those 5 concurrent connections?
Does my really interactive website need SSR where then each button click will be a server action and take ages to process any action?

And please, stop building clones. It does not matter:

how many services you use in it
how much knowledge you gained from creating it
how complex the project was to make

The YouTube clone you made by following a random Youtuber’s 8-hour-long guide is not going to help you in any way.

Quoting Theo (idk where he said tho):

To build a great product, you need to first be a customer

If you want project ideas, look around you. Try to solve problems you face every day. If you just try looking, you WILL find many.

Final words

This blog is a summary of my (I admit very short-lived) experience of working in tech till now. I always tried not to treat tech as something I specialize in, but as a tool that helps me solve problems.

I started off my journey in web with a simple problem, I just wanted a website of my own because it would be cool :D

Then a simple problem gave birth to more problems with a chain reaction ongoing, to me finding myself working with PHP, something I would have never imagined doing in a million years before.

So…. that’s it. Keep building and showcasing your work, and most importantly, have fun at it!

Debugging with Source Maps: A Comprehensive Guide

Chirag Aggarwal — Sun, 09 Mar 2025 18:44:24 +0000

We all have been there, working on a new feature for 10+ hours straight, and everything is going well. You build your project and push the code to production. And boom, a new production error alert! Everyone in your team - whether at a company or a hackathon - starts to look for someone to blame. Found it; it was from you. But none of your test suites resulted in an error. Everything with the code itself looks excellent.

You check the logs. The error is:

Uncaught Error: Cannot read property 'xyz' of undefined at app.min.js:1:45678

You think to yourself, what the heck is app.min.js:1:45678 supposed to mean? There was no file like that in the entire source code? Your file was called app.js. And it's 45678 characters long! That's impossible to debug!! Still, you try to open the file and potentially find the root cause of the error. It's a mess. The entire file is filled with random gibberish you are unable to understand. What should you do?

Now, this is where Source Maps come into play. Source Maps allow you to map the minified code in your production environment, aka the random gibberish you just saw, with the actual source code, allowing you to pinpoint the root cause of the error in your source code and debug it effectively.

In this blog, we will detail what source maps are, why and how they are created, and give some tips on effectively using source maps to debug your code. Let's dive in!

Why is source code minified?

Before we delve into Source Maps, let's first decode what happened to your clean, formatted and linked source code and why it looks nothing like it on the browser.

The simple answer is minification.

Minification is the process of converting your source code into production-ready code without changing any of its functionality. This is typically done by the bundler you are using, such as Webpack. To learn more about bundlers, you can check out this awesome guide on Javascript bundlers by Snipcart.

Simply put, bundlers optimise your source code by stripping out whitespaces, comments, and redundant code and even removing or renaming variables for shorter alternatives. This makes your code super efficient and much smaller in size.

Why does this happen?

Improved load times - Smaller file sizes lead to better website loading times.
Obfuscation—Although it won't make your code entirely illegible, it does make it harder for regular users to understand.
Browser Performance - The code is altered in a way that's easy for browser engines to parse.

Here is an example of what a minified React app code looks like:

bundle.js file created by Webpack on building a simple React app, even the text is overflowing from the terminal screenshot!

What are source maps?

Source maps are files whose names end with .map and that map the minified code to your actual source code. Examples of such files can be example.min.js.map or for css, styles.css.map. They are explicitly generated only by build tools like Webpack, Vite, Rollup, Parcel etc. Since source maps are only required for debugging purposes, these tools usually have the option to generate source maps off by default. For example to enable it in Webpack, you can do:

// add this to your package.json file
"scripts": {
    "build:dev": "webpack --mode development --devtool source-map",
}

or add it to your webpack.config.js file:

module.exports = {
    devtool: 'source-map',
    // ...rest of your config
}

A source map includes crucial information on how the mapping is done, including the actual source file name, the content it includes, various variable name the source code has, name of the minified code file etc.

Here is a format of how a typical source map file looks like:

{
  "mappings": "AAAA,SAAQA,MAAMA,QAAQ,OAAO;AAC7B,SAAQC...",
  "sources": ["src/index.js"],
  "sourcesContent": [
    "import React from 'react';\nimport { createRoot } from 'react-dom/..."
  ],
  "names": ["React", "createRoot", "App", "count", "setCount", "useState", ...],
  "version": 3,
  "file": "bundle.js.map"
}

The most important section here is mappings. This uses a special kind of encoding called VLQ base 64 encoded string to map the lines and locations to compiled file and its corresponding original file.

Visualising source maps

"Okay, great!" I hear you saying. "How is this actually helpful? I still can't read the source maps and manually decode the mappings."

That's a great question! This brings me to the main highlight of this blog—source map visualisers. These tools allow you to see the mappings in a visual manner to locate and debug the problem effectively. There are many source map visualisers on the market, but today, we will be focusing on Sokra & Paulirish's source map visualization. You can find the source code for this on their Github Repository.

Here is a side-by-side comparison of how your code (on the right-hand side) can look like a jumbled mess when minified (on the left-hand side). However, the colour-coded mapping of the visualiser helps us map these two codes by hovering over them.

Working Example

Let’s create a simple React app and play around with it’s sourcemaps!

Start with creating a project directory:

mkdir my-project
cd my-project

Init a new project:

npm init -y

Add the following dependencies into package.json

{
  "name": "react-counter-app",
  "version": "1.0.0",
  "description": "Simple React Counter App",
  "main": "index.js",
  "scripts": {
    "start": "webpack serve --mode development",
    "build": "webpack --mode production",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@babel/core": "^7.23.0",
    "@babel/preset-env": "^7.23.0",
    "@babel/preset-react": "^7.22.15",
    "babel-loader": "^9.1.3",
    "css-loader": "^6.8.1",
    "html-webpack-plugin": "^5.5.3",
    "style-loader": "^3.3.3",
    "webpack": "^5.88.2",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "^4.15.1"
  }
}

Create a src/index.js file with following React code:

// src/index.js
import React from 'react';
import { createRoot } from 'react-dom/client';
import './styles.css';

function App() {
  const [count, setCount] = React.useState(0);

  const increment = () => {
    setCount(count + 1);
  };

  const decrement = () => {
    setCount(count - 1);
  };

  return (
    <div className="app">
      <h1>Counter: {count}</h1>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
}

// New React 18 createRoot API
const container = document.getElementById('root');
const root = createRoot(container);
root.render(<App />);

Add styling by adding a src/styles.css file:

/* src/styles.css */
.app {
  font-family: Arial, sans-serif;
  max-width: 500px;
  margin: 0 auto;
  padding: 20px;
  text-align: center;
}

button {
  background-color: #4CAF50;
  border: none;
  color: white;
  padding: 10px 20px;
  text-align: center;
  text-decoration: none;
  display: inline-block;
  font-size: 16px;
  margin: 10px;
  cursor: pointer;
  border-radius: 4px;
}

button:hover {
  background-color: #45a049;
}

Now define the webpack config by creating a webpack.config.js file in the root folder:

// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env', '@babel/preset-react']
          }
        }
      },
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './public/index.html'
    })
  ],
  devServer: {
    static: {
      directory: path.join(__dirname, 'public'),
    },
    port: 3000,
    open: true
  },
  resolve: {
    extensions: ['.js', '.jsx']
  }
};

Now you can start the application by running:

webpack serve --mode development

This is how it should look (very basic i know :D):

You can find the source maps using your browser's dev tools. The format can look different depending on the browser you are using. Here, I am using Zen, but the format should look similar for all browsers.

You can do so by right-clicking anywhere on the page and clicking on Inspect Element. Then, go to the Sources section of your browser and find the source file. Here on Zen, it's available in the debugger section since it's mainly used for debugging purposes.

Now, you can load this in the source-map-visualization. It will look something like this:

On right you can skip all the React code and skip to the section that contains just your code. On hovering over each section of your code you will see exactly which part of the minified code it maps to!

It can look pretty confusing at first, but try hovering over various elements in the UI and you will see how intuitive it actually is. For eg. in this example code,

React.useState(0) ----> t().createElement("h1",null,"Counter: ",n) .... // so on

Hovering over React.useState reveals that it maps to a createElement in the minified code. So our bundler, Webpack, in this case, optimised our code by directly converting our state into a javascript element and directly modifying it in subsequent code. This makes our application much, much more performant and reduces the file sizes the browser has to load!

Security Considerations

While creating the example app, you may have noticed we had to explicitly add the flag --mode development to the Webpack run command. This is because source maps are supposed to be used for debugging purposes only, and can lead to security concerns when used in production, including:

Concern	Description	Mitigation
Exposing Source Code	Source maps reveal your original code, including comments and logic	Use `hidden-source-map` or `nosources-source-map` in production
IP Protection	Intellectual property may be exposed via full source maps	Deploy source maps to secure, authenticated location
File Size	Source maps can be large, affecting download performance	Generate maps only in development, or serve separately
Server Configuration	CORS issues may prevent source map loading	Configure proper `Access-Control-Allow-Origin` headers

There are also tools like Sentry or Rollbar which use your source maps for better error reports without violating any of the security concerns. Tools like these are considered best practise for production environments.

Conclusion

Source maps are a mind-blowing feature that lets you map your source code precisely to the minified code loaded by your browsers, which is generated by bundlers like Webpack for performance and speed. We explored how debugging can be made easy using this feature and tools like source map visualisers to aid in the process.

The web is built on top of layers and layers of abstractions done by tools like bundlers, but when things go catastrophically wrong, we might discover that these abstractions are not always hundred percent perfect, and hence, we need to take out our tools, look under the hood, and find the fix ourselves.

To learn more about package managers like NPM, Bun, PNPM, and yarn, you can check out my other article, Mastering npm: A Comprehensive Guide to Package Management.

References

Thanks to these fantastic references by the Google Chrome dev team that helped me learn about source maps myself and in writing this article:

Writing Event-Driven Serverless Code to Build Scalable Applications

Chirag Aggarwal — Sun, 26 Jan 2025 17:12:20 +0000

Serverless isn't just trendy—it's rewriting how software scales.

Netflix streams billions of hours without servers. Coca-Cola automates workflows without infrastructure. Figma and T-Mobile ditch downtime. What do they know that you don't?

The secret? Event-driven serverless code. It's the backbone of apps that scale instantly, cut costs, and survive traffic spikes. No servers. No guesswork. Just code that reacts.

This isn't hype—it's a blueprint. Ready to build smarter? Let's break down how event-driven serverless turns scalability from a challenge into a reflex.

Brief Intro to Serverless

Spoiler alert: servers are still there.

There are multiple definitions for this term online, often filled with complex jargon. The best way I like to define it is:

A "fashion" of deploying your code where YOU don't have to think about the servers running your code.

Let's take an example:

Take Bob. He built mytrashcode.com but panicked at "server setup." He's a developer, not a sysadmin. Instead, he uploaded his code to a cloud provider. They handled security, scaling, and traffic—his site went live. No late-night server meltdowns. No panic during traffic surges. Done.

Why Can't I Manage My Own Servers?

Managing your own servers usually takes one of two paths. You either run physical hardware—like turning an old laptop into a DIY server—or rent a Virtual Private Server (VPS) from providers like DigitalOcean Droplets, Azure VMs, or AWS Lightsail. These fall under IaaS (Infrastructure as a Service), where the cloud company provides the bare-metal infrastructure, but the rest—updates, scaling, security—is entirely up to you.

Does this mean self-managing servers is impossible?

Not at all. Plenty of teams still do it. But managing your own servers comes with a lot of... challenges, including:

Knowing how to manage infrastructure/hardware.
Setting up auto-scaling and downscaling.
Periodically applying system patches and updates to avoid exposing vulnerabilities.
Configuring proxies, SSL certificate generation, network settings, etc.

Dividing Your Code into Functions

Serverless code doesn't need to be monolithic, i.e., all code doesn't need to be in the same place. It can be a collection of bite-sized, event-triggered functions.

A Function is nothing but a set of code that performs a specific task. When writing your entire code serverless, you'll find that you can divide your code into various functions, each handling a specific part of your application. Let's understand this more deeply with an example:

When Bob first logs into mytrashcode.com as a new user, the system triggers a "send welcome email" function before redirecting him. Subsequent logins bypass this function entirely, routing him straight to the dashboard. This separation serves a critical purpose—while 99% of users interact solely with the dashboard, isolating secondary functions (like email triggers) enables independent scaling.

Though trivial in this example, the cost implications compound dramatically at scale. Each decoupled function operates on its own resource allocation curve—high-frequency features like dashboard access demand consistent infrastructure, while one-time actions (welcome emails) can scale down during inactive periods. This modular approach prevents overprovisioning for rarely triggered events, even before considering complex systems with hundreds of interdependent functions.

Where to Deploy???

Okay, so just a quick recap—we now know:

Deploying serverless is great!
Dividing your code into functions is modular and scalable.
Functions can be triggered by events.

So, where do you deploy this architecture? Leading platforms like AWS Lambda, Azure Functions, and Google Cloud Functions support it, but we'll focus on Appwrite Functions.

Appwrite, an open-source Backend-as-a-Service (BaaS), bundles authentication, databases, storage, and serverless functions into a single toolkit. This tight integration streamlines deployment—instead of managing fragmented cloud services, Appwrite centralizes backend logic, letting you deploy event-driven functions with minimal overhead. For developers prioritizing simplicity without sacrificing scalability, this unified approach reduces operational friction significantly.

So, let's deploy our function!

Deploying Your First Function

Before writing code, set up your backend on Appwrite:

Go to appwrite.io and register or log in.
Create an organization (if new).
Create a new project.
Copy your Project ID for later use.

Now, let's simulate a server-side project using the node-appwrite package:

Create a project directory:

mkdir my-project  
cd my-project

Install the Appwrite CLI and initialize your project:

npm init -y  
appwrite init

Install dependencies:

npm install dotenv node-appwrite

Create your function using the Appwrite CLI:

appwrite init function

For the runtime, I selected Node 20, but you can choose any runtime.

Write your main function in src/main.js:

import dotenv from "dotenv";
import { Account, Client, Users } from "node-appwrite";

dotenv.config();

const client = new Client();
client.setEndpoint("https://cloud.appwrite.io/v1");
client.setProject(process.env.PROJECT_ID);

const users = new Users(client);
const account = new Account(client);

const main = async () => {
  await account.create(
    "test-user",
    "test@test.com",
    "test@123",
    "test",
  );
  const session = await account.createEmailPasswordSession(
    "test@test.com",
    "test@123",
  );
  console.log(session);
};

main();

Add a start script in package.json to run node src/main.js.
Create a .env file with the required environment variables.

This function simulates a new user creation and login, logging the session details.

Note: Replace the email IDs with actual emails to receive the email.

Now, let's set up the function logic. Navigate to functions/your-function where your function resides.

For this demo, we'll use Resend to send emails:

Install the resend package:

npm install resend

Update src/main.js with this code:

import { Resend } from 'resend';

// https://appwrite.io/docs/advanced/platform/events
export default async ({ res, req, log }) => {
  const resend = new Resend(process.env.RESEND_API_KEY);

  await resend.emails.send({
    from: 'hello@yourdomain.com',
    to: req.body.email,
    subject: 'Hello!',
    text: 'Hi, its nice to meet you!',
  });

  log('Email sent successfully');

  return res.json({
    success: true,
    message: 'Email sent successfully',
  });
};

You need to set up an account on Resend to get the API Key. Resend also requires you to connect to your own domain to send emails. You can read more about it on the Resend docs.

Now, let's push the created function to the console using:

appwrite push functions

The final step is to set up the event that connects the two pieces of code together using the users.*.create event:

Go to the Appwrite console and navigate to your created project.
Navigate to the Functions tab.
You should see your newly created function there—click on it.
Go to its settings and under the Events section.
Add a new event to trigger this function: users.*.create.

And... voila! Your program is done. If everything is set up correctly, running your main script should send the newly created user an invitation email. Try it using:

npm run start

Conclusion

In conclusion, serverless architecture is more than just a passing trend—it's a transformative approach to building and scaling modern applications.

Platforms like Appwrite further simplify the process, offering a unified backend solution that integrates seamlessly with serverless functions. Whether you're a solo developer like Bob or part of a larger team, adopting serverless can turn scalability from a daunting challenge into an effortless reflex.

Thanks for reading!

You can also connect with me here: https://www.chiragaggarwal.tech/

DEV Community: Chirag Aggarwal

How utopia-php/client keeps fixing our memory leaks

What was actually leaking

What the library is

Which specs it holds itself to

PSR-18 decides what counts as an error

Retrying, and why only some requests get to

withBaseUri() is not string concatenation

Everything else is a header you'd otherwise hand-roll

The four rules underneath

Reuse over recreate

Every with*() returns a clone

Policy lives in decorators

Bounded memory by default

Where it ended up

What we grep for now

Reference

The specs

The code

Background

How I built the Appwrite MCP server (and decided to hide most of its capabilities)

The stdio years

Authorization ate the schedule

Sessions, and then no sessions

Off-topic, but why not REST?

Tool choice

Four tools over 981

Where it landed

What I'd tell anyone building one

Managing multiple docker hub accounts using docker-use

The idea

What it looks like

How it works

Things I'd flag if you read the source

Install

How we solved logging at Appwrite

What we had

Our solution

Why not just make the logger methods static?

Exporters

Before and after

JStack + Appwrite: A Match Made in Heaven for Modern Web Development

Getting Started

Initialising Project

Defining Schema

Syncing Types

Configuring Code

Testing

Deploying your application

Conclusion

Sources:

Creating Knowledge bases using MindsDB

Creating a knowledge base

Demo

From student to full-time Platform Engineer at Appwrite

TLDR

Pre-Interview

The Interview(s)

Experience

Thank You

Automate anything - Making research analysis effortless

Researcher’s Dilemma

Meet Runner H

The prompt

Demo

So what makes Runner H different?

Vibe coding an Email Ticket Automater using Postmark

What I Built

Demo

Code Repository

ChiragAgg5k / email-ticket-automator

AI-powered helpdesk platform leveraging email-parsing by Postmark

📧 Email Ticket

🏹 Quick Start

Prerequisites

Installation

🛠️ Tech Stack

Frontend

Backend & Services

How I Built It

`withBaseUri()` is not string concatenation

Every `with*()` returns a clone