Then, somewhere around the third month, the project stalls. Not dramatically — there’s no postmortem, no cancellation email. It just quietly stops moving. The remaining work never gets easier, the Rust never gets good, and eventually the branch goes stale.

This isn’t a failure of nerve or tooling. It’s a structural property of what porting C++ to Rust actually is — and it’s worth understanding before you spend a quarter learning it the expensive way.

The seduction is real, and so is the wall

The reason the demo is so convincing is that the first 90% genuinely is easy now. Translating C++ control flow, arithmetic, and data structures into syntactically valid Rust is exactly the kind of pattern-matching LLMs are good at. The compiler even helps: if it builds, a lot of bugs are already gone.

The problem is what’s hiding in the last 10%, and it’s the same thing whether a human or a model is doing the work.

C++ does not encode ownership. When you write T* p, the language does not record whether p owns that memory, borrows it, shares it, or aliases something else that’s about to be freed. Those facts live in the programmer’s head, in comments, in naming conventions, and in tribal knowledge about “who frees what.” Rust’s entire value proposition is that these facts must be written down and checked. So a C++→Rust port is not a translation. It’s a reconstruction of invariants that were never explicitly recorded.

That’s why automatic transpilers are so instructive. Tools like c2rust produce Rust that is “almost always correct” — and almost always unsafe and unidiomatic. They faithfully preserve C’s pointer semantics by wrapping everything in unsafe, raw pointers, and libc calls. The output compiles. It is also, in the words of the research, “very different from the kind of Rust code usually written by humans, making it hard to read and maintain” — and it sails straight past the linters that are supposed to catch the problems. You get Rust syntax with C semantics: all of the migration cost, none of the safety payoff.

LLMs improve on this — they can sometimes infer ownership and produce idiomatic code — but the failure mode is sneakier. As DARPA’s program manager for TRACTOR (the agency’s program to automate exactly this translation) put it: ask any model to translate C to safe idiomatic Rust and “something comes out, and it’s often very good, but not always.” When it’s not, the model tends to reach for unsafe to make the borrow checker stop complaining — which is precisely how you end up with code that looks migrated but carries the same latent bugs it always had, now harder to spot because everyone assumes “it’s in Rust, so it’s safe.”

This is the mechanism behind the stall. The borrow checker doesn’t get tired and wave the last 10% through. Every place where the original C++ had a fuzzy ownership story becomes a hard stop that requires a human to decide what the ownership story should be — and frequently to redesign the data structures to express it. That’s design work, not typing work. LLMs removed the typing bottleneck, which was never the bottleneck.

The evidence cuts both ways — but cleanly

The honest read of the industry data is not “Rust good” or “rewrites bad.” It’s that the shape of the project predicts the outcome far better than the language choice does.

Look at what the wins have in common. Android never ported anything — Google’s entire strategy is that new code is Rust and old C++ is left in place; the safety gains come from the fact that “most bugs live in new code”, so you don’t need to touch the old stuff to bend the curve. Pingora wasn’t a translation at all; it was a clean-room reimplementation against a known spec, where the team got to design the ownership model from scratch instead of recovering it from someone else’s pointers. Mozilla picked off self-contained, parallelism-hungry components one at a time and integrated each before starting the next.

Now look at curl. Daniel Stenberg’s team spent roughly five years (2020–2025) trying to let curl use the Rust hyper library as an HTTP backend through an FFI glue layer — and ultimately ripped it out. The reasons are a near-perfect catalog of why these projects die:

• The last 5% was the whole problem. “The final few percent would turn out to be friction enough to now eventually make us admit defeat.”

• Nobody to do the hard part. It needed someone fluent in both C and Rust and the HTTP protocols to drive the integration across the FFI boundary — and almost no one wanted to.

• The FFI seam leaked. They had to remove HTTP/2 support because they’d misunderstood how the API integrated across the language boundary.

• No demand pulling it forward. curl users didn’t care that a backend was in Rust; Rust users didn’t want to maintain glue for a C project.

Stenberg’s conclusion is the bluntest data point in the whole debate: “We’re not going to rewrite curl in Rust. In any language — we’re not going to rewrite it at all.” This from someone who openly acknowledges that roughly half of curl’s historical vulnerabilities are C memory mistakes. He knows the safety case cold. He’s declining anyway, because the migration cost is real and the existing C is hardened by decades of fuzzing and CVE wrangling.

The hidden tax: comprehension debt

There’s a second-order cost that the demo never shows you, and it’s worse with LLM-driven ports than with hand ports.

When a model emits 4,000 lines of plausible Rust, no one on your team owns the mental model of that code. The 2025 research on LLM-generated code calls this comprehension debt and “ownership debt”: “it compiles” is not the same as “someone understands why it’s correct and can change it safely.” With a hand-written port, the engineer who fought the borrow checker comes out the other side understanding the ownership model — that understanding is half the point. With a generated port, you’ve skipped the understanding and kept only the artifact. The first time it needs a non-trivial change, you pay the comprehension cost you deferred, except now under deadline and without the person who’d have built the model.

This is why “the LLM did 90% in a week” is a misleading metric. The week of typing was never the expensive part. The expensive part is owning a correct mental model of a safety-critical system — and that’s exactly what gets skipped when the code arrives pre-written.

A decision framework that actually predicts outcomes

Stop asking “should we port to Rust?” It’s the wrong altitude. Ask these instead:

1. Is this new code or existing code?

If new, strongly favor Rust, and stop reading. The Android data is overwhelming: the cheapest safety win is to stop adding to the C++ pile. No migration risk, all the upside.

2. If existing — is the component self-contained, or is it threaded through the codebase?

A module with a narrow, well-defined interface (a parser, a codec, a proxy data path) is a Stylo/Pingora candidate. A module whose pointers reach into everything will trap you in FFI hell: every call across the C++/Rust seam is an unsafe boundary where Rust’s guarantees evaporate and new bugs breed. The curl/hyper failure was fundamentally an FFI-boundary failure.

3. Do you have a spec, or only the code?

If you can reimplement against a specification or a strong test suite (Pingora had the HTTP spec; you can have a differential test harness), favor a clean-room rewrite over a line-by-line port. You’ll design the ownership model instead of reverse-engineering it, and you can run old and new side by side to prove equivalence.

4. Will someone own the result?

If the answer is “the LLM wrote it and we’ll figure it out later,” you don’t have a migration plan, you have a future incident. Budget the human comprehension cost up front or don’t start.

5. Is the existing C++ actually your risk?

Battle-hardened, heavily-fuzzed C++ that hasn’t thrown a CVE in years is not where your memory-safety risk concentrates. New and frequently-changed code is. Spend the migration budget where the bugs actually are.

The verdict

Use the LLM. It genuinely removed a real cost — the mechanical translation that used to make these projects unaffordable to even start. But understand precisely what it removed and what it didn’t. It removed the typing. It did not remove the thinking: recovering ownership invariants that C++ never recorded, designing data structures that satisfy the borrow checker, and proving the result is equivalent to the original.

That thinking is the project. It was always the project. The reason ports stall at 90% is that the demo completes the 90% that was never hard, and then hands you the 10% that was the entire point — now disguised as “almost done.”

Port new code by default. Port self-contained components against a spec. Leave hardened, stable C++ alone. And treat any plan whose timeline is built on “the model already wrote most of it” as a plan that hasn’t started yet.

There is no shortage of "rewrite it in Rust" stories on the internet. Some are driven by hype, others by genuine engineering needs. This is not the former. What follows is a straightforward account of where MantisBase is headed, why, and what it means for you.

A Growing Ecosystem Worth Taking Seriously

Before getting into the decision itself, it is worth acknowledging the state of Rust as a language and ecosystem. The Rustacean community has grown into one of the most active and technically rigorous developer communities in open source. The crates.io registry now hosts hundreds of thousands of packages, covering everything from async runtimes and HTTP frameworks to database drivers, JWT handling, and mailer integrations — all with first-class tooling and consistently high quality. Rust has also topped Stack Overflow's "most admired language" survey for several consecutive years, which speaks less to popularity and more to developer satisfaction once they have committed to it.

We have been watching this ecosystem closely. It has matured to a point where building a production-grade, single-binary backend on top of it is not only feasible — it is arguably the most sensible path forward for a project with MantisBase's goals.

What Is Already Happening

Work on v0.4 has begun, and it is a full rewrite in Rust. The goal is to reach feature parity with the current C++ release at minimum, and to go further where the new foundation makes it practical to do so. If you want to track progress, the master branch on GitHub already reflects the active rewrite — the repository is already building and running in Rust, with core functionality like entity schemas, REST routing, access rules, JWT authentication, admin dashboard serving, and webhook support already in place.

This is not a distant roadmap item. It is ongoing work, and it is further along than most announcements of this kind tend to let on.

Why the C++ Foundation Was Holding Us Back

MantisBase started as a C++ project for good reasons: raw speed, embeddability, and a single-binary deployment model with no external runtime dependency. Those goals have not changed. What changed is our assessment of the cost of continuing to pursue them in C++.

The C++ codebase accumulated a set of challenges over time — not insurmountable, but expensive to address correctly. Memory management patterns that required careful audit, integration complexity when pulling in third-party libraries, and a build system that made certain kinds of cross-platform testing harder than it needed to be. Fixing these properly would have demanded a significant investment of time — time that should have gone toward improving the product.

The practical result was that several things we wanted to deliver kept getting pushed back. The documentation site needed modernisation. The admin dashboard needed a cleaner, more capable UI. The REST API had features we wanted to expand. Most notably, out-of-the-box SDK support for JavaScript and Python — something users have asked about consistently — was hard to prioritise while we were managing the overhead of the C++ foundation.

We reached a point where the honest assessment was: the language itself had become a constraint on the project's growth, not just a technical detail.

Why Rust, and Not Zig or Go

Once the decision to move away from C++ was made, we evaluated the realistic alternatives that could preserve what made MantisBase useful in the first place: a single compiled binary, genuine performance, and low memory overhead. Rust, Zig, and Go were the serious contenders.

Go produces clean binaries and has an excellent standard library, but its garbage collector introduces latency characteristics that are a poor fit for a backend meant to be embedded inside other applications. Zig is technically compelling and offers tight control over memory, but its ecosystem and tooling are still maturing — pulling in third-party integrations would mean building more from scratch than we wanted.

Rust offered the right combination: compile-time memory safety without a garbage collector, a mature ecosystem through crates.io, and tooling (cargo, rustfmt, clippy, cargo test) that genuinely reduces friction rather than adding to it. The memory safety story was particularly relevant. Part of why the C++ codebase was difficult to maintain was precisely the category of issues that Rust eliminates at the compiler level — use-after-free, data races, invalid pointer dereferences. We could have audited and hardened the C++ code, but choosing Rust means we do not have to keep having that conversation on every future contribution.

Beyond safety, the crate ecosystem makes it straightforward to integrate capabilities that previously required significant custom work: mailer support via lettre, async HTTP with axum, database access via sqlx, and more. These are not afterthoughts — they are well-maintained, widely used libraries that slot in cleanly.

First-class test support via cargo test is also worth naming directly. Writing and running tests in C++ projects of this kind involves considerably more ceremony. In Rust, testing is a natural part of the workflow, which matters when you are trying to build confidence in a rewrite incrementally.

Language SDK Support Becomes Realistic

One of the things we wanted to offer from early on was MantisBase SDKs for JavaScript and Python — not just REST clients, but deeper integration. In the C++ world, producing idiomatic bindings for both languages meant navigating complex FFI boundaries, separate build pipelines, and significant maintenance surface.

From Rust, this is substantially more tractable. The PyO3 project provides a mature path for exposing Rust libraries to Python, and Neon (or WASM targets) covers the Node.js side. We are not committing to a specific release timeline for these yet, but the rewrite removes the structural obstacle that made them impractical before.

What Happens to C++ Support

The original C++ releases are not being abandoned. Binaries up through v0.3.5 remain available on the GitHub releases page, and that code is not going anywhere.

Looking further ahead, we are interested in the model that projects like Slint have demonstrated. Slint is a UI toolkit written in Rust that exposes a fully supported C++ API — developers working in C++ interact with it as though it were a native C++ library, with no Rust toolchain required on their end. Several other projects in the embedded and systems space have taken similar approaches. We are examining what that looks like for MantisBase's embedding use case, and C++ API support remains part of the long-term plan.

What to Expect Next

The v0.4 work is progressing in the open. You can follow along, open issues, or contribute via the GitHub repository. The current Rust codebase is already functional enough to run and experiment with.

A more detailed devlog covering the architecture of the Rust port — including database abstraction, the new schema engine, and the HTTP layer — is coming soon. For updates, subscribe below or follow @allankoechke on X.

MantisBase is an open-source, single-binary Backend-as-a-Service. Visit mantisbase.com for documentation and demos.

Originally posted here:

Explore New Features in 3ds Max 2027 Release Updates

A few weeks ago, 3ds Max 2027 was officially released, introducing new features and capabilities for both artists and developers. With this release, 3ds Max saw many upgrades including Arnold to 5.9.0, USD to 0.14.0, Substance to 3.0.6, performance improvements across tools, modifiers, and render workflows, and much more. Refer to the product release page for a detailed feature breakdown for 3ds Max 2027.

New Features, Improvements, and Updated Workflows

3ds Max 2027 ships with several notable updates across its plugin ecosystem: 

• Arnold for 3ds Max updated to 5.9.0 (Arnold 7.5.0.0)

• USD for 3ds Max updated to 0.14.0

• Substance updated to 3.0.6

• Autodesk Assistant (Technical Preview): An AI-powered tool that helps you quickly find information about features and workflows directly within the product — a welcome addition for developers and artists alike looking to streamline their pipeline research. Read more here.

SDK Changes

Now let's get into what matters most for plugin developers.

• .NET 10.0 Support: 3ds Max 2027 moves plugin development to .NET 10. Note that .NET 8, introduced in 3ds Max 2026, has reached an end of life and is no longer supported. If you are still on an older version, refer to our porting guide from .NET Framework to .NET for plugins for step-by-step migration guidance.

• DirectX 9 Removal: Support for DirectX 9 has been fully removed. This affects several headers that have been dropped from the public SDK — notably id3d9graphicswindow.h, idx9pixelshader.h, and idx9vertexshader.h — along with related interfaces in ihardwarematerial.h, ihardwarerender.h, and RTMax.h. Developers relying on these should migrate to the DirectX 11 equivalents now available in the SDK.

• Updated Core Dependencies: 3ds Max 2027 development specifies Visual Studio 2022 (v17.14.x), C++20, Qt 6.8.3. Review your plugin dependencies against these versions before building. You could also use the newer Visual Studio 2026, when you set the toolset to be v143.

• API Changes: There are targeted API updates across several headers — including new methods in custcont.h, ioapi.h, and IValidateNodeCallback.h, as well as deprecations in object.h, gfx.h, and others.

• Updated Samples and Documentation: Samples and documentation have been updated to reflect all API changes in this release.

We're shipping v0.3.4 today with a handful of quality-of-life improvements, a cleaner configuration story, and a few important bug fixes. Here's what's new.

Unified MB_* Environment Variable Prefix

All environment variables now consistently use the MB_* prefix. If you were previously setting MANTIS_JWT_SECRET, update that to MB_JWT_SECRET — the old name is no longer recognised. This brings every runtime knob under one coherent namespace and makes it easier to manage configuration in Docker and CI environments.

Variable Description Default MB_JWT_SECRET JWT signing secret (set this in production!) built-in default MB_DISABLE_FILE_UPLOADS Set to 1 to disable file uploads globally 0 MB_DISABLE_ADMIN_ON_FIRST_BOOT Set to 1 to skip auto-admin creation browser spin off 0 MB_DISABLE_RATE_LIMIT Set to 1 to disable rate limiting enabled

File Upload Kill Switch

A new MB_DISABLE_FILE_UPLOADS=1 flag lets you turn off file uploads at the server level without touching your schema. Any upload attempt while this flag is active will receive a 403 Forbidden response. Useful for read-only deployments or environments where you want to enforce that no files land on disk.

Docker Improvements

The Dockerfile has been updated to debian:trixie-slim as its base, and the build arg has been renamed from MANTIS_VERSION to MB_VERSION (default 0.3.4) to match the new naming convention. The docker-compose file now also surfaces all MB_* variables as commented-out stubs, so it's clear what you can configure without digging through docs.

The published image on Docker Hub is allankoech/mantisbase — the quick-start command is simply:

docker run -p 7070:80 allankoech/mantisbase

All submodules have also been switched from SSH to HTTPS URLs and set to shallow fetch, which significantly speeds up fresh clones in CI pipelines.

Admin Panel Updates

Several improvements have landed in the admin UI this release:

Entity cloning — You can now clone an existing entity directly from the admin panel. Cloning copies the source entity's schema (field names, types, and structure) into a new entity, giving you a clean starting point to build on without recreating common field sets from scratch. No records are carried over, only the schema.

Entity renaming — Entities can now be renamed from within the admin panel without having to drop and recreate them.

Long entity name overflow fix — Entity names that exceeded the available sidebar/panel width were pushing other UI elements off screen. This has been corrected so long names truncate gracefully and the layout stays intact.

Minor bug fixes and improvements across the admin panel generally.

Bug Fixes

• PATCH requests with password fields — a missing-field error that surfaced when patching records containing a password field has been resolved.

• Last-activity tracking — activity timestamps now only update on actual database record changes, not on every SSE ping or passive connection event. This prevents misleading "active" signals for idle clients.

• SSE session cleanup — auth tokens are no longer held in memory on SSE sessions. The token field is explicitly nulled out after verification, reducing the risk of credentials lingering in heap memory across a long-lived connection.

Internal / Code Quality

• soci_wrappers.h saw a significant cleanup — redundant nesting in the field-binding logic was flattened, making the type-dispatch code considerably easier to follow.

• SSE event queuing now uses emplace instead of push for slightly cleaner construction.

• SQL update column formatting moved to std::format for consistency.

Upgrading

Update your environment variables from MANTIS_JWT_SECRET → MB_JWT_SECRET and pull the new image or rebuild from source. No schema migrations are required for this release.

The full changelog and binaries are available on the GitHub releases page.

If you've been following along, you know I've been busy building MantisBase for a while now. Today feels like a good checkpoint to step back, write a bit, and share what's shipped.

This is the first official devlog. There will be more.

The Project Website is Up

First things first, MantisBase now has a proper home on the internet.

MantisBase | Lightning fast BaaS in C++

It's a landing page for now, but it does the job — gives you a quick feel for what MantisBase is and where it's headed. If you've been curious but haven't dug into the GitHub repo yet, the website is probably the gentler starting point.

Try It Without Installing Anything

This one I'm particularly happy about.

One of the biggest friction points with any self-hosted tool is the "I'll check it out later" trap; you bookmark it, tell yourself you'll spin it up over the weekend, and then never do. I've been guilty of this myself more times than I'd like to admit.

So we now have a live demo environment:

Mantis Admin Dashboard

No installation. No Docker. No config files. Just open it and poke around. If it clicks for you, then you can go down the setup rabbit hole.

Docker Image on Docker Hub

Speaking of setup—for those who are comfortable with Docker and just want to pull and run, we've got you covered.

docker pull allankoech/mantisbase

Full image available at:

allankoech/mantisbase - Docker Image

This is probably the fastest path from zero to a running instance if you're on a server or just want to keep things clean on your local machine.

What's Next

We're currently in the middle of cleaning up the admin UI — ironing out some rough edges and squashing a few bugs that have been on the list. Nothing dramatic, just the kind of polish work that makes the difference between something that works and something that feels solid.

More updates soon. If you want to follow along, the GitHub repo is the most up-to-date place to track progress.

Until the next devlog. ✌️

February 4, 2026 — We're excited to announce the release of MantisBase v0.3.3, bringing real-time database capabilities to this lightweight, high-performance Backend-as-a-Service framework. This release introduces Server-Sent Events (SSE) support for both SQLite and PostgreSQL backends, along with critical bug fixes and improved system observability.

What's New in v0.3.3

Real-Time Database via SSE

The flagship feature of v0.3.3 is native real-time database synchronisation using Server-Sent Events. Unlike traditional polling approaches that waste resources checking for updates, SSE establishes a persistent HTTP connection that allows the server to push changes to clients as they happen.

Why SSE?

Server-Sent Events offer several advantages for real-time database applications:

• Efficient unidirectional streaming — Perfect for database change notifications where data flows primarily from server to client

• Built on standard HTTP — No special protocols or WebSocket infrastructure required

• Automatic reconnection — The browser's EventSource API handles connection recovery automatically

• Firewall-friendly — Works through corporate proxies and firewalls that might block WebSocket connections

• Low overhead — Simpler than WebSockets when you don't need bidirectional communication

Universal Backend Support

Real-time updates now work seamlessly with both SQLite and PostgreSQL databases. Whether you're running MantisBase on an embedded device with SQLite or scaling up with PostgreSQL, you get the same real-time capabilities without changing your code.

Enhanced System Observability

System logs have been moved to a dedicated database and are now accessible through the /api/v1/logs endpoint, providing administrators with powerful filtering and pagination capabilities for monitoring and debugging.

Getting Started with Real-Time

Opening an SSE Connection

Connect to the real-time endpoint and subscribe to entity changes:

// Subscribe to changes on the 'posts' entity
const eventSource = new EventSource(
  'http://localhost:7070/api/v1/realtime?topics=posts'
);

// Listen for all events
eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received event:', data);
};

// Handle connection events
eventSource.onopen = () => {
  console.log('SSE connection established');
};

eventSource.onerror = (error) => {
  console.error('SSE connection error:', error);
  // Browser automatically reconnects
};

Subscribing to Multiple Entities

You can monitor multiple database entities on a single connection:

// Subscribe to posts, comments, and users
const eventSource = new EventSource(
  'http://localhost:7070/api/v1/realtime?topics=posts,comments,users'
);

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  
  // Events include the entity name they originated from
  switch(data.entity) {
    case 'posts':
      updatePostsUI(data);
      break;
    case 'comments':
      updateCommentsUI(data);
      break;
    case 'users':
      updateUsersUI(data);
      break;
  }
};

Event Format

Real-time events follow a consistent JSON structure:

{
  "type": "INSERT",
  "entity": "posts",
  "data": {
    "id": "abc123",
    "title": "New Post Title",
    "content": "Post content here",
    "created": "2026-02-03T14:30:00Z",
    "updated": "2026-02-03T14:30:00Z"
  },
  "timestamp": "2026-02-03T14:30:00.123Z"
}

Event Types:

• INSERT — New record created

• UPDATE — Existing record modified

• DELETE — Record removed

Dynamic Topic Management

Update your subscriptions without reconnecting:

// Later, add more topics to the existing connection
async function subscribeToComments() {
  await fetch('http://localhost:7070/api/v1/realtime', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${yourAuthToken}`
    },
    body: JSON.stringify({
      client_id: clientId,
      topics: ['posts', 'comments']  // Updated topic list
    })
  });
}

// Or clear all subscriptions
async function unsubscribeAll() {
  await fetch('http://localhost:7070/api/v1/realtime', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${yourAuthToken}`
    },
    body: JSON.stringify({
      client_id: clientId,
      topics: []  // Empty array clears all topics
    })
  });
}

System Logs API

Access and monitor system logs with the new logs endpoint:

# Get recent logs (requires admin authentication)
curl -H "Authorization: Bearer <admin_token>" \
  http://localhost:7070/api/v1/logs

# Filter by log level
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?level=ERROR"

# Pagination
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?limit=50&offset=100"

# Filter by time range
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?from=2026-02-03T00:00:00Z&to=2026-02-03T23:59:59Z"

Migration Guide

If you're upgrading from v0.3.2, here's what you need to know:

Breaking Changes

There are no breaking changes in v0.3.3. The real-time API is a new addition that doesn't affect existing functionality. To enrol existing entities to be real-time "enabled", update the entities to trigger the real-time monitoring.

Security Considerations

Authentication for Real-Time

Real-time connections respect MantisBase's access control rules:

• For public topics (entities), no additional authentication is required.

• For non-public entities, the following rules are enforced:

  • List Rule: Used to list records in an entity.

  • Get Rule: Used to fetch a record by the record ID.

For non-public entities, provide the authorisation JWT token when creating the EventSource stream.

Installation & Upgrade

Download Pre-built Binaries

Download the latest release from GitHub Releases:

# Linux
wget https://github.com/allankoechke/mantisbase/releases/download/v0.3.3/mantisbase-linux-x64.zip
unzip mantisbase-linux-x64.zip
chmod +x mantisbase
./mantisbase serve

# Windows
# Download mantisbase-windows-x64.zip and extract
mantisbase.exe serve

Build from Source

git clone --recurse-submodules https://github.com/allankoechke/mantisbase.git
cd mantisbase
git checkout v0.3.3
cmake -B build
cmake --build build
./build/mantisbase serve

Bug Fixes

This release includes several important bug fixes:

• Fixed memory leak in SSE connection handling

• Improved database connection pooling for PostgreSQL

• Resolved race condition in concurrent entity updates

• Fixed authentication token refresh timing

• Corrected CORS headers for cross-origin real-time connections

Community & Support

Join our growing community:

• GitHub: github.com/allankoechke/mantisbase

• Documentation: allankoechke.github.io/mantisbase

• YouTube Tutorials: MantisBase Playlist

• Discussions: GitHub Discussions

• Support: Patreon

Acknowledgments

Thank you to everyone who contributed to this release through bug reports, feature requests, and code contributions. MantisBase is built for developers, by developers.

Checkout the video announcement here:

MantisBase—Lightning-fast BaaS in C++. One binary, full backend, anywhere.

For the full changelog, see v0.3.2...v0.3.3

The second edition of the Smart Living & Tech Leadership Conference 2025 ran for two days, with intense, future-focused dialogue. Day one set the foundation — sustainability, leadership, and the evolving role of cities in shaping human experience. Talks centred on energy management, mobility systems, and the ethics of digital transformation.

Day two shifted toward design, technology, and AI, unpacking how digital tools turn ideas into smarter, more liveable environments.

The Core Idea

Smart living isn’t about gadgets. It’s about intentional design. Every decision — spatial, structural, or digital — shapes how we live, move, and connect. Design is the link between people, data, and sustainability.

🗨️ "Design is not just what it looks like and feels like. Design is how it works."
— Steve Jobs

Steve Jobs was a visionary who foretold of what it became of today, a fusion of design and functionality. A move toward designing for use rather than designing for aesthetics alone.

My Session: Smart Living by Design

I presented “Smart Living by Design: Evolving from Digital Tools to AI Decisions.” The session traced design’s evolution—from manual drafting to data-driven modelling and now to intelligent, AI-augmented systems.

• Digital tools like Revit, Inventor, 3ds Max, and Maya redefined collaboration and precision.

• AI now extends creativity — generating forms, predicting outcomes, and guiding sustainable choices.

• Projects like Bernini show how AI-driven 3D generation can reduce waste and optimise performance.

• Digital twins enable continuous feedback loops between the real and virtual worlds, making smart cities adaptive by design.

The key takeaway: AI doesn’t replace creativity — it amplifies it. The future designer leads with intent, while AI accelerates exploration and insight.

Conversations That Followed

Post-session discussions were rich. People wanted to know how data models support interoperability across industries and where the limits of AI automation should be drawn. Others shared case studies on generative layouts for housing, mobility planning, and carbon analysis.

Outside the panels, the networking felt natural. Designers, engineers, urban planners, and educators connected over one shared vision — building systems that think with us, not for us.

Closing Thought

The conference reinforced a simple truth: design is leadership. Tools evolve, but human intention drives change. If we design with purpose — aligning creativity, technology, and sustainability — smart living becomes not an idea, but a lived reality.

Join the conversation!

Qt is a mature and feature-rich framework, but building flexible and declarative UIs often requires more than widgets and signals. That’s where Slint fits in. It provides a compact, declarative syntax for building modern UIs while staying native and lightweight.

Some Qt-based projects, like LibrePCB, already use Slint to modernise their UI without abandoning their existing Qt foundation. Check the full blog details here. Embedding Slint lets you:

• Keep your Qt app logic and backend code intact.

• Use Slint for fast, declarative, and maintainable UI layers.

• Mix and match Slint views with traditional Qt widgets.

• Gradually migrate UI parts without a full rewrite.

Watch the walkthrough video here:

Slint UI 102: Embedding Slint UI Within a Qt Application | C++

What you’ll learn:

• How to embed Slint UI components in a Qt app

• How to compile .slint files to native C++

• How to synchronise data between Qt and Slint

• How to manage event flow and cleanup

Resources:

• Slint Documentation: https://slint.dev/docs

• Slint Source Code: https://github.com/slint-ui/slint

• Slint C++ Template: https://github.com/slint-ui/slint-cpp-template

• Full Source Code from this video: https://github.com/allankoechke/qt-slint-integration-cpp

We have earlier introduced Mantis, a C++ BaaS toolkit, designed to be lightweight but powerful.

Introducing Mantis: The C++ Backend Framework Built for Simplicity and Speed

What's changed?

From our last v0.2.7 release a couple of weeks ago, we have some important fixes and improvements added to our v0.2.8 release. Have a look:

• PostgreSQL Support: v0.2.8 brings full PostgreSQL support for Linux builds. This allows for easy backend database switch when scaling is required while maintaining lightweight backend database (SQLite) where it's needed. How do you switch the database? Easy!

• Minor bug fixes & improvements: Lots of bugs were squashed, solving some performance issues as well as mending some issues that existed. Chief among these is matching data types compatibility for SQLite to/from PostgreSQL, forcing SQLite WAL mode checkpointing for every boot and refactoring project for performance improvements.

Release Release v0.2.8 · allankoechke/mantis

Getting Started?

We have a YouTube video to guide you out; don't fret. Checkout the video below for a walkthrough of the features mantis provides. If you have any question, lets discuss on YouTube or open a GitHub issue.

Enjoy!

We’ve shipped Mantis v0.2.7-beta, a new milestone for our lightweight pluggable backend-as-a-service (BaaS) framework written in C++. This release focuses on making file management a first-class feature while continuing to strengthen stability and prepare for broader database support.

Highlights

File and Files Field Support

• Records now support file and files fields.

• Upload, update, and remove files directly through record operations.

• Safer filename handling with sanitization for long names and unknown characters.

For more information on how to handle files in Mantis, check out the docs below:

mantis/doc/11.files.md at master · allankoechke/mantis

Health check Endpoint

• Added a /api/v1/health endpoint to make it easier to monitor and integrate Mantis into production setups.

Mantis Admin v0.1.7

• Updated to the latest version of the Mantis Admin dashboard with file management capabilities.

• Improved performance in the admin panel when working with larger datasets.

Bug Fixes and Improvements

• Better handling of database value binding with soci::values.

• Performance optimization for table ID generation.

• More consistent cleanup of file references for updates and removals.

PostgreSQL Support (WIP)

• Early integration of PostgreSQL via SOCI.

• Initial support for builds, CLI commands, and CI/CD integration.

• Still marked experimental but progressing quickly.

⚠️ PostgreSQL support is experimental and currently only built for Linux. The feature still has unresolved issues and may fail to launch entirely.

Why It Matters

Mantis is designed as an alternative to Firebase, Supabase, or PocketBase, but lighter, portable, and embeddable directly into your C++ applications. By keeping the runtime minimal and the architecture pluggable, we aim to make backend services faster to integrate and easier to run anywhere.

What’s Next?

• Complete PostgreSQL support for production use.

• Expanded file access controls.

• More integrations for different deployment targets.

Get Started

GitHub Repo: https://github.com/allankoechke/mantis
Release Page: https://github.com/allankoechke/mantis/releases/tag/v0.2.7-beta
Documentation: https://docs.mantisapp.dev/.

Feedback is welcome. If you try out the new file support or start testing PostgreSQL integration, please let us know how it works for you.

In a world dominated by heavyweight frameworks and bloated deployment pipelines, Mantis stands out as a fast, modular C++ backend library designed for simplicity, speed, and embeddability. Whether you're building for the cloud, desktop, or embedded systems, Mantis gives you modern backend capabilities with zero friction.

What Makes Mantis Special?

🚀 Single Binary Deployment

No containers, no dependencies, no problem. Mantis compiles to a single mantisapp binary that runs anywhere—just:

./mantisapp serve -p 8000

It’s ideal for embedded devices, desktop applications, or servers where simplicity is paramount.

Zero-Configuration REST APIs

Define your tables—and that’s it. Mantis auto-generates RESTful CRUD endpoints, complete with JWT-based authentication and fine-grained access control.

🧠 Minimal Runtime Footprint

With SQLite as the default database and tight memory usage, Mantis is engineered for environments where every byte counts.

Key Benefits That Set Mantis Apart

🔧 Embeddable by Design

Unlike traditional backends that require external deployment, Mantis can be embedded directly into your C++ application. Add backend functionality to Qt apps, CLI tools, or microservices—all from within your codebase.

🔐 Built-in Authentication & Security

Mantis handles token generation, validation, and route-level access control using JWT. You get secure, configurable auth out-of-the-box.

📊 Lightweight Admin Dashboard

Each Mantis deployment includes a built-in admin dashboard for managing tables, records, and users—no separate tooling or setup required.

🐳 Docker-Ready

Mantis offers a Docker image with volume mounting support, ideal for containerized environments and CI/CD pipelines.

🛠 Technology Stack

Mantis integrates robust C++ libraries to deliver production-grade performance:

• HTTP Server: httplib-cpp for lightweight HTTP(S) handling

• Database: SOCI as an abstraction layer (SQLite by default; MySQL/PostgreSQL coming soon)

• Authentication: l8w8jwt for secure token management

• Logging: spdlog for structured, high-performance logging

🚧 Future Vision: What’s Coming

Mantis isn’t just stable—it’s growing. Here’s what’s on the horizon:

• Real-Time Sync Engine
  WebSocket-powered data sync between clients and the backend—perfect for offline-first and collaborative apps.

• Full RDBMS Support
  Extend Mantis from SQLite to full support for MySQL and PostgreSQL with seamless migration tooling.

• Pluggable Middleware Architecture
  Customize request handling with user-defined middleware for logging, validation, authentication, or anything else.

Getting Started is Effortless

You can start using Mantis today in one of two ways:

Option 1: Use Prebuilt Binaries

Available for Linux (x86_64) and Windows (x64)—just download and run.

Option 2: Build From Source

If you're targeting another platform or want to embed Mantis into your own C++ application:

git clone --recurse-submodules https://github.com/allankoechke/mantis.git
cd mantis
cmake -B build
cmake --build build
./build/mantisapp serve -p 5000

Access the dashboard at http://localhost:5000/admin.

👉 Read the full setup guide here:
https://allankoechke.github.io/mantis/setup.html

🌟 Why Choose Mantis?

In a space filled with over-engineered solutions, Mantis offers a refreshing alternative: modern backend functionality in a compact, embeddable C++ package. Whether you're targeting embedded devices, developer tools, or just want a backend that won’t get in your way—Mantis delivers.

Ready to Try It?

Explore the GitHub repository, download the binaries, and see what lightweight backend development really feels like.

In the growing jungle of codebases, developer tools, and open-source libraries, one thing remains consistently frustrating: documentation. Whether they're too shallow, too outdated, or just missing altogether, bad docs slow everyone down. But what if you could talk to a codebase like you would a teammate? That’s where DeepWiki comes in.

DeepWiki | AI documentation you can talk to, for every repo

What’s DeepWiki?

It provides up-to-date documentation for any repo in the world that you can talk to. At first glance, you might consider it similar to your favorite LLM, but with the added context of a codebase.

💡 A wiki is a form of hypertext publication on the internet which is collaboratively edited and managed by its audience directly through a web browser. A typical wiki contains multiple pages that can either be edited by the public or limited to use within an organization for maintaining its internal knowledge base.

DeepWiki is powered by Devin AI, but over the past few months, there have been new open-source entrants to the space providing the same functionality.

Where does it find its use?

Consider this: the quality of documentation for repositories can range from excellent to inadequate. Imagine bumping into a repo with no docs, but it seems like a good fit for your needs. This scenario is where DeepWiki can help you create documentation for human understanding without needing to read through the entire codebase line by line.

You ask, it answers. From "What does this function do?" to "How does authentication work in this repo?" DeepWiki gives you direct, conversational insight based on the actual code, not assumptions.

It’s particularly useful when:

• You inherit a legacy code and need to quickly catch up.

• You're actively participating in open-source projects and seeking to understand the internal workings.

• You’re assessing a new library or tool and need to grasp its internals without reading 10 files.

But how does it work?

Behind the scenes, DeepWiki syncs with the repository and builds an internal understanding of the code—structure, logic, and behavior. It doesn’t just summarize; it contextualizes. Ask a question, and it doesn’t respond based on generic training but refers to the actual code. That’s the difference.

How do I get started?

It's actually quite simple. On any GitHub repo you need to look into, replace the GitHub with the DeepWiki domain. For instance, for the SQLite repo above, replace https://github.com/sqlite/sqlite to https://deepwiki.com/sqlite/sqliteand there you'll be ready to chat with your repo.

⚠️ Note that not all repos are already indexed. For those that aren't, you'll have to request indexing and provide your email, and you'll be notified once indexing is completed. Usually in less than an hour or so.

Why it matters

We’re entering a world where shipping fast isn't enough; you also need to understand fast. DeepWiki makes technical onboarding smoother, reduces context-switching, and adds clarity to chaos, especially in large or under-documented codebases.

Sure, it’s not a silver bullet. It won’t replace solid developer docs. But it’s a powerful fallback when the docs are missing, outdated, or nonexistent.

Final thoughts

In a way, DeepWiki brings back the original promise of AI in dev tooling—not to replace developers, but to augment them. It’s not just about code completion or chat-based assistance anymore; it’s about deep understanding. And in that space, DeepWiki has carved out something genuinely useful.

Whether you're delving deeply into a complex system or simply exploring a new library, DeepWiki is a valuable resource.

FAQs

1. What is DeepWiki, and how does it work?

DeepWiki is an AI-powered tool by Devin AI that generates real-time, conversational documentation for any code repository. It analyzes the codebase and lets developers ask natural language questions to understand functionality, architecture, and workflows.

2. Can DeepWiki document private or internal repositories?

Yes, DeepWiki can be used with private repositories as long as you grant it access. It can then generate documentation and allow conversational querying based on your internal codebase.

3. How is DeepWiki different from ChatGPT or other AI coding assistants?

While general AI assistants like ChatGPT are trained on broad programming knowledge, DeepWiki is built to ingest and understand specific repositories, offering contextual, code-aware responses tailored to your exact codebase.

4. Is DeepWiki useful for teams and enterprise-level development?

Absolutely. DeepWiki can dramatically speed up developer onboarding, reduce time spent searching through code, and improve collaboration by acting as a living, interactive documentation layer for your projects.

5. Does DeepWiki replace traditional documentation?

No, but it complements it. While human-written documentation provides structure and intent, DeepWiki helps fill gaps, explain code in real time, and answer questions dynamically—especially when traditional docs are missing or outdated.

Originally posted at:

Autodesk Developer BlogUpgrading 3ds Max .NET projects from .NET Framework to .NET 8

3ds Max 2025 and earlier versions have used the .NET Framework for building plugins, but, with the VFX world transitioning to .NET, 3ds Max 2026 brings this support with it. As such, .NET projects require a bit of housekeeping to get them compiled and working in .NET 8 for our case. This blog is a simple walkthrough of the upgrade process, using the public Explode Geometry Sample hosted here.

The Upgrade Assistant

Microsoft provides an Upgrade Assistant extension to help with porting .NET Framework projects to .NET as well as .NET Core to .NET and much more. The tool simplifies and aids in handling the upgrade intricacies, leaving just a few more steps for us to complete.

First, to get things going, check if you have the Upgrade Assistant installed. If not installed, the Visual Studio Extensions Manager should be your first stop. With Visual Studio opened, navigate to Menu > Extensions > Manage Extensions. Under the Extensions Manager, search for Upgrade Assistant and get it installed as shown below.

With the assistant downloaded, follow the instructions to get it installed. This may include having to restart the IDE to get the extension installed and loaded for use.

Please note that the Upgrade Assistant is available as both a Visual Studio extension and a command-line utility. In this blog, we will only cover using the Visual Studio extension.

Explode Geometry Project .NET Upgrade

Let's work with our [ADN Explode Geometry Sample] (GitHub link) available on GitHub and see how we can get it building and running in .NET 8.

Fetching the project

This is an easy step: clone the repo (SSH, HTTPS, ZIP, or any format you prefer). Note that our GitHub repo is already updated, so fetch the older tagged version for the 2025 code for the sample.

git clone --branch v2.7 https://github.com/ADN-DevTech/3dsMax-Explode-Geometry
cd 3dsMax-Explode-Geometry

In the Source folder, open the .csproj in Visual Studio.

Upgrading to .NET the Assistant way

As detailed in the Microsoft blog on the assistant, we can upgrade by right-clicking the project and selecting Upgrade. This opens a new project upgrade page.

Here, we select the project upgrade way and work with the in-place project upgrade, but feel free to test the other options if they suit your needs.

With the upgrade type ironed out, next, we need to select the .NET version to upgrade to. For our case, we are going for .NET 8.0 LTS; this is the expectation for 3ds Max 2026 .NET plugins. You may optionally get an action requirement to download and install .NET SDK if you don't have it yet; if so, proceed with that installation, then pick it up from here once done.

In the next step, we are required to select the files to upgrade. By default, all files in the project are checked, including the project file. Let's leave it as is and proceed with upgrading the selection. After the process completes, if no errors come up, then our project will have been transformed.

Probably, the project will try to build but fail; we will fix that shortly. To check the logs, switch the combo box as shown below to the Upgrade Assistant option.

At the end of this process, you should have a project file `.csproj` that has been updated to conform to the .NET 8 project format. Running the build fails due to missing references to the Autodesk assemblies that may have been dropped in the upgrade process. Don't worry; fixing this is easy!

To fix the missing Autodesk assemblies or any other internal or 3rd party assemblies, we can achieve that either by;

• Directly edit the csproj file by copying the ItemGroup for the assemblies from the old project file and updating where necessary. For instance, for the Autodesk.Max.dll assembly, we can have it included in the new project file as shown below, with the version updated to 2026, of course. The same will be done for the other project dependencies like CSharpUtilities.dll, ManagedServices.dll, etc.

<ItemGroup>
  <Reference Include="Autodesk.Max">
    <HintPath>$(ADSK_3DSMAX_x64_2026)\Autodesk.Max.dll</HintPath>
    <Private>False</Private>
  </Reference> .... other assemblies
</ItemGroup>

• Another way is making use of the Visual Studio Reference Manager that is accessed from the Menu > Project > Add Project Reference > Browse & find your assemblies. Once all intended libraries are selected, click OK to add them. Just as in the option above, the new assemblies will be added back into the project file. Just FYI, we can change the assembly paths for the Autodesk assemblies to make use of the path variables. This way, any user can use our plugin despite the installation path they chose. For our case, we will use the path as $(ADSK_3DSMAX_x64_2026)\<assembly name>. 

At this stage, we can build our project, and everything should now be okay. But, looking at the logs, our build outputs are going to the default Visual Studio project build directory and not the one defined under our debug/release property group. In .NET Framework project configuration, we had defined <OutputPath> inside each build type (Build/Debug); in .NET, we define it inside the first global <PropertyGroup> where we have our project defaults, as shown below:

<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>  
  ... the other config here
  <OutputPath>C:\Our\intended\path\for\the\assembly</OutputPath> 
</PropertyGroup>

For our case, we will be using the Autodesk plugin path as our output path. This way, any plugin development changes can be updated in the plugin directory for testing.

Note: There may be extra steps to getting the assembly loaded into 3ds Max. If using PackageContents.xml, update where necessary to get the assembly and its dependencies loaded. Refer to the following documentation pages for help: Menu System Migration, Packaging Samples 

Final Housekeeping 

As a close, we need to do a bit of housekeeping. Here are a few things to consider:

• Setting included assemblies as not private: When we add assembly references in our project, the build process ends up copying the assembly references and their dependencies to the `OutputPath` directory, which is not the intended behavior. This results in duplication of assemblies, which may cause 3ds Max to crash. To resolve this, update each of the included assemblies as follows:

<Reference Include="ManagedServices"> 
  <HintPath> $(ADSK_3DSMAX_x64_2026)\ManagedServices.dll </HintPath>  
  <Private> false </Private> 
</Reference> 

• Disabling AppendTargetFrameworkToOutputPath flag: Since plugins for 3ds Max are meant for Windows, we can disable the flag above to ensure the assemblies don't end up nested in a target framework directory.

<AppendTargetFrameworkToOutputPath> false </AppendTargetFrameworkToOutputPath>

• Updating/bumping up plugin versions. This applies to both ApplicationVersion and AssemblyVersion

• Cleaning up some left-behind <ItemGroup> locks, which are not required in .NET 8.

• Since our plugin is intended to run only on the Windows platform, expect to see lots of warnings on platform compatibility. We can safely ignore these warnings using the snippet below:

<NoWarn>$(NoWarn);CA1416</NoWarn>

You can find the complete upgraded sample on our ADN GitHub repo for reference.

What did I miss out on? Please let us know! Happy upgrading: smile:!

A few weeks ago, 3ds Max 2026 saw its official release, introducing new features and capabilities for both artists and developers. With this release, 3ds Max saw many upgrades in Arnold to 5.8, Substance to 3.0.8, performance improvements in different modifiers, and much more. Refer to the release page for a detailed feature change for 3ds Max 2026.

Originally Posted At:

Autodesk Developer BlogWhat’s new in 3ds Max 2026?

SDK Changes

First, let's discuss the SDK changes that came with 3ds Max 2025 last year. We didn't have full information then, as there were breaking changes that are now fully documented.

•  3ds Max 2025 came with a revamped new menu system. The update necessitates the rewriting of all plugins that generate menus or quad menus to align with 3ds Max 2025. Check out more information on the menu changes, menu migration guide, and general plugin migration guide to 2025 using the Explode Geometry Sample.

With that out of the way, what's new in 2026?

• NET 8.0 Support: In 2026, .NET 8 support for plugin development was introduced to align with Autodesk's goal of updating all our projects to more modern standards. This upgrade is a shift from the framework-based projects of previous 3ds Max versions; as such, this breaking change will require project restructuring and rebuilding to work in 2026. Refer to our porting guide from .NET Framework to .NET for plugins.

• Lots of minor API changes in ActionTable, Animatable, CustCont, ColorManagement, Menu System, etc. for performance and/or added functionality.

• SDK licensing updates: SDK header licenses have been updated for conformity to the Autodesk license agreement, which is provided at the time of installation or download.

• Updated samples and documentation to reflect API changes.

Refer to our What's New docs section for a full list of API & SDK changes in 2026.

3ds Max 2025 came with some breaking changes that marked an era of new approaches aimed at improving performance at the core. As a result, some tools tailored to pre-2025 3ds Max versions may fail to load into 2025. In this blog, we will give you a walkthrough of how to handle porting a plugin to 2025, using one of our samples as a base example.

Originally Posted:

Autodesk Developer BlogPorting Plugins from 3ds Max 2024 to 3ds Max 2025

What Changed in 2025?

2025 brings some exciting changes; here are some highlights:

• Menu Changes: 3ds Max 2025 introduces an overhaul of the menu system, deprecating the old MenuManager (menuMan) and introducing the new CuiMenuManager and its associated classes. This brings more ways of creating menus, statically or dynamically.

• shape.h: Introduced 8 helper methods for enhanced Bezier shape handling and end cap material options to improve shape rendering and control.

• spline3d.h: Added methods for checking spline segment linearity , managing angle constraints, and enhancing spline manipulation capabilities.

• splshape.h: Implemented methods to override spline closure prompts, providing customizable control over user interface prompts.

• mnmesh.h: Introduced new classes and optimizations for vertex origins and mesh management, focusing on performance improvements with complex meshes.

• Mesh.h: We have added a helper method in ScopedLockChannels to efficiently update transformed bounding boxes, thereby enhancing mesh rendering accuracy.

• MaxGuid.h: Introduced the MaxGuid class for GUID management within MaxSDK, facilitating efficient unique identifier handling.

• iparamm2.h: A virtual SetRange method has been added for defining UI control ranges, enabling flexible parameter range customization.

• imorpher.h: Established interface classes for Morpher modifiers, expanding morphing capabilities with multiple channels of geometric transformation control.

• control.h: Implemented the GetDefaultController method to select appropriate user controls based on parameter types, ensuring efficient and accurate UI element assignment.

Now that you have seen some SDK changes in 2025, let's see how you would port a 2024 sample to work with 3ds Max 2025.

Porting the Explode Geometry Sample

The Explode Geometry Sample is one of the sample plugins maintained by the ADN team, with the installer available on the Autodesk App Store and the source code hosted on the ADN GitHub repo. To begin the porting process, let's begin with fetching the code we will be working with.

Fetching the source code

Using your favourite tool, whether GitHub Desktop, SourceTree, the command line, etc., clone the Explode Geometry Sample. Note that you need to clone on the version tag indicated below, as the code has been updated already to support newer versions of 3ds Max.

// Lets fetch code from v2.6 tag which supports 3ds Max 2024
// https://github.com/ADN-DevTech/3dsMax-Explode-Geometry/releases/tag/v2.6
git clone --branch v2.6 https://github.com/ADN-DevTech/3dsMax-Explode-Geometry.git
cd 3dsMax-Explode-Geometry

Updating to 2025 Assembly Versions

First, let's start by updating the assembly reference version to 3ds Max 2025 as well as setting our assembly output directory to 2025. In the .csproj project file, update the occurrence of 2024 to 2025, the assumption here being that you already have the 3ds Max 2025 setup installed.

With the project version updated, another interesting section to update is in our AssemblyInfo.cs file. Here we have predefined assembly versions and other organizational details, which may need to be bumped up to match the 3ds Max 2025 version.

// Update the following two lines if need be
[assembly: AssemblyVersion("2.7.0.0")]
[assembly: AssemblyFileVersion("2.7.0.0")]

At this point, we have all versioning details updated and ready to work on 2025 feature changes. First, let's look at our core functionality.

Note: The system requirements for .NET are v4.8, if you have any build issues with version incompatibility, switch to v4.8.1.

MNVert Changes

As noted earlier about some small changes to the C++ API that affect .NET-generated code, MNVert is among the victims of performance optimization. With the C++ API dropping the original copy operator for the C++ default copy, making MNVert trivially copiable and allocatable. This subtle change that works the same on the C++ side results in missing the `Assign` operator on the .NET `MNVert`.

Below is the final output for the 2024 vs. 2025 `ExplodeGeometry` with the MNVert functionality unchanged. You will note that the 2025 version shows no shapes on the scene as the Assign method is missing, which assigns vertex points to the `polyNewFace` which we are using to create new faces.

 How can we remedy this? A quick fix is as shown below:

// Original code ..
polyNewFace.Mesh.V(k).Assign(vert);
// New code ...
polyNewFace.Mesh.V(k).P = vert.P;

Note that the method `Assign` still works on the `MNVert`, but this originates from the `FlagUser`, where `MNVert` derives from.

With that fixed, let's have a look at the menu system changes and how to effect those changes in our sample.

Upgrading to the new Menu System

Unfortunately, we will go over all the menu changes and how to make use of them here, but you can find a detailed guide on the following topic below:

• The Menu System: https://help.autodesk.com/view/MAXDEV/2025/ENU/?guid=GUID-FF48D0EC-6669-4EC7-AB43-E9998A14A198 & https://help.autodesk.com/view/MAXDEV/2025/ENU/?guid=menu_system

• Menu Migration Guide: https://help.autodesk.com/view/MAXDEV/2025/ENU/?guid=menu_migration_guide

 The sample packs a few useful packaging scripts and configuration files. This is where we will be modifying to set up the menu changes. But first, why do we need to make use of the menu in this sample?

The sample is distributed as part of the ADN samples through the Autodesk AppStore. As such, to invoke the sample:

• First, the assembly must be loaded to 3ds Max, which we are achieving by using the `PackageContents.xml` file. You can check the section on ` Packaging Your Project` in the Menu Migration Guide linked above.

• Secondly, we expose the action items through MacroScript. This is not necessary, as we can make use of the Action table IDs directly to invoke the .NET methods.

• Lastly, we create a menu entry under the `App Store` menu item on the main menu bar.

With all that in mind, let's navigate to the `PackageContents.xml` located in the `/Bundle2` directory and start the packaging process upgrade.

PackageContents.xml file

First, let's expand the package runtime environment to support 2025. This can be done by updating the `SeriesMax` value to 2025. Similarly, let's expand the `SeriesMax` for `macroscripts parts` segment as shown below:

<RuntimeRequirements
    OS="Win64"
    Platform="3ds Max"
    SeriesMin="2020"
    SeriesMax="2025"
/>
<Components Description="macroscripts parts">
    <RuntimeRequirements ... SeriesMax="2025" />
    ...
</Components>

With MacroScript support for 2025 added, let's add .NET assembly as shown below.

<Components Description="assemblies parts">
    <RuntimeRequirements OS="Win64" Platform="3ds Max" SeriesMin="2025" SeriesMax="2025" />
    <ComponentEntry AppName="ADNExplodeGeometry" Version="2.6.0" ModuleName="./Contents/ManagedAssemblies/2025/ADNExplodeGeometry.dll" AppDescription="..." />
</Components>

Lastly, let's add a post-startup script for 2025 that will create the menu entry for us on 3ds Max boot. Don't worry for now; we'll create the actual file and its contents next.

<Components Description="post-start-up scripts parts">
    <RuntimeRequirements OS="Win64" Platform="3ds Max" SeriesMin="2025" SeriesMax="2025" />
    <ComponentEntry AppName="ADNExplodeGeometry" Version="2.6.0" ModuleName="./Contents/Post-Start-Up_Scripts/ADNGeometryExplodeSetupMenu2025.ms" AppDescription="Setup Menu to execute tool" />
</Components>

 Creating Menu Entries for 2025

As we noted above in the `PackageContents.xml`, we need to add a new post-startup script that will handle menu creation for our package when it's loaded. We create a new file called ` ADNGeometryExplodeSetupMenu2025.ms` in the `./Bundle2/Contents/Post-Start-Up_Scripts/` directory. Unlike 3ds Max 2024 and earlier versions, 2025 uses callbacks to register new menu entries for both regular and quad menus.

Within the file, let's add code to register our callback as well as get the main menu bar handle, which we will use to add new menu or submenu entries.

function menuCallback = (
    local menuMgr = callbacks.notificationParam()
    local mainMenuBar = menuMgr.mainMenuBar
)

-- Register Callback to the #CuiRegisterMenus
callbacks.removeScripts id:#adnExplodeGeomMenu
callbacks.addScript #cuiRegisterMenus menuCallback id:#adnExplodeGeomMenu

From the callback, we can access the menu manager, which hosts the main menu bar. We'll use the main menu bar to add a sub-menu item, which will have our menu item. Let's see how this is attained:

local stringAppStoreDefaultMenu = "App Store"
-- ADN Explode Geometry MXS
local stringMacroScriptName = "ADNExplodeGeomMS"
local stringMacroScriptCategory = "ADN Samples"
local helpMenuId = "cee8f758-2199-411b-81e7-d3ff4a80d143"

-- ID of the "App Store" menu in the menu bar. Use this ID when in need of adding new submenu items to the "App Store" menu entry.
local appStoreMenuId = "CC18FEFC-E8A4-4B16-B519-664E8FA3B549"
local newSubMenu = mainMenuBar.CreateSubMenu appStoreMenuId stringAppStoreDefaultMenu beforeId:helpMenuId

local separatorId = "96FB49D4-6263-4D8E-AC95-6D304673327B"
newSubMenu.CreateSeparator separatorId
local permanentId = stringMacroScriptName + "`" + stringMacroScriptCategory

-- 647394: MacroScript Action Table ID
newSubMenu.CreateAction "9DE5BDB9-E47F-4614-BDF8-C331B9B38C70" 647394 permanentId

This script defines some local variables like the menu entry name and our menu name, as well as some system data like the `Help Menu` GUID. From the main menu bar, we create a submenu called `App Store` using mainMenuBar.CreateSubMenu⁣. In the submenu, we add a separator at the end of the existing menu items, if any (in our case it may be empty), and then we create a new action entry for our sample.

With the script completed, we have one last piece remaining: adding the built assembly to the package.

Building & Adding Assembly to the Package

Under the `PackageContents.xml` section, we added a reference to a built assembly supporting 2025. From our upgraded project, we build our project, and the generated assembly is written out to our project's `OutputPath` directive. We can copy over this assembly to the `./Bundle2/Contents/ManagedAssemblies/2025/` directory.

The Bundle2 directory can be copied over as is now to the 3ds Max plugin directory, and on the next 3ds Max boot, the plugin will be loaded. For a full guide to plugin packaging, check the docs here: https://help.autodesk.com/view/MAXDEV/2025/ENU/?guid=packaging_plugins.

Final touches

To finalise the plugin details, we can do a couple of things:

•  Update version information for the plugin, as encompassed in the `PackageContents.xml`

• Documentation: Updating the documentation details for new features, fixes, and/or new version information.

We hope you found that helpful!

Early this year, I mentioned that I was excited about the Slint development and that it was a toolkit on top of my watchlist this year. Refer to my previous post below.

New Year: Slint, PocketBase, Rust, and C++; My watchlist

What is Slint? Slint is a cross-platform UI toolkit written in Rust with language bindings for C++, JavaScript, Python, and much more. As a cross-platform toolkit, Slint boasts of a couple of features:

• Separation between the UI and the business logic: Slint comes with its DSL called slint which allows writing UI and connecting it to the business logic written in our preferred supported language.

• Lightweight: Slint runs on both modern computers and small microcontrollers, with the Slint runtime fitting within 300 KiB of RAM.

• Native: Slint compiles to the native binary, which is excellent for performance.

• And much more!

Checkout a full walkthrough of Slint on our youtube channel below.

Youtube Video

Hope you find the video helpful. If you have any question, feel free to reach out! Cheers!

You’ve seen how PocketBase can simplify backend development with its one-file magic. But what if your project needs more — custom routes, database logic, or deeper control over how things run?

In this follow-up, we’ll dive into how to extend PocketBase with JavaScript (or Go) to create a backend that truly fits your business needs.

PocketBase: The Lightweight, One-File Backend You Didn’t Know You Needed

Extending PocketBase

The big question is, why would you want to extend PocketBase? Or more so, what's even the meaning of 'extend'? Let's have a look:

English defines the term 'extend' by:
- to make available
- to increase the scope, meaning, or application of
Source: https://www.merriam-webster.com/dictionary/extend

By the literal definition, extending PocketBase means adding the scope, functionality, or amending the existing functionality to act in a particular way.

Why extend PocketBase?

There are a ton of reasons why I would think of extending any software in existence, not just PocketBase. As the docs would put it;

... PocketBase can be used as a framework which enables you to write your own custom app business logic in Go or JavaScript and still have a portable backend at the end.

The essence of extending PocketBase is to customize and fit the functionality of PocketBase into your business context. I think of PocketBase as a canvas that you can tune to fit the design in mind. Here are some context-specific scenarios I would extend PocketBase:

• Adding custom routes: PocketBase creates API routes for record CRUD operations as well as authentication needs. However, you may need to have some routes to handle business needs, like an endpoint to compute reports or bulk import/export data from your database, etc.

• Binding to event hooks and intercepting responses: Pocketbase has several hooks, like app hooks, mailer hooks, real-time hooks, record model hooks, collection model hooks, request hooks, and base model hooks. These hooks allow us to modify the default process by checking user input, formatting data, removing data, etc.

• Register custom console commands: If you like playing with the PocketBase command-line utility, you may need to add some cmd commands to invoke your business logic. For instance, maybe migrate new data after installation or export existing data into JSON or even SQL?

There is quite a lot that can be added to PocketBase; check the docs section on Go and Javascript extending sections. Now that we’ve looked at why you might want to extend PocketBase, let’s talk about how you can do it — and which language might be the better fit for your use case.

Extend with Go or JavaScript?

One of the things to think about beforehand is the language to use to extend PocketBase. As the docs note, you can use PocketBase as a framework in Go or make use of the JavaScript SDK. Each has its own pros and cons. Let's have a look:

Extending with Go

PocketBase is written in Go, so if you have some basic knowledge in Go, you may find this option more applicable. Beware that you shall be building PocketBase, so you have lots of flexibility. For instance, you can add any 3rd party library to add any kind of functionality you need. In contrast, the Go APIs are verbose and may take time to master well.

PocketBase - Open Source backend in 1 file

Extending with JavaScript

In contrast with the Go approach, using JavaScript entails using the standard-built PocketBase binary. This helps you avoid the hassle of building the binary package, which, if you are using a tiny VPS, may take a couple of minutes, depending on the 3rd party packages added. A big plus here is, if you have knowledge in JavaScript, this would be the best place to drop your knowledge.

However, note that PocketBase uses the Goja module for loading and executing JavaScript, which lacks some functionalities unlike Node.js. As such, beware of some inherent limitations like missing concurrent execution using setTimeout and setInterval, support for Common JS modules (CJS), and the unique handler scopes for hooks, which make sharing variables outside the handler hard.

PocketBase - Open Source backend in 1 file

Something to keep in mind is that, with the embedded Goja package, browser-specific dependencies like fs, window, etc are not supported. As such, any 3rd-party modules that also depend on the same will not work.

Despite these limitations, JavaScript is still a powerful and accessible option for extending PocketBase — so let’s walk through what that actually looks like in practice.

How do we extend PocketBase with JavaScript?

Picking up from where we left in our last blog, your PocketBase directory should be structured as below:

Two things before we get started:

• Open the folder in Visual Studio Code so that we can add the scripts. Use any editor of your choosing.

• We'll be launching the pocketbase as a dev so that we can see the debug logs as the app starts. This may be helpful to monitor our hooks.

⚠️ Note: on UNIX platforms, changing the hooks will trigger the PocketBase to reload. On Windows, you will have to restart PocketBase manually.

In this section, we’ll explore how to extend PocketBase using JavaScript—covering topics such as adding new routes, custom database interactions, middleware, and hooks.

a. Adding New Routes

One of the primary ways to extend PocketBase is by creating custom API endpoints. Whether you need to aggregate data from various sources, perform specialized computations, or integrate third-party services, adding new routes gives you full control over your API. For example, you can define a new GET endpoint that fetches records from a specific collection:

// Example: Adding a custom GET route to PocketBase
routerAdd('GET', '/org/public-endpoint', (e) => {
    // Interact with the internal database, do your
    // aggregation and return data if successful
    e.json(200, { success: true })
});

// register "POST /org/secret-endpoint" route 
// (allowed only for authenticated users)
routerAdd("POST", "/org/secret-endpoint", (e) => {
    // do something ...
    return e.json(200, { "success": true })
}, $apis.requireAuth())

In this snippet, we add a route /org/public-endpoint and /org/private-endpoint allow for interaction with the database layer, with later requiring user log in. This approach encapsulates custom business logic without modifying the core system.

Once your routes are in place, the next natural step is working directly with the database to handle more advanced operations. So, let's take a look.

b. Custom Database Interactions

While PocketBase’s integrated database is designed for speed and simplicity, many applications require more advanced data manipulation. Using the PocketBase JavaScript SDK, you can execute complex queries, apply filters, sort data, and even perform batch updates. Consider the following example:

// register "POST /org/secret-endpoint" route (allowed only for authenticated users)
routerAdd("POST", "/org/secret-endpoint", (e) => {
    // Other code here ...

    // Lets run in a transaction block
    $app.runInTransaction((txApp) => {
      // update a record
      const record = txApp.findRecordById("articles", "RECORD_ID")
      record.set("status", "active")
      txApp.save(record) // Update Record

      // Create a record
      let collection = $app.findCollectionByNameOrId("<some collection>")
      let record = new Record(collection)
      record.set("title", "Lorem ipsum")
      record.set("active", true)
      txApp.save(record) // Save Record
  
      // run a custom raw query (doesn't fire event hooks)
      txApp.db().newQuery("DELETE FROM articles WHERE status = 'pending'").execute()
  })
    return e.json(200, { "success": true })
}, $apis.requireAuth())

Here, we are making use of transactions to ensure the changes are only committed if no error is thrown, lest we have a rollback. We update an existing record, create a new record, and delete another record, all operations that must execute successfully before we commit the changes to the database.

This example demonstrates how you can leverage the SDK to perform refined data operations—tailoring data retrieval to fit your application’s unique needs.

c. Integrating Middlewares

Beyond adding routes and custom database interactions, PocketBase supports middlewares, enabling you to inject logic at critical points in your application workflow. Middlewares can be essential in validating data before proceeding to the next step or even checking authentication and much more. Below is a simple middleware added to the /some/route route, any logical condition can be done there to decide if code execution should proceed to e.next() or return back to the client.

// Attach middleware to a single route
// "GET /some/route"
routerAdd("GET", "/some/route", (e) => {
    // Execute some db query, ...
    return e.string(200, "Hello!")
}, (e) => {
    // Do some checks here ...
    // Your custome middleware ...
    return e.next()
})

Utilizing middleware ensures that your customizations remain modular and centralized, which is especially beneficial for maintaining data integrity and consistency across your application.

PocketBase out of the box offers some middlewares for use. These include:

// Require the request client to be unauthenticated (aka. guest).
$apis.requireGuestOnly()

// Require the request client to be authenticated
// (optionally specify a list of allowed auth collection names, default to any).
$apis.requireAuth(optCollectionNames...)

// Require the request client to be authenticated as superuser
// (this is an alias for $apis.requireAuth("_superusers")).
$apis.requireSuperuserAuth()

// Require the request client to be authenticated as superuser OR
// regular auth record with id matching the specified route parameter (default to "id").
$apis.requireSuperuserOrOwnerAuth(ownerIdParam)

// Changes the global 32MB default request body size limit (set it to 0 for no limit).
// Note that system record routes have dynamic body size limit based on their collection field types.
$apis.bodyLimit(limitBytes)

// Compresses the HTTP response using Gzip compression scheme.
$apis.gzip()

// Instructs the activity logger to log only requests that have failed/returned an error.
$apis.skipSuccessActivityLog()

With your extensions in place — routes, data logic, and middleware — it's important to consider a few best practices to ensure your setup remains maintainable and secure over time.

Best Practices for Extending PocketBase

• Modular Code Organization: Separate your custom routes, hooks, and database logic into distinct modules. This practice not only makes your code more maintainable but also facilitates future scalability.

• Robust Error Handling: Implement comprehensive error handling within your custom endpoints and hooks to ensure that exceptions do not cascade into critical failures.

• Security Considerations: Always validate and sanitize incoming data, particularly in routes that interact directly with your database. This is crucial for preventing common vulnerabilities such as injection attacks.

• Clear Documentation: Maintain thorough documentation for each extension. This aids both current team members and future developers in understanding the purpose and functionality of your customizations.

Conclusion

Whether it’s by adding new routes to expose custom logic, leveraging the SDK for complex database interactions, or incorporating middleware and hooks to manage application flow, these techniques empower you to build a more dynamic and responsive system. Embrace these extension strategies to make PocketBase not just a backend service but a flexible platform that evolves with your project’s needs.

Similar to JavaScript, Go can be utilized in a similar manner to extend the core functionality. Whichever tool you pick, analyze the options and pick what works best for you and the team.

Have any questions, suggestions, or concerns? Please let me know below. Cheers!

There are times in development when you just wish the tooling could stay out of your way. You’re building a front-end — maybe a mobile app, maybe embedded — and all you want is to test some functionality: a login screen, some data flows, maybe a bit of access control. But before you know it, you’ve spun up yet another backend project, configured auth, debugged token issues, and lost half a day to infrastructure rather than solving your actual problem.

This happens to a lot of us. We start with a simple idea and end up building supporting systems that spiral beyond what we originally intended.

Sometimes, you don’t need the full stack. Sometimes, you just want something that works — fast, local, and lightweight.

"Everything should be made as simple as possible, but not simpler."

— Albert Einstein

That’s where PocketBase comes in.

What's PocketBase?

The Pocketbase team describes it as an open-source backend in 1 file. Yes, one single file. It's a complete (complete can be relative; keep that in mind) Backend as a Service (BaaS) solution that can be spun up to offer a fully fledged backend for mobile, desktop, web, and even embedded solutions.

Being a lightweight and performant backend solution, PocketBase makes use of SQLite as the storage database, which allows embedding the database into the final executable. For some use cases, this may be desirable, but for others, this may not be the database we desire, so there are trade-offs.

Why PocketBase?

PocketBase offers some eye-catching features out of the box without much tweaking. These are:

• Full backend in 1 file: This may not be a selling point to others, but it's a pretty big deal if you know. No messy node-modules folder and the million other files you need to run your node backend. PocketBase is written in Go, a statically typed and compiled language, which converts all user code into a single binary file. This file can be copied over to a target PC and run as is (if the architecture matches, of course), and all features are available for use.

• Real-time database: Once in a while, your project may need real-time subscription to record changes in your database. Data changes in the database emit events in which all subscribed clients are notified about.

• Authentication: By default, Pocketbase provides multiple methods of user authentication, including the standard username/password and OAuth protocols. Yes, you'll need to provide some credentials for the auth to work, but everything else is already implemented for you. Additionally, there are row-level access rules for record listing (List/Search Rules), record viewing (View rule), record creation (Create rule), record update (Update rule), and record delete (Delete rule), which allow for specifying rules users have to meet to perform the different tasks on the backend.

• File Storage: By default, PocketBase provides local storage for all files uploaded to the server and conveniently generates thumbnails where applicable. There is an additional option to connect to an S3 bucket for external file storage. File access can be regulated to public or token-based access to add a level of security to some files.

• Extensibility: PocketBase functionality can be extended using Go or JavaScript or used as is. This feature allows us to add new functionalities, modify existing ones, or even do things like provide your own database driver for specific use cases.

• APIs & SDK: By default, PocketBase creates a full CRUD API for every table (collection) you create. This allows querying the data via the API or any supported SDKs, allowing connection to front-end applications or 3rd party applications.

• Admin Dashboard: The backend comes with a beautiful admin dashboard, which allows admin management, collections, record operations, and much more!

Getting Started

So, how do you get and make use of PocketBase? First, navigate to the PocketBase documentation below, at the time of writing, latest version being v0.26.4;

PocketBase - Open Source backend in 1 file

Whether your current OS is Windows, Mac, or Linux on x86 or ARM64, download the corresponding binary zip file to your PC as shown below. Alternatively, navigate to the PocketBase release page and get the platform release binary from there.

Once downloaded, use your favorite zip tool to unzip the archive to your desired directory. This should give three files as shown below. Of concern, we'll only use the pocketbase binary file.

Starting the server

Starting the PocketBase server is pretty simple. As the docs say, execute the binary and pass the serve command argument to it as shown below. This will spin up the PocketBase server on the default port 8090 which we can override if need be. Being the first time spinning the server, a couple of directories will be created to store the database data, migration scripts, and file assets.

cd <unzipped directory>
./pocketbase serve

By default, the server in dev mode spins up the admin panel on our default browser for us to create a default admin user. This is the admin user we'll use for logging into the admin panel going forward.

From the admin panel, we can:

• Create New Collections: This is new tables in SQL terms, which will contain the record fields. Each collection can additionally specify the access rules; by default, only admins can perform CRUD on any collection data. There are 3 types of collections:

  • Base Type: Any general collection; this type adds a unique record ID and created and updated timestamps.

  • Auth Type: These records allow for logging into your applications. This template extends the Base Type with fields like password, tokenKey, email, verified, emailVisibility, etc which help in capturing user login information.

  • View Type: Analogous to the SQL View type, because it's exactly that. A read-only view created by writing an SQL statement.

• Create/Update/Delete Records: We can perform CRUD operations on data on existing collections.

• Manage Access Rules: The create collections drawer has two tabs or more, the second being API Rules in which we define conditional statements that are evaluated for the 5 rules (listRule, viewRule, createRule, updateRule, and deleteRule). Pocketbase offers some handy macros to access other collections and records, as well as request information to determine access metrics for the current user request. Check here for more information and syntax.

• Access Logs: PocketBase provides a view to check logs with a default 5-day retention period. You can change the log level from the gear icon here to set the kind of information to be logged.

• Application Settings: Application configuration like application name, URL, SMTP settings, and backup jobs as well as collection import/export are all housed here.

• Admin Accounts: We can also manage admin accounts from this pane on the bottom left side menu icon.

So how does it all work?

When we spin up the PocketBase server, the following directories will be created:

• /pb_data : This directory will have the data.db file to store the application data, an auxiliary.db file to store log data, and a/storage/ folder to store record files if we are keeping them in the local directory.

• /pb_migrations : Created once we modify collections while running in development mode. Here, any changes on the collections are recorded into a *.js file which can be pushed to a GitHub repo, and when we pull on another server/PC, starting the server recreates the collections from the migration scripts here.

• /pb_public : Not created by default, but we can create and put any static files we want the server to serve. For instance, put here the .html and .css files to have them served.

• /pb_hooks : Not created by default, but here we can write *.pb.js scripts that extend the functionality of PocketBase. These scripts can add new routes, perform specific actions before writing data to the database, etc. Check on extending PocketBase in the docs on the full feature list we can do here.

With such a setup, we can copy the whole structure into a new computer and have the same functionality on the go.

How does it compare?

Of course, in the world of BaaS , there are several offerings. Of notable mentions:

• Google Firebase: Owned by Google, offering a free tier to some level, then a pay-per-consumption model kicks in. Uses two database kinds, Firestore and real-time database (JSON database). In terms of usability, you'll get lots of integration with the tons of Google services, which might be desirable but, of course, will be vendor-locked, and you can't host it yourself.

• AppWrite: A self-hostable BaaS offering a NoSQL database API but running MariaDB/MySQL under the hood. Has most of the features, but direct database access is a bit lacking, and I believe it's for a reason.

• SupaBase: Similar to PocketBase in terms of using a relational database and being self-hostable. The difference here is that SupaBase uses a PostgreSQL database, which can come in handy in cases where we need horizontal scaling and not just vertical scaling. If you feel PocketBase is not enough for you, this can be a better go-to for self-hosted options. Of course, it's more resource-hungry compared to PocketBase.

There are tons of choices, but it all depends on the task at hand. A balance between the effort needed, features desired, processing, etc. For instance, hosting AppWrite and SupaBase requires containerization, which adds a layer of complexity to set up but also hides a whole lot of mess when setting it up. Both are massive projects; as such, there are lots of moving pieces to consider, so containerization helps in such cases.

So, if you just needed a quick spin-up, I guess you are best sticking with PocketBase. Quick prototyping and fiddling do not need the painful hassle of looking for a hosting provider, learning a bit of Docker, or even messing with Firebase rules; maybe just get the <40mb pocketbase binary, and you are all set.

To every problem, there is a most simple solution.
Agatha Christie

What Next?

We'll soon do a walkthrough of setting up collections, record rules, API tests, and lastly extending PocketBase with JavaScript/Go. Meanwhile, play around with the docs, experiment a bit and discover the potential PocketBase can offer to your development journey.

I hope this was helpful; let me know your thoughts! Cheers!

When working with QML, you often need to position UI elements relative to a global or local coordinate system. To contextualize it, imagine you have your layout done with a sidebar on the left and the main context view taking over the remaining space.

Inside the main view, you need to spawn a popup that displays some information or even get user input for processing. A simple way to center your popup would be to manipulate the items `x` and `y` coordinate systems as shown below;

// Other QML imports here

Popup {
	width: 300
	height: 250
	
	// `app` here is the ID for the root window
	x: (app.width - width)/2
	y: (app.height - height)/2
}

As expected, the popup when opened is centered on both the horizontal and vertical axes of the parent view. On closer look, we can see the popups x-offset is larger on the left than on the right side of the popup. The screenshot below shows the effect of adding spacing in a RowLayout containing the SideBar and the MainContentItem. But why isn't the popup centered?

Remember that the popup centering by setting the x and y value is relative to the parent Item. In this case, we are creating the popup from within the MainContentItem. As such, the calculated x value is does not take into account the presence of the SideBar as well as the RowLayout spacing; hence, the spawned popup is off-center but spacing + sidebar width.

Quick Fix

A common approach I have seen on other codebases (including how I used to do it) is to use the mapToGlobal function to get the global coordinates and calculate the x and y offsets from it. In theory, this approach is correct; however, I've observed several novice errors, including my own. So, a quick solution for the xOffset would be;

// Other code as before
x: (app.width - width)/2 - ((app.width - width)/2 - mapToGlobal(0,0).x)
// Other code as before

What's all that mumbo jumbo? Basically, we are:

• Calculating the x center from the parent item using (app.width - width)/2

• We are calculating the difference between the mapped x-position of the (0,0) position of our popup and the global position and the x-center above. This, in theory, should give the offset to apply on the x-side to reposition the popup.

• Lastly, we subtract the offset from the x-center in step 1. In theory, this should center the popup in the window.

But, looking at the output window, our popup is way off-center. It was even better before, kind of; we have made it worse. Where did we go wrong?

Understanding mapToGlobal vs mapToItem

First, when an app draws its window, there are two coordinate systems at play here. One is the global coordinate relative to the monitor or screen. The next is the local coordinate relative to the app's top-left position, a.k.a., the origin (0,0) or the parent item.

For mapToGlobal, it converts the given local coordinate into a global screen coordinate. That is, whether the app is full-screen, maximized, or just taking a small portion, the coordinate returned is relative to the screen and not the window/app in question.

In contrast, mapToItem takes a target item as the first parameter and the coordinates to transform as the second and third parameters. This maps the current item's coordinate position to the item of interest.

How do we fix our `perfect` popup centering?

Quite simple now that we understand the concepts above. Let's map the popup’s origin position to the ApplicationWindow's contentItem to the x & y offsets. The returned offset x and y shall be subtracted from our x-center and y-center, respectively.

// Other code as before
x: (app.width - width)/2 - mapToItem(app.contentItem, 0,0).x
// Other code as before

As noted, `mapToItem` expects an item as a parameter. Our Window or ApplicationWindow is not an item and will throw an error if passed in. To resolve that, access the item within the window, which is usually the `contentItem`.

Conclusion

A similar approach can be used to apply the offset on the y-axis. I hope you found this informative; let me know how you would have done the alignment.

Cheers!

If you've worked with C++, even at a basic level, you've likely encountered pre-increment (++x), pre-decrement (--x), post-increment (x++), and post-decrement (x--). While these operators may behave similarly in C, they have distinct differences in C++.

For reference

Increment/decrement operators - cppreference.com

Pre-Increment Operator (++x)

Think of this operator as simply adding 1 to x. For example:

int main() {
    int x = 0;

    // Equivalent to y = x + 1;
    int y = ++x;

    // Prints `1`
    std::cout << y << std::endl;
}

pre-increment operator c++ code block

Here, x is incremented first, and then the new value is assigned to y.

Post-Increment Operator (x++)

Unlike pre-increment, the post-increment operator returns the original value of x before incrementing it. As cppreference explains, this operator creates a temporary copy of the object, then increments the original.

int main() {
    int x = 0;
    int y = x++;

    // Prints `0`
    std::cout << y << std::endl;

    // Prints `1`
    std::cout << x << std::endl;
}

post-increment operator c++ code block

Why is the output 0 instead of 1? Let's break it down:

1. A copy of x is created (both x and its copy are 0).

2. x is incremented to 1.

3. y is assigned the initial value of x (which was 0).

4. As a result, x becomes 1, while y remains 0.

A similar approach works for the pre- and post- decrement operators.

When to Use Pre- vs. Post-Increment/Decrement

It depends on what you need from your code.

• If you need the variable to be incremented/decremented before assignment or evaluation, use pre-increment/decrement (++x, --x).

• If you need to retain the original value before modifying it, use post-increment/decrement (x++, x--).

Operator Overloading

C++ allows operator overloading, so both pre- and post-increment/decrement can be customized for user-defined types. The Standard Library (STL) leverages this for types like std::atomic<T> and std::chrono::duration<Rep, Period>, enabling them to support these operators seamlessly.