springnext 0.0.5 → 0.0.7

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