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.
Files changed (2) hide show
  1. package/README.md +338 -1
  2. 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.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "springnext",
3
- "version": "0.0.5",
3
+ "version": "0.0.6",
4
4
  "type": "module",
5
5
  "license": "MIT",
6
6
  "exports": {