<h1>Meet Nile Js</h1>
Nile Js is a backend framework I am building at Nile Squad Labs for the past couple of 12 months and running in production in all our systems. It is designed around two core primitives: services and actions.
A service groups related functionality. An action is a single unit of work within a service, validated inputs in, typed result out.
<h2>WHY?</h2>
Building a production-ready TypeScript backend often means stitching together validation, routing, database access, and error handling from scratch every time and spending hours setting up routing files, middleware chains, and error handlers without having wrote a single line of actual business logic yet.
This is common and the reality for developers using traditional frameworks like Express, FastAPI, or Django and it’s so outdated way on how a small team or fast moving team can ship business logic and main course first, neither does your coding agent find this sexy, tokens burnt over repetitive plumbing and API spec conventions that no one reads anymore… agents read and write the code now days.
Let me paint a picture. You want to build a task management API. Here’s what a typical Express setup looks like:
<pre><code class="language-typescript">
// routes/tasks.js

router.post(&#x27;/tasks/:id/complete&#x27;, authenticate, validateBody, async (req, res) =&gt; {

try {

const { id } = req.params;

const result = await completeTask(id);

res.status(200).json(result);

} catch (error) {

res.status(500).json({ error: error.message });

}

});

// repeat this pattern 50+ times for your API...

</code></pre>
Each endpoint requires:
Route definition
Middleware chain
Request/response parsing
Error handling boilerplate
Status code management
You’re building HTTP plumbing. A lot of HTTP plumbing.
And here’s the thing: if you want AI agents to call your API? Good luck. You need to document every endpoint, write OpenAPI specs, and build adapter layers or some MCP stuff so LLMs can understand your API structure.
And that’s too much work, this should be simpler and so…
Nile.js asks a radical question: What if we stopped thinking in HTTP endpoints and started thinking in business logic?
Instead of routes, you define actions. Instead of controllers, you organize actions into services. The HTTP layer? The framework handles it automatically.
Here’s the same task completion with Nile.js:
<pre><code class="language-typescript">
export const completeTaskAction = createAction({

name: &quot;complete&quot;,

description: &quot;Mark a task as complete&quot;,

validation: z.object({ id: z.string() }),

handler: async (data) =&gt; {

const result = await completeTask(data.id);

return Ok({ task: result });

},

});

export const services = createServices([

{

name: &quot;tasks&quot;,

description: &quot;Task management&quot;,

actions: [completeTaskAction],

},

]);

</code></pre>
That’s it. No routing files. No middleware chains. No error handler boilerplate. Just business logic.
Three Reasons This Matters
<ol>
<li>Developer Experience</li>
</ol>
With traditional frameworks, you’re managing two layers:
The HTTP machinery
Your actual business logic
With Nile.js, you’re only writing business logic. The framework handles the rest. Your mental model is simpler. Your code is cleaner.
<ol>
<li>Performance</li>
</ol>
Traditional frameworks do route matching at runtime. They parse the request, match it against your route definitions, and then execute your handler.
Nile.js pre-computes everything. Service names, action names, parameters—all resolved in O(1) time. Your API is faster, period.
<ol>
<li>AI Integration (The Future)</li>
</ol>
Here’s where Nile.js really shines.
Imagine you’re integrating an AI agent (like Claude or GPT-4) into your system. With traditional frameworks, you have to:
Document all endpoints manually
Write OpenAPI specs
Build complex adapter layers
Hope the LLM understands your API
With Nile.js? Your services are tool definitions. AI agents can discover and call your services natively. No adapters needed. No documentation to maintain separately.
// Your action automatically becomes a tool the AI can call with validation and on per action access control.
// AI can now invoke tasks.complete(), tasks.create(), etc. directly
The Bigger Picture
We’re at an inflection point. APIs are no longer just for humans. They’re for:
Mobile apps
Other services
AI agents
LLM-powered features
Traditional frameworks were built for a simpler time—when APIs were just HTTP endpoints consumed by frontend apps.
Nile.js is built for what’s coming next: backends that are simultaneously developer-friendly, AI-integrated, and blazingly fast.
Should You Switch?
If you’re building:
Modern SaaS products with AI features ✅
AI agent backends ✅
New projects where you want to move fast ✅
If you’re maintaining:
Legacy systems built on Express/Django ⚠️ (probably not worth migrating)
Heavy monoliths with complex routing ⚠️ (Nile.js is service-oriented)
Final Thought
Every major framework shift in the past 20 years has come with a simple promise: Let developers focus on what matters.
Rails: Focus on models, not SQL. React: Focus on UI, not DOM manipulation. Nile.js: Focus on business logic and being agent ready out of the box, not HTTP machinery and not humans only but for agents and the humans.
It’s a simple idea. But for the time I have been using it with my team and a few friends it’s surprisingly good and you can’t go back after trying it out.

Hussein Kizz

Nile.js is a TypeScript backend framework built around services and actions instead of traditional HTTP routing. It eliminates boilerplate like route definitions, middleware chains, and error handlers, letting developers focus purely on business logic. The framework pre-computes routing for O(1) performance and is designed to natively expose services as AI agent tool definitions, removing the need for OpenAPI specs or adapter layers when integrating LLMs like Claude or GPT-4.

A backend framework that ditches your outdated REST conventions - Nile Js

Creator of Nile here, ask me anything guys?