next-zero-rpc 0.1.7 → 0.1.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +24 -26
- package/package.json +1 -1
- package/templates/apiRegistry.ts +4 -1
package/README.md
CHANGED
|
@@ -38,29 +38,29 @@ if (err) {
|
|
|
38
38
|
}
|
|
39
39
|
```
|
|
40
40
|
|
|
41
|
-
###
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
|
46
|
-
|
|
|
47
|
-
| Type-safe paths
|
|
48
|
-
|
|
|
49
|
-
|
|
|
50
|
-
|
|
|
51
|
-
|
|
|
52
|
-
|
|
|
53
|
-
|
|
|
54
|
-
|
|
|
55
|
-
|
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
41
|
+
### The 2026 Ecosystem Comparison
|
|
42
|
+
|
|
43
|
+
| Feature | next-zero-rpc | tRPC | ts-rest | raw fetch |
|
|
44
|
+
| --------------------------- | -------------------------------------- | --------------------------------- | ------------------------------- | ----------------- |
|
|
45
|
+
| Primary Philosophy | Invisible type bridge | End-to-end framework | Contract-first API | Platform standard |
|
|
46
|
+
| Source of Truth | Next.js Route Handlers | tRPC Routers / Procedures | Shared contract.ts file | None |
|
|
47
|
+
| Type-safe paths & responses | ✅ | ✅ | ✅ | ❌ |
|
|
48
|
+
| Per-route error narrowing | ✅ (via TypeScript generics) | ❌ (Global error shapes) | ❌ (Standardized HTTP errors) | ❌ |
|
|
49
|
+
| Next.js App Router Native | ✅ (Zero changes to standard handlers) | ❌ (Requires tRPC adapters) | ❌ (Requires ts-rest adapters) | ✅ |
|
|
50
|
+
| Input Validation | Bring-your-own | Built-in (Zod heavily favored) | Built-in (Zod favored) | Bring-your-own |
|
|
51
|
+
| OpenAPI Generation | ❌ | ❌ (Requires third-party plugins) | ✅ (First-class citizen) | ❌ |
|
|
52
|
+
| Client Runtime Size | ~1.8 KB | ~15 KB | ~3-5 KB | 0 KB |
|
|
53
|
+
| Server Actions Integration | ✅ (Tuple-based Go-style returns) | ✅ (Excellent RSC/Action support) | Partial (Focus remains on REST) | N/A |
|
|
54
|
+
| Non-TS Client Support | ❌ | ❌ | ✅ (Via standard REST/OpenAPI) | ✅ |
|
|
55
|
+
| Ecosystem & Community | Niche / Lightweight | Massive / Enterprise-grade | Very Strong / Standardized | Ubiquitous |
|
|
56
|
+
|
|
57
|
+
#### Architectural Breakdown: Which to Choose?
|
|
58
|
+
|
|
59
|
+
##### 1. next-zero-rpc (The Minimalist Bridge)
|
|
60
|
+
|
|
61
|
+
- **Best for:** Teams deeply invested in the Next.js App Router who want type safety without adopting a new framework paradigm.
|
|
62
|
+
- **The draw:** You write standard \`export async function GET(req)\` handlers. The library just quietly infers what you wrote. If you ever decide to remove the library, your backend code doesn't have to change at all.
|
|
63
|
+
- **The trade-off:** You give up the robust middleware pipelines, batched requests, and automatic OpenAPI generation that larger ecosystems provide.
|
|
64
64
|
|
|
65
65
|
## When to use this
|
|
66
66
|
|
|
@@ -69,8 +69,6 @@ if (err) {
|
|
|
69
69
|
- You're already writing plain Next.js App Router route handlers and want type-safe `fetch` calls _without restructuring your backend_ into tRPC procedures or ts-rest contracts
|
|
70
70
|
- Per-route error code narrowing matters to you — this is genuinely not available in tRPC or ts-rest out of the box
|
|
71
71
|
- You want a tiny client footprint (~1.8 KB) and zero ongoing npm dependencies
|
|
72
|
-
- You're building a solo or small-team Next.js project and prefer to own a few simple files over maintaining a dependency
|
|
73
|
-
|
|
74
72
|
|
|
75
73
|
## Philosophy
|
|
76
74
|
|
|
@@ -259,7 +257,7 @@ const [data, err] = await apiFetch("/api/users/123?include=profile", { method: "
|
|
|
259
257
|
|
|
260
258
|
### Static vs Dynamic Route Precedence
|
|
261
259
|
|
|
262
|
-
If you have overlapping static and dynamic routes (e.g., `/api/users/active` and `/api/users/[userId]`), `next-zero-rpc` correctly gives **exact static matches precedence** over dynamic segments at compile time.
|
|
260
|
+
If you have overlapping static and dynamic routes (e.g., `/api/users/active` and `/api/users/[userId]`), `next-zero-rpc` correctly gives **exact static matches precedence** over dynamic segments at compile time.
|
|
263
261
|
|
|
264
262
|
```typescript
|
|
265
263
|
// Safely infers the type of the `active` route, completely ignoring the `[userId]` route
|
package/package.json
CHANGED
package/templates/apiRegistry.ts
CHANGED
|
@@ -40,7 +40,10 @@ type StripQuery<Path extends string> = Path extends `${infer Base}?${string}` ?
|
|
|
40
40
|
export type FindMatchingRoute<Path extends string> = Path extends keyof KnownRoutes
|
|
41
41
|
? Path
|
|
42
42
|
: {
|
|
43
|
-
[K in keyof KnownRoutes & string]: MatchSegments<
|
|
43
|
+
[K in keyof KnownRoutes & string]: MatchSegments<
|
|
44
|
+
Split<StripQuery<Path>>,
|
|
45
|
+
Split<K>
|
|
46
|
+
> extends true
|
|
44
47
|
? K
|
|
45
48
|
: never;
|
|
46
49
|
}[keyof KnownRoutes & string];
|