springnext 0.0.5 → 0.0.6
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 +338 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1 +1,338 @@
|
|
|
1
|
-
# springnext
|
|
1
|
+
# springnext
|
|
2
|
+
|
|
3
|
+
<p align="center">
|
|
4
|
+
|
|
5
|
+
</p>
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
<p align="center">
|
|
9
|
+
<a href="https://badge.fury.io/js/springnext" target="_blank"><img src='https://badge.fury.io/js/springnext.svg'></img></a>
|
|
10
|
+
<img src='https://img.shields.io/npm/l/springnext'></img>
|
|
11
|
+
</p>
|
|
12
|
+
|
|
13
|
+
Scaffold Next.js full-stack modules in seconds with **springnext**.
|
|
14
|
+
|
|
15
|
+
Get a domain-focused architecture with a contract-first approach out of the box.
|
|
16
|
+
|
|
17
|
+
Batteries included! ✨
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
# What you get
|
|
22
|
+
|
|
23
|
+
After installing and initializing springnext, run one CLI command to generate a production-ready backend with React Query hooks:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
npx sn crud-api user
|
|
27
|
+
# sn stands for springnext
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
This will instantly scaffold:
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
server/
|
|
34
|
+
entities/user/... # user entity
|
|
35
|
+
stores/user/... # user stores (contract, in-memory, prisma)
|
|
36
|
+
services/user/... # service
|
|
37
|
+
controllers/user/... # API controller
|
|
38
|
+
|
|
39
|
+
app/api/user/... # api routes
|
|
40
|
+
|
|
41
|
+
ui/shared/queries/user/... # react queries
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Features DI, logging, in-memory stores, unified errors, and endpoint guards. Everything is ready after a few tweaks — see `Quick start with Prisma` for details.
|
|
45
|
+
|
|
46
|
+
All code is editable — scaffold parts individually or together. You can also scaffold front-end widgets. CLI commands are listed in `CLI commands glossary`.
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
# Quick start with Prisma
|
|
50
|
+
|
|
51
|
+
Assuming you have
|
|
52
|
+
|
|
53
|
+
- `Next.js` project with a generated `Prisma` client
|
|
54
|
+
- some `User` schema in your `Prisma` client
|
|
55
|
+
- enabled `experimentalDecorators` and `emitDecoratorMetadata` in `compilerOptions` section of `tsconfig.json`
|
|
56
|
+
- configured `@tanstack/react-query`
|
|
57
|
+
|
|
58
|
+
## Setup
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
# install springnext and peer dependencies
|
|
62
|
+
npm i inversify zod reflect-metadata springnext
|
|
63
|
+
|
|
64
|
+
# initialize springnext with absolute prisma client path
|
|
65
|
+
npx sn init prismaClientPath:@/generated/prisma/client
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Then plug your `Prisma` adapter in scaffolded `/server/infrastructure/prisma/client.ts` file.
|
|
69
|
+
|
|
70
|
+
## Scaffolding CRUD operations for `User`
|
|
71
|
+
|
|
72
|
+
```bash
|
|
73
|
+
npx sn crud-api user
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
This command scaffolds:
|
|
77
|
+
|
|
78
|
+
- `User` entity
|
|
79
|
+
- `UserStore` (with Prisma + RAM implementations)
|
|
80
|
+
- `UserService` (ready to be used in Server Actions)
|
|
81
|
+
- `UserController` proxying UserService methods
|
|
82
|
+
- `API routes` for UserController endpoints
|
|
83
|
+
- `React Query hooks` for fetching UserController from client-side
|
|
84
|
+
|
|
85
|
+
Then tweak a few files:
|
|
86
|
+
|
|
87
|
+
- `/domain/entities/user/user.entity.ts` → entity schema
|
|
88
|
+
- `/server/stores/user/user.store.ts` → store schemas (if default schemas do not fit your needs)
|
|
89
|
+
- `/server/stores/user/user.store.prisma.ts` → map `UserStore` contracts to Prisma client contracts
|
|
90
|
+
|
|
91
|
+
And after only one command and a few tweaks you have ready-to-use React Query hooks & Server Actions backend.
|
|
92
|
+
|
|
93
|
+
## Using scaffolded React query hooks
|
|
94
|
+
|
|
95
|
+
```
|
|
96
|
+
Schema: Client → React Query → API → Controller → Service → Store → DB
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
```tsx
|
|
100
|
+
'use client'
|
|
101
|
+
|
|
102
|
+
import { UserQueries } from '@/ui/shared/queries/user';
|
|
103
|
+
|
|
104
|
+
export default function Page() {
|
|
105
|
+
const { mutate: addUser } = UserQueries.usePOST()
|
|
106
|
+
const { data, isFetching } = UserQueries.useGET({ query: {} })
|
|
107
|
+
|
|
108
|
+
const addRandomUser = () => {
|
|
109
|
+
addUser({ body: { payload: { name: `${Math.random()}` } } })
|
|
110
|
+
}
|
|
111
|
+
|
|
112
|
+
return (
|
|
113
|
+
<div>
|
|
114
|
+
<button onClick={addRandomUser}>
|
|
115
|
+
New random user
|
|
116
|
+
</button>
|
|
117
|
+
|
|
118
|
+
{isFetching ? 'Loading users...' : JSON.stringify(data)}
|
|
119
|
+
</div>
|
|
120
|
+
);
|
|
121
|
+
}
|
|
122
|
+
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
## Using scaffolded Service methods as Next server actions
|
|
126
|
+
|
|
127
|
+
```
|
|
128
|
+
Schema: Server Action → Service → Store → DB
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
```tsx
|
|
132
|
+
'use server'
|
|
133
|
+
|
|
134
|
+
import { fromDI } from '@/server/di'
|
|
135
|
+
import type { UserService } from '@/server/services/user'
|
|
136
|
+
|
|
137
|
+
export default async function Page() {
|
|
138
|
+
/**
|
|
139
|
+
* FYI: `fromDI` argument is strongly typed and
|
|
140
|
+
* this type automatically updates after you scaffold
|
|
141
|
+
* anything. Cool, right?
|
|
142
|
+
*/
|
|
143
|
+
const userService = fromDI<UserService>('UserService')
|
|
144
|
+
|
|
145
|
+
const user1 = await userService.getDetails({
|
|
146
|
+
filter: { id: 'user-1-id' }
|
|
147
|
+
})
|
|
148
|
+
|
|
149
|
+
return <div>{JSON.stringify(user1)}</div>
|
|
150
|
+
}
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
# CLI commands glossary
|
|
154
|
+
|
|
155
|
+
## Initialization
|
|
156
|
+
|
|
157
|
+
| Command | Scaffolding result | Options |
|
|
158
|
+
| --------------- | ------------------ | ------------------------------------------------------------------------------------------------------------- |
|
|
159
|
+
| `npx sn init` | **init**ialization | pass `prismaClientPath:` to work with Prisma. E.g. `npx sn init prismaClientPath:@/generated/prisma/client` |
|
|
160
|
+
|
|
161
|
+
## Complex scaffolding
|
|
162
|
+
|
|
163
|
+
| Command | Scaffolding result |
|
|
164
|
+
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
165
|
+
| `npx sn crud-api <name>` | CRUD via Server Actions and React Query hooks. |
|
|
166
|
+
| `npx sn crud-service <name>` | CRUD via Server Actions (no Controllers, API Routes and React Query hooks). |
|
|
167
|
+
| `npx sn se <name>` | **s**tored **e**ntity: entity + store (contracts linked). |
|
|
168
|
+
| `npx sn rq` | API **r**outes and React **q**ueries for all of your controllers. This command will also remove endpoints which don't exist anymore with according React query hooks |
|
|
169
|
+
|
|
170
|
+
## Primary server modules scaffolding
|
|
171
|
+
|
|
172
|
+
| Command | Scaffolding result | Options |
|
|
173
|
+
| -------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
174
|
+
| `npx sn e <name>` | **e**ntity | |
|
|
175
|
+
| `npx sn vo <name>` | **v**alue **o**bject | |
|
|
176
|
+
| `npx sn cs <name>` | **c**ustom **s**tore (all schemas are `z.object({})`) | |
|
|
177
|
+
| `npx sn s <name>` | **s**ervice | `i:UserStore,Logger` will automatically inject `UserStore` and `Logger`. E.g. `npx sn s shop i:UserStore,ProductStore` will create `ShopService` with already injected `UserStore` and `ProductStore` |
|
|
178
|
+
| `npx sn c <name>` | **c**ontroller | `i:UserService` will automatically inject `UserService`. `Logger` and `Guards` are injected by default regardless of `i:` option |
|
|
179
|
+
|
|
180
|
+
## Auxiliary server modules scaffolding
|
|
181
|
+
|
|
182
|
+
| Command | Scaffolding result |
|
|
183
|
+
| ------------------- | ------------------------- |
|
|
184
|
+
| `npx sn p <name>` | **p**rovider |
|
|
185
|
+
| `npx sn i <name>` | **i**nfrastructure module |
|
|
186
|
+
|
|
187
|
+
## UI modules scaffolding
|
|
188
|
+
|
|
189
|
+
| Command | Scaffolding result |
|
|
190
|
+
| ------------------- | ------------------------- |
|
|
191
|
+
| `npx sn w <name>` | **w**idget |
|
|
192
|
+
| `npx sn lw <name>` | **l**ayouted **w**idget - widget with separated view layout |
|
|
193
|
+
|
|
194
|
+
# How to implement your own methods
|
|
195
|
+
|
|
196
|
+
## Zod schemas (module contracts)
|
|
197
|
+
|
|
198
|
+
Server method contracts are defined with Zod schemas in files like `user.controller.metadata.ts` or `product.service.metadata.ts`.
|
|
199
|
+
|
|
200
|
+
They:
|
|
201
|
+
|
|
202
|
+
- validate data at runtime
|
|
203
|
+
- can be reused across layers (no separate DTOs needed)
|
|
204
|
+
- automatically infer types (no manual TypeScript work)
|
|
205
|
+
|
|
206
|
+
Service method description example:
|
|
207
|
+
|
|
208
|
+
```ts
|
|
209
|
+
// ...some service metadata
|
|
210
|
+
orderDetails: {
|
|
211
|
+
payload: Order.schema.pick({
|
|
212
|
+
name: true,
|
|
213
|
+
createdDate: true
|
|
214
|
+
}),
|
|
215
|
+
response: z.object({
|
|
216
|
+
user: User.schema,
|
|
217
|
+
products: z.array(
|
|
218
|
+
Product.schema.omit({
|
|
219
|
+
price: true
|
|
220
|
+
})
|
|
221
|
+
)
|
|
222
|
+
})
|
|
223
|
+
}
|
|
224
|
+
// ...some service metadata
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
## Services
|
|
228
|
+
|
|
229
|
+
1. **Define method in metadata** (`*.service.metadata.ts`):
|
|
230
|
+
|
|
231
|
+
```ts
|
|
232
|
+
// ...service metadata
|
|
233
|
+
foo: {
|
|
234
|
+
request: z.object({ str: z.string() }),
|
|
235
|
+
response: z.object({ num: z.number() })
|
|
236
|
+
}
|
|
237
|
+
// ...service metadata
|
|
238
|
+
```
|
|
239
|
+
|
|
240
|
+
2. **Implement it in service** (`*.service.ts`):
|
|
241
|
+
|
|
242
|
+
```ts
|
|
243
|
+
// ...service class implementation
|
|
244
|
+
foo = this.methods('foo', async ({ str }) => {
|
|
245
|
+
// 'foo' string is strongly-typed, don't worry
|
|
246
|
+
// all input and output types are also infered
|
|
247
|
+
return { num: Number(str) }
|
|
248
|
+
})
|
|
249
|
+
// ..service class implementation
|
|
250
|
+
```
|
|
251
|
+
|
|
252
|
+
### Usage
|
|
253
|
+
|
|
254
|
+
Service methods can be used like a usual method of signature `(data: Request) => Promise<Response>`. E.g.
|
|
255
|
+
|
|
256
|
+
```ts
|
|
257
|
+
const { num } = await someMethod.foo({ str: '25' })
|
|
258
|
+
```
|
|
259
|
+
|
|
260
|
+
## Controllers
|
|
261
|
+
|
|
262
|
+
Same idea, but metadata uses optional `query` and optional `body` instead of abstract `request`.
|
|
263
|
+
|
|
264
|
+
1. **Metadata** (`*.controller.metadata.ts`):
|
|
265
|
+
|
|
266
|
+
```ts
|
|
267
|
+
// ...controller metadata
|
|
268
|
+
POST: {
|
|
269
|
+
query: z.object({ id: z.string() }),
|
|
270
|
+
body: z.object({ delta: z.number() }),
|
|
271
|
+
response: z.object({ success: z.boolean() })
|
|
272
|
+
}
|
|
273
|
+
// ...controller metadata
|
|
274
|
+
```
|
|
275
|
+
|
|
276
|
+
2. **Implementation** (`*.controller.ts`):
|
|
277
|
+
|
|
278
|
+
`query` and `body` are merged into one object in implementation:
|
|
279
|
+
|
|
280
|
+
```ts
|
|
281
|
+
// ...controller class implementation
|
|
282
|
+
POST = this.endpoints('POST', async ({ id, delta }) => {
|
|
283
|
+
return { success: true }
|
|
284
|
+
})
|
|
285
|
+
// ..controller class implementation
|
|
286
|
+
```
|
|
287
|
+
|
|
288
|
+
### React-queries and API routes
|
|
289
|
+
|
|
290
|
+
Once you done implementing controller methods, just run `nmx sn rq`. This command will generate up-to-date API routes and React Query hooks for all your controllers. You can call it also, for example, in a pre-commit hook so that your backend and frontend integration is always kept in sync.
|
|
291
|
+
|
|
292
|
+
# FAQ
|
|
293
|
+
|
|
294
|
+
## Why not use Nest or tRPC?
|
|
295
|
+
|
|
296
|
+
`springnext` combines the best of both worlds in one package while staying in plain Next.js:
|
|
297
|
+
|
|
298
|
+
| Feature | springnext | tRPC | Nest |
|
|
299
|
+
| ---------------------- | --------------------------------------------- | ------ | ------------------------------- |
|
|
300
|
+
| Architecture | contract-first, domain-focused | ❌ | module-centric, tightly coupled |
|
|
301
|
+
| Learning curve | Medium | Low | High |
|
|
302
|
+
| Type safety | ✅ - including run-time checks out of the box | ✅ | ⚠️ |
|
|
303
|
+
| Scaffolding | ✅ - production-ready full-stack | ❌ | ⚠️ |
|
|
304
|
+
| Boilerplate | ✅ - Low | ✅ | ❌ - High |
|
|
305
|
+
| No framework lock-in | ✅ | ✅ | ❌ |
|
|
306
|
+
| Single source of truth | ✅ (schemas) | ⚠️ | ❌ |
|
|
307
|
+
| Time to first feature | ✅ instant full-stack | ⚡ fast | 🐢 slow |
|
|
308
|
+
| Code ownership | ✅ full (generated, editable) | ✅ | ⚠️ (framework patterns) |
|
|
309
|
+
|
|
310
|
+
|
|
311
|
+
## What does domain-focused mean?
|
|
312
|
+
|
|
313
|
+
springnext puts your business domain first. Entities drive the architecture, so backend and frontend stay consistent.
|
|
314
|
+
|
|
315
|
+
## What does contract-first mean?
|
|
316
|
+
|
|
317
|
+
The behavior of all server modules in springnext is governed by Zod schemas. Function signatures and entity contracts are derived from these schemas. There is also automatic runtime validation to ensure that all data — function arguments and entity models — conform to their schemas.
|
|
318
|
+
|
|
319
|
+
## Can I tweak scaffolded files?
|
|
320
|
+
|
|
321
|
+
Yes — everything is fully editable, including configuration. Think of springnext as a shadcn-style approach for full-stack: scaffold first, then fully own the code. Moreover, in most of the cases your changes are preserved on subsequent generations. For example, if you modify a generated query and run `npx sn rq` later, your edits stay intact.
|
|
322
|
+
|
|
323
|
+
## Do I really need to understand DI and other fancy concepts to use springnext effectively?
|
|
324
|
+
|
|
325
|
+
Not really. springnext handles dependency injection (DI) for you using `inversifyjs`. You don’t need to set it up manually.
|
|
326
|
+
To get an instance of a service anywhere in your server code, just use:
|
|
327
|
+
|
|
328
|
+
```tsx
|
|
329
|
+
import { fromDI } from '@/server/di'
|
|
330
|
+
|
|
331
|
+
const userService = fromDI<UserService>('UserService')
|
|
332
|
+
```
|
|
333
|
+
|
|
334
|
+
Here, `fromDI` is strongly typed — your IDE will give autocomplete automatically.
|
|
335
|
+
|
|
336
|
+
## Why data layer modules are called `Stores` and not `Repositories`?
|
|
337
|
+
|
|
338
|
+
A “Repository” is a specific design pattern for managing data. springnext prefers Stores — a simple, flexible abstraction for your data layer that can adapt to your needs regardless of the specific pattern. This approach helps to keep your code simple, and it has been successfully used in other languages, like Go.
|