DEV Community: Canercan Demir

Every Dev Has the New-Project Itch. Rapid Prototyping Makes It Creative.

Canercan Demir — Thu, 09 Apr 2026 15:07:24 +0000

Inside every developer lives a second self — the one who wants a new project the moment they get bored with the current one.

Most advice says you should fight that self. Discipline. Focus. Finish what you start.

I think that's wrong. 99% of the ideas that second self hands you really are going nowhere. But the 1% is worth every other one combined — and the only way to find out which is which is to let the second self speak, fast.

Tutorial hell is when you follow step-by-step guides without actually understanding them. You open a "Build X with Y" article, you type the code the author tells you to type, you rename a few variables, and six hours later you have a thing that runs. It looks like you learned something. You didn't. You learned the shape of someone else's decisions — their project layout, their preferred libraries, their stylistic quirks — but you didn't make a single call of your own. The moment your own idea diverges from the tutorial by one step, you're stuck. You close the tab, tell yourself you need "more practice", and open the next tutorial. Repeat for years.

Rapid prototyping looks similar from the outside: you start, you don't finish, you move on. The content is completely different. You make every decision yourself. You don't know the "correct" way to do it, so you pick the shortest path. The result is ugly but it's yours, and every line of it represents a choice you made — which means you can extend it, break it, debug it, or throw it away on purpose.

Concrete example. Say the idea is a habit tracker.

Tutorial hell version: "I'll follow a 'Build a Habit Tracker App' tutorial." Six hours later you've typed the code the author told you to type. You have something that runs. If someone asks you why useEffect has an empty dependency array, you shrug. If you want to add a feature the tutorial didn't cover, you go hunting for another tutorial. Somewhere along the way the original idea of "a habit tracker" became irrelevant — you're just solving the puzzles the author gave you.

Rapid prototyping version: "Can habits be tracked with a bash alias that appends to ~/.habits.txt?" Thirty minutes later, yes they can. Next morning: did you actually use it? No → the idea was the problem, not the stack. Delete it. Yes → now you have a signal that something is worth building, and you already know the minimum it has to do.

The difference isn't how much time you spend. It's who made the decisions.

Tutorial hell answers: "Did I finish the tutorial?"

Rapid prototyping answers: "Does this idea even work?"

Those are not the same question. And the side-project graveyard in most developers' GitHubs is full of answers to the wrong one

Rapid prototyping's real superpower

Here's what I missed for years: the point of rapid prototyping isn't speed. It's feasibility.

When you start a project the traditional way, you commit before you know anything. Two days of setup, one day picking a UI kit, half a day deciding between Postgres and SQLite — and you've spent a week on the question "what stack should I use?" before you've touched the question that actually matters: does this idea work at all?

Rapid prototyping inverts that order. You answer the second question first. You build the ugliest possible version of the idea — a single HTML file, a bash script, a route that returns JSON — and you look at it. Not the code. The thing the code does. And you ask: is this useful? is it fun? does it solve the problem I thought it did?

Most of the time, the answer is no. That's the part people don't want to hear. Most ideas that look brilliant in your head collapse the moment they exist in the real world. You only find out by making the cheapest possible version first.

Here's the reframe that finally clicked for me. The second self — the voice inside every developer that wants a new project every time the current one slows down — isn't what needs fixing. The cost of listening to it is. When that cost is two weeks of setup per impulse, you either fight the second self with willpower, or you end up in a graveyard of half-finished folders. When the cost is two hours, you can let it speak. You can try the thing. Most attempts still collapse — but you find out in an afternoon instead of a month, and the attempts that don't collapse have already proved themselves before you commit to them.

That's the real move. Not "follow every impulse." Not "ignore every impulse." Reduce the price of every impulse until it stops mattering whether the impulse was right. Feasibility testing by default, built into the way you start.

Which brings me to the thing I actually built.

The thing I built: PointArt

A month ago, PointArt didn't exist. My default stack was Spring Boot — that's what I reach for when I start anything serious. Then a client asked for something simple: just a website. Nothing that justified spinning up a JVM.

I'd written PHP years ago and hadn't touched it in a while. Sitting with the brief, I started remembering how cheap PHP can be, shared hosting for a few dollars a month. Aggressively un-cool and aggressively cheap. But I didn't want to give up the parts of Spring that made me productive: JPA, dependency injection, attribute-based routing. Those aren't luxuries once you've built real apps with them — they're how you move fast without shooting yourself in the foot.

So I built my own. PointArt is a PHP microframework with zero dependencies that runs on the cheapest shared hosting you can find and carries the Spring-shaped programming model I was used to. Attribute routing. Dependency injection. An ORM with repositories.

The original reason for building it was one client site. But once you have a framework you trust, everything downstream gets cheaper — and that's where the ratchet came from. My cold-start cost for a new prototype dropped from a week to an afternoon, and every idea I'd been putting off became worth trying.

The first thing I built on top of it was a RAG system — an AI retrieval-augmented-generation demo for a different idea I had been sitting on. I never published it. The prototype took an afternoon and it answered the question: does the idea work? (Not really.) But more importantly, it answered the question the framework actually needed: what's annoying about writing a real app on this thing? The first round of framework fixes came directly out of that RAG prototype. Nothing about the RAG itself survived. Everything I learned about the framework did.

The second thing had a longer runway than PointArt itself. I took a game design course in college and I've been a quiet fan of browser-based games for years — the kind you open in a tab with no install, no launcher, no friction. Recently I'd stumbled across Phaser.js and realised I finally had the right tool to make one myself. The PointArt prototype was the excuse I'd been waiting for.

So I built GameHub — a browser-based game platform with a dot-com era deckbuilder called DotCom Broker 98 as its first resident. It's in beta right now at PointArt GameHub. Everything runs in the browser: no download, no install, no app store. The game itself is fully web-based and server-authoritative, so the client can stay as dumb as Phaser allows.

That's three live pieces in about a month:

PointArt — the framework itself, live at pointartframework.com
The PointArt website — the docs + marketing site, built on the framework itself (eating its own food from day one)
GameHub — in beta, the first real load test for the framework at scale

Plus one unpublished experiment — the RAG — whose only lasting purpose turned out to be sharpening the tool that built the next two.

That's what the ratchet looks like in practice. The graveyard version of this same month would have been three half-finished folders in my Projects/ directory and nothing to show anyone. The ratchet version is three URLs, one platform, and a pile of concrete lessons heading into whatever I build next.

Fundamentals first, then speed

Everyone quotes Kent Beck's "make it work, make it right, make it fast" — and most solo devs get it exactly backwards. They try to do all three at once on a brand-new prototype. They reach for the perfect ORM before they've validated the idea. They argue about what database to use before they've written a single line of feature code. Then they stall out, call it a "focus problem", and move on to the next project.

Kent Beck wasn't handing us three boxes to tick simultaneously. He was handing us three gates. Make it work — and only after the thing actually works, and only if it deserves to exist, do you graduate it to "make it right". Only after "right" is meaningfully right do you earn the question of "fast". The gates are the whole point. Skipping the gates is what kills solo projects, not the order itself.

Rapid prototyping, stripped of the buzzword, is just phase 1 taken seriously. Make it work. Don't worry about refactoring — you haven't earned that question yet. Don't worry about performance — you don't have users yet. Just: does this thing, in its ugliest possible form, answer the question I set out to ask? If yes, you graduate it. If no, you delete it and move on without guilt, because you never paid the "right" tax on an idea that didn't deserve it.

There's a catch, though. Phase 1 is only cheap if you can actually write phase-1 code. "The ugliest possible version" still has to be real code that runs. If you don't know your language well enough to throw something together without looking things up every thirty seconds, phase 1 isn't a two-hour sprint — it's a three-day tutorial hunt. Which is exactly the thing you were trying to escape.

I wrote a whole separate post about this fundamentals half: "The Hidden Cost of Framework-First Thinking.". Short version: reach for a framework after you've written the thing it abstracts away at least once, not before. The same principle applies here — you earn the right to prototype fast by having written the boring, foundational version first. Once that knowledge is in your hands, the ugliest-possible-version is an hour, not three days.

So the order matters. Fundamentals first. Framework second. AI third. Get any of those in the wrong order and the whole stack collapses into a different flavour of tutorial hell.

The order matters because of the symmetric case. Without language fundamentals and a framework you trust, AI output has nothing to land on. You can't verify what you don't understand, and you end up stacking generated code on top of generated code, chasing bugs that move every time you regenerate. That's not a problem with the AI — the tool is fine, it's the ground underneath that's missing. It's the same pattern as copy-pasting Stack Overflow without reading the answer first: the shortcut only works if you already understand what it's shortcutting. Once that's true, the same AI goes from noise to leverage overnight.

Speed without understanding is just faster mistakes. Speed with it is leverage.

If you're reading this and thinking "this sounds great, let me go start prototyping fast" — maybe. If you know your language well enough to catch === when it should be hash_equals(), yes. If you don't yet, do that first. It's the best investment you'll ever make in your own velocity.

Concrete practices

Enough philosophy. Here are the rules I actually follow, cribbed together from a year of getting most of this wrong.

Time-box phase 1 to one sprint. Whatever "one sprint" means in your calendar — for me it's usually a focused afternoon, for you it might be a weekend. The point is the bound, not the length. If nothing resembling an answer exists at the end of that window, the problem isn't effort. It's either the approach or the problem statement itself. Do not extend the sprint "just a bit more" — that's how prototypes become tutorial hell. End the sprint, look at what you have, make a decision.

Best case scenario only. Phase 1 is about the best-case scenario, nothing else. No auth. No error handling. No input validation. Hardcoded credentials if they make the demo shorter. If even the happy path is boring when it works, the idea doesn't deserve a phase 2 — and you'll have learned that in a day instead of a month.

Rapid prototyping is not "skip testing". This one needs saying out loud because I know how the rest of this post sounds. Phase 1 compresses the discovery phase, not the quality phase. Once an idea graduates to "make it right", you still write tests, still handle errors, still watch real users hit the rough edges. GameHub is in beta when I am writing this article. Phase 1 told me the idea worked. Phase 2 is sitting behind a small door while I fix whatever the first handful of players break. Cutting phase 1 short gives you clarity. Cutting phase 2 short gives you embarrassment.

It's about your future self, not your code

Here's what this whole thing is really about.

Solo devs talk a lot about "discipline" and "focus" as if the hardest part of shipping software alone is making yourself work harder. It isn't. The hard part is that the version of you who starts a project and the version of you who has to finish it are not the same person. Your future self is going to be tired, distracted, bored, and — most importantly — already thinking about the next idea. That's not a character flaw. That's just how creativity runs.

Everything in this post is a process for protecting that future self from themselves.

Time-boxing phase 1 is a promise you make to the future-you who would otherwise spend three weeks on setup for an idea that was never going to work. The happy-path-only rule is a promise to the future-you who would otherwise get stuck wiring input validation for a demo nobody is going to run. Rapid prototyping is a promise to the future-you who would otherwise look at an unfinished project with shame and quietly close the tab.

And the second self — the voice that wants a new project every time the current one slows down — isn't something you fight. It's the same voice that originally got you into this. It's the part of you still reading the frontier, still noticing where the interesting problems live. You don't want to silence that voice. You want to give it a system where being right or wrong costs almost nothing, so it can keep speaking.

This is why solo devs need a development model at all. Not because the code quality matters in the way it does for a ten-person team. Because nobody else is going to stop your past self from signing your future self up for a three-week tutorial marathon on behalf of an idea that'll die in the first afternoon. You're the whole reviewing committee. You have to install your own guardrails.

The methodology isn't really about the methodology. It's about keeping faith with the version of you who hasn't shown up yet.

If you want to see any of this in action

Two live things, one devlog series, and an open offer.

PointArt — the framework that started all this. Zero dependencies, attribute-driven, Spring-shaped, runs on the cheapest shared hosting you can find. Live at pointartframework.com.
PointArt Devlog — this post is one of a series. The others cover how the framework got built, when not to reach for a framework at all, the self-updater, webhooks, and a handful of other posts I'll keep adding to. They all live at PointArt Devlog Series.
GameHub — DotCom Broker 98 — the deckbuilder the second half of this post is about. It's behind a key-based beta at gamehub.pointartframework.com. If you want a key, just ask. Drop a comment below, or email me at info@pointartframework.com — I'm handing them out one at a time to anyone curious enough to poke at it.

And honestly: if you've got your own second self nagging at you right now, I'd rather hear which project it's pointing at than whether you liked this post. Tell me in the comments

The Hidden Cost of Framework-First Thinking

Canercan Demir — Fri, 03 Apr 2026 08:11:31 +0000

Frameworks are good for more than just boilerplate. They encode decisions: how to structure a project, where logic belongs, how to handle requests. A developer picking up Laravel or Spring for the first time isn't just getting free code — they're inheriting years of hard-won conventions. That's valuable. It means a junior and a senior on the same team are solving the same problem in the same -almost- shape.

But "frameworks are useful" doesn't mean "always use a framework." Knowing when not to reach for one is as important as knowing how to use one.

When you're still learning the language

This is the one that gets skipped most often, and causes the most damage later.

When the only mental model is Laravel does it this way, it's not really programming — it's copying at a higher level. Instead of copying Stack Overflow snippets, copying framework patterns. The abstraction is more sophisticated, but the understanding underneath is the same. When a bug appears outside the framework's happy path, or something it doesn't support cleanly is needed, there's nothing to fall back on.

A concrete example: webhook signature verification.

// ❌ What you might write if you only know framework routing
$expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);
return $expected === $received; // Vulnerable to timing attacks

// ✅ What learning the language teaches you
$expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);
return hash_equals($expected, $received);

hash_equals() instead of ===. This is a language-level security detail that prevents timing attacks. No framework teaches this — it's just PHP. Learning PHP only through a framework, a developer might write === and never know it was wrong.

Learn the language first. Write raw SQL before using an ORM. Handle routing yourself before adding a router. Not forever — just long enough to see what the abstraction is actually doing for you.

When the project is small enough to not need one

A framework has a cost beyond file size or boot time. The mental overhead of fitting your problem into its model is real.

For a 200-line script, a standalone endpoint, or a cron job that reads a file and sends an email — that cost doesn't pay off. A script that runs once a day and calls one external service doesn't need routing, DI containers, or a migration system. It needs to work.

The same principle applies to pulling in packages. PointArt's self-updater downloads release zips from GitHub with no HTTP client library:

// ❌ Reaching for a package by default
$client = new GuzzleHttp\Client();
$zip = $client->get($zipUrl)->getBody();

// ✅ PHP already handles this natively
$ctx = stream_context_create(['http' => ['timeout' => 30]]);
$zip = file_get_contents($zipUrl, false, $ctx);

Knowing the language means knowing when the standard library is enough — and not adding a dependency graph to solve a problem that was already solved.

The question isn't could I use a framework here? It's does this problem have enough surface area that shared conventions help me manage it?

When the framework's model doesn't fit your problem

Frameworks are designed around specific problem shapes. A web framework expects HTTP request/response cycles. An MVC framework expects controllers, models, views.

If your project doesn't fit that shape — a long-running daemon, a CLI tool, a data pipeline, a batch processor — you spend as much effort fighting the framework as building the thing.

When I built PointArt, I had to make this call explicitly: no middleware system, no async, single-process, designed for shared hosting. Not oversights — deliberate limits because the target problem is the web request/response cycle on constrained hosting.

The AI angle

There's a new version of the "framework without language knowledge" problem: using AI to generate framework code without understanding either.

With enough prompting you can build something that looks like a working application. Frameworks help AI here — it's seen a lot of Laravel and Rails, so it generates plausible-looking code. But when something goes wrong, and it will, you have no model of what correct looks like. You can't debug what you can't read. You can't maintain what you don't understand.

AI is a strong tool for developers who already know what they're doing. It fills in boilerplate fast. But the understanding it skips is exactly what you'll need when the generated code misbehaves.

The practical signals

Use a framework when:

Multiple developers need shared conventions across a long-lived codebase
The problem shape fits the framework's model well

Skip it when:

You're still learning the language fundamentals
The project is small enough that the model costs more than it saves
The deploy target rules it out
Your problem shape doesn't match the framework's assumptions

The goal is not to avoid frameworks. It's to know what they're doing — so you can choose when to use them, and know what to do when they stop working.

I've been writing about building PointArt — a zero-dependency PHP micro-framework — from scratch. If you're curious about what it looks like to make these decisions at the framework level, you can take a look at PointArt Devlog Series.

How I Built a Self-Updater With GitHub Releases

Canercan Demir — Fri, 27 Mar 2026 18:38:20 +0000

I've been building PointArt — a PHP micro-framework modelled after Spring Boot's programming model. Attribute-based routing, dependency injection, an ORM, repositories — all in plain PHP, no Composer required.

The previous articles in this series covered the framework itself and how I turned GitHub into a headless CMS for the docs site. This one is about a different kind of problem: distribution.

PointArt v1.1.0 added CORS and CSRF support. CORS headers are opt-in via .env — useful if you're building an API frontend. CSRF protection is on by default for all POST form requests, with per-route opt-out for webhooks. Both are security features, the kind of thing you actually want users to be running.

But here's the problem: how do users get the update?

There's no composer update (and if it ever comes, it will be totally optional). The framework is just files — you clone it and deploy it. Updating means manually downloading a zip, figuring out which files changed, and copying them over without breaking your own app/ code. In practice, most people don't bother. They stay on whatever version they cloned.

That's a bad place to be when the update contains security features. So I built a self-updater directly into the framework — browser-based, no terminal required, pulls from GitHub Releases.

This article is about how that works: the system design, the tradeoffs, and how it all fits into a codebase with zero dependencies.

The Constraint: Zero Dependencies

Composer is great, but not everyone has it available — shared hosting environments vary a lot, and more importantly, not every project needs it. Optional Composer support is on the roadmap, but zero-dependency will always remain a valid choice. If PHP 8.1+ is available, PointArt runs.

That constraint shapes everything about how the updater had to be built. No CLI helpers. Just what PHP ships with:

file_get_contents() with an HTTP context — for hitting the GitHub API and downloading zips
ZipArchive — for extracting the release archive
copy(), scandir(), mkdir() — for the file sync
hash_equals() — for constant-time secret comparison
Sessions — for auth state between the login POST and the update page

That's the entire dependency surface. If these exist on a host, the updater works.

The Design

The updater intercepts requests before the application router runs — so it works even if the framework itself is partially broken, which matters when you're about to overwrite framework files.

The full flow:

User visits /pointart/update
    → Not authed? Show login form
    → Authed? Call GitHub API, show version check page
        → Click "Update Now"
            → Download zip from GitHub
            → Backup existing files
            → Sync new files (skip protected paths)
            → Clear route cache
            → Show result

Version Tracking

The installed version is stored in a plain text file: framework/VERSION.

1.1.0

That's it. One line. The updater reads it with file_get_contents, strips whitespace, and extracts the semver string with a regex. If the file doesn't exist, it defaults to 0.0.0 — which means any real release will be considered an update.

public function getCurrentVersion(): string {
    if (!is_file(self::VERSION_FILE)) return '0.0.0';

    $raw = trim((string) file_get_contents(self::VERSION_FILE));
    if ($raw === '') return '0.0.0';

    if (preg_match('/\d+\.\d+\.\d+(?:-[0-9A-Za-z.-]+)?/', $raw, $matches) === 1) {
        return $matches[0];
    }

    return $raw;
}

Keeping the version in a plain file means it survives updates — it gets overwritten by whatever the new release ships — and it's readable by anything without parsing JSON or querying a database.

Talking to GitHub Releases

The updater doesn't use webhooks or a custom release server. It just calls the public GitHub Releases API:

GET https://api.github.com/repos/Cn8001/PointArt/releases

This returns a JSON array of releases, newest first. Each object has tag_name for the version string, zipball_url to download the archive, body for release notes, and prerelease — a boolean set from the GitHub release UI. The updater iterates and picks the first release matching the selected channel:

foreach ($releases as $data) {
    $isPrerelease = !empty($data['prerelease']);

    if ($channel === 'stable' && $isPrerelease) continue;
    if ($channel === 'dev'    && !$isPrerelease) continue;

    return [
        'version' => $data['tag_name'],
        'zip_url' => $data['zipball_url'],
        'notes'   => $data['body'],
    ];
}

The stable channel skips anything marked as prerelease on GitHub. The dev channel does the opposite — only prereleases. No special tag naming convention required. The prerelease checkbox on the GitHub release UI is the only thing that controls channel membership.

Version comparison uses PHP's built-in version_compare():

if (version_compare($current, $latest['version'], '>=')) {
    // already up to date
}

The File Sync: Safe by Default

This is the part that has to be right. The sync logic walks the extracted release directory and copies files into place — but with two layers of protection.

Protected paths are never touched:

private const PROTECTED = [
    'app',
    '.env',
    '.env.example',
    'cache',
];

app/ is your controllers, models, views. .env is your config. cache/ is runtime state. SQLite files are also skipped anywhere they're found — by extension, not by path:

if (pathinfo($item, PATHINFO_EXTENSION) === 'sqlite') continue;

Every overwritten file is backed up first:

// Backup existing file
if (is_file($dest)) {
    if (!@copy($dest, $bak)) {
        $errors[] = "Failed to backup $rel";
        continue;  // don't overwrite if we couldn't back up
    }
}
// Copy new file
if (!@copy($src, $dest)) {
    $errors[] = "Failed to copy $rel";
}

If the backup fails, the file isn't overwritten. If any errors occur, the result page reports them and the backup directory stays in place at cache/update-backup-{version}/ so you can restore manually.

On a clean update, the backup directory is removed at the end — no leftover clutter.

Post-Update

PointArt scans app/ once and serializes the route + service registry to cache/registry.ser. Every subsequent request reads from that cache. After an update, the cache needs to be cleared so the next request rebuilds it.

The updater calls this directly:

ClassLoader::clearCache();

Which just deletes the file. No fancy invalidation, no versioning. The next request rebuilds from scratch.

Putting It Together

Here's the updater from a user's perspective:

Add two lines to .env
Visit /pointart/update in a browser
Enter the secret
See current version, latest version, release notes
Click Update
Done

From a deployment perspective, you'd enable the updater when you want to check for updates and disable it afterwards. It's not meant to be always-on.

Tradeoffs

What this approach gets right:

Works on shared hosting with no CLI access
User's code and data are never touched
Backup before overwrite — something can always go wrong
Stable/dev channels without special tag naming

What it doesn't do:

Rollback — you'd have to restore from the backup directory manually
Differential updates — always downloads the full release zip
Auto-updates on a schedule — it's manual, on demand

For a framework at this scale and distribution model, those tradeoffs are fine. The goal was to make applying an update take two minutes instead of twenty.

PointArt is open source under the Mozilla Public License 2.0. If you want to dig into the full implementation, the repo and documentation are at pointartframework.com.

How I Turned GitHub into a Headless CMS

Canercan Demir — Sun, 22 Mar 2026 10:35:22 +0000

After publishing my PHP micro-framework PointArt, I built a website for it. However, the site needed some dynamic content — especially the changelog and roadmap — to update the moment something changes on GitHub.

My first instinct was an admin panel. Then I stopped myself — the content already lives on GitHub, why enter it for the second time? It also opens a door for human error. So I made GitHub the CMS instead of an admin panel and used webhooks to keep a local database in sync automatically.

Architecture

GitHub (push or release event)
  → POST /hooks/* (HMAC-verified)
    → Parse payload
      → Upsert / delete DB rows
        → Website reads DB on page load

Two content types, two sync strategies:

Content	Source	Strategy
Changelog	GitHub Releases	Incremental — insert/update/delete per event
Roadmap	`CONTRIBUTING.md`	Full sync — re-fetch + delete-all + re-insert on every push

The website never calls the GitHub API at request time. It reads from the local database; GitHub keeps that data fresh.

Verifying the Signature

Every GitHub webhook includes an X-Hub-Signature-256 header — HMAC-SHA256 of the raw body signed with your secret. Verify it before anything else.

function verifySignature(string $rawBody, string $secret): bool {
    $expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);
    $received = $_SERVER['HTTP_X_HUB_SIGNATURE_256'] ?? '';
    return hash_equals($expected, $received); // timing-safe
}

Two gotchas here: read the raw body before json_decode() (HMAC is over the exact bytes GitHub sent), and use hash_equals() not === to avoid timing attacks.

GitHub also sends a ping event when the webhook is first created. Handle it or GitHub marks the endpoint as failed:

$rawBody = file_get_contents('php://input');
$payload = json_decode($rawBody, true);

if (!verifySignature($rawBody, $secret)) {
    http_response_code(403); return;
}
if (isset($payload['zen'])) {  // ping event
    echo json_encode(['ok' => 'pong']); return;
}

In PointArt website, this lives in a HookController with #[Router] / #[Route] attributes:

#[Router(name: 'webhook', path: '/hooks')]
class HookController {
    #[Wired] private ReleaseRepository $releaseRepository;
    #[Wired] private RoadmapRepository $roadmapRepository;

    private function verifySignature(string $rawBody): bool {
        $secret   = Env::get('WEBHOOK_SECRET');
        $expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);
        $received = $_SERVER['HTTP_X_HUB_SIGNATURE_256'] ?? '';
        return hash_equals($expected, $received);
    }

Syncing the Changelog (Incremental)

Release events carry an action field: published, edited, or deleted. Map them to DB operations:

$action    = $payload['action'];
$release   = $payload['release'];
$releaseId = $release['id'];

if ($action === 'deleted') {
    deleteByReleaseId($releaseId);
} elseif (in_array($action, ['published', 'edited', 'released'])) {
    deleteByReleaseId($releaseId); // delete + insert = simple upsert
    insertRelease([
        'release_id'   => $releaseId,
        'tag_name'     => $release['tag_name'],
        'name'         => $release['name'] ?? $release['tag_name'],
        'body'         => $release['body'],
        'published_at' => $release['published_at'],
        'author'       => $release['author']['login'],
    ]);
}

Delete + insert instead of UPDATE keeps it simple and naturally idempotent (more on that below).

In PointArt this maps to a repository with #[Query] attributes — method signatures auto-generate their implementations:

#[Service]
abstract class ReleaseRepository extends Repository {
    protected string $entityClass = Release::class;

    #[Query('SELECT * FROM releases ORDER BY published_at DESC')]
    abstract public function findAllOrderedByDate(): array;

    #[Query('DELETE FROM releases WHERE release_id = ?')]
    abstract public function deleteByReleaseId(int $releaseId): void;
}

Syncing the Roadmap (Full Sync from Markdown)

For the roadmap I use a different strategy: the push event is just a trigger. I re-fetch CONTRIBUTING.md from GitHub's raw CDN and do a full delete + re-insert.

Why not parse the diff from the payload? Because fetching the whole file is simpler and I don't need partial updates — every push gives a fresh, complete view.

$url     = 'https://raw.githubusercontent.com/yourname/repo/master/CONTRIBUTING.md';
$content = @file_get_contents($url, false, stream_context_create(['http' => ['timeout' => 10]]));

// Full sync: wipe and re-insert
$roadmapRepository->deleteAll();
foreach (parseContributing($content) as $item) {
    $entry->title       = $item['title'];
    $entry->description = $item['description'];
    $roadmapRepository->save($entry);
}

The parser scans for ### headings inside a ## What to Contribute section:

function parseContributing(string $content): array {
    $lines = explode("\n", $content);
    $items = []; $inSection = false; $title = null; $descLines = [];

    foreach ($lines as $line) {
        $line = rtrim($line);
        if (!$inSection) { if (stripos($line, '## What to Contribute') === 0) $inSection = true; continue; }
        if (str_starts_with($line, '## ')) break;
        if (str_starts_with($line, '### ')) {
            if ($title !== null) $items[] = ['title' => $title, 'description' => trim(implode(' ', $descLines))];
            $title = trim(substr($line, 4)); $descLines = []; continue;
        }
        if ($title !== null && $line !== '' && $line !== '---') $descLines[] = $line;
    }
    if ($title !== null) $items[] = ['title' => $title, 'description' => trim(implode(' ', $descLines))];
    return $items;
}

A Few Gotchas

Webhooks only fire on future events. When you first deploy, the DB is empty, keep in mind!

GitHub retries on non-2xx. If your handler throws a 500, GitHub retries. The delete + insert pattern makes handlers naturally idempotent, so retries are harmless.

Use raw.githubusercontent.com for files, not the API. The raw CDN has no rate limit for public repos. The GitHub API is limited to 60 unauthenticated requests/hour.

The Result

Publish a GitHub release → changelog updates automatically
Edit CONTRIBUTING.md and push → roadmap refreshes

The same pattern could extend further — maybe devlogs, ideas, or any other content that already lives in a GitHub repository. If GitHub is already your source of truth, the webhook just keeps everything else in sync.

Thanks for reading!

I built a PHP framework with Spring Boot style - zero dependencies, dynamic ORM, attribute-based routing (works on shared host).

Canercan Demir — Wed, 18 Mar 2026 11:14:58 +0000

I was using Spring Boot and it was my default selection until one client wanted to build a simple website. I had started coding with PHP but hadn't used it for a while. Then, I remembered the simplicity and minimalism of mixing PHP, HTML, CSS, and JS into one file (or separate files with .js etc), and how easy and cheap the hosting management was. But I didn't want to leave Spring's features behind, like JPA and dependency injection.

So, I built a microframework with zero dependency that even works on shared hosting.

Website & Docs: pointartframework.com
GitHub Repo: Cn8001/PointArt

The site itself is using PointArt and resides on shared hosting. For more documentation please visit the website.

PointArt is a PHP micro-framework that brings Spring Boot's attribute-based style to PHP 8.1 (PHP 8.1+ since it introduced attributes, and PDO driver is required):

#[Router(name: 'user', path: '/user')]
class UserController {
    #[Wired]
    private UserRepository $userRepository;

    #[Route('/list', HttpMethod::GET)]
    public function index(): string {
        return Renderer::render('user.list', ['users' => $this->userRepository->findAll()]);
    }

    #[Route('/show/{id}', HttpMethod::GET)]
    public function show(int $id): string {
        $user = User::find($id);
        return $user ? Renderer::render('user.show', ['user' => $user]) : httpError(404);
    }

    #[Route('/create', HttpMethod::POST)]
    public function create(
        #[RequestParam] string $name,
        #[RequestParam] string $email
    ): string {
        $user = new User();
        $user->name  = $name;
        $user->email = $email;
        $user->save();
        return Renderer::render('user.show', ['user' => $user]);
    }
}

The repository pattern generates query implementations from method names — just like Spring Data JPA. If you need custom SQL it also allows it:

abstract class UserRepository extends Repository {
    protected string $entityClass = User::class;

    abstract public function findByName(string $name): array;
    abstract public function findOneByEmail(string $email): ?User;
    abstract public function existsByEmail(string $email): bool;
    abstract public function countByActiveTrue(): int;

    // Custom SQL when you need it
    #[Query("SELECT COUNT(*) FROM users")]
    abstract public function countAll(): int;
}

Features:

#[Router] / #[Route] — attribute-based routing with path params and query string support
#[Wired] — property injection, no constructor boilerplate
#[Entity] / #[Column] / #[Id] — ORM for SQLite, MySQL, PostgreSQL
Spring Data-style dynamic finders + #[Query] for raw SQL
Route + service registry is cached — no Reflection overhead on every request
No Composer, no build step, no CLI — literally copy files to a server and go (that is the reason why I did not use a full framework.)

It's been a fun project to build from scratch (the dynamic repository finder parser was the trickiest part). Would love any feedback and open to contributions. You can see the future ideas on the website.