1 | # @lbu/insight
|
2 |
|
3 | [![install size insight](https://packagephobia.com/badge?p=@lbu/insight)](https://packagephobia.com/result?p=@lbu/insight)
|
4 | ![lint-build-test](https://github.com/lightbasenl/lbu/workflows/lint-build-test/badge.svg)
|
5 |
|
6 | Collection of Lightbase backend utilities
|
7 |
|
8 | ---
|
9 |
|
10 | ## Features
|
11 |
|
12 | - Minimal project boilerplate
|
13 | - Script runner, can watch & reload almost anything
|
14 | - Flexible code generators supporting routers, validators, api clients, CRUD
|
15 | queries and more in the future.
|
16 | - Opinionated structured logging
|
17 | - Common Koa middleware wrapped in a single function
|
18 | - Various utilities like loading .env files, executing other processes and a
|
19 | basic string templating system
|
20 |
|
21 | ## Requirements
|
22 |
|
23 | - Node.js >= 14
|
24 | - Yarn 1.x.x
|
25 |
|
26 | ## Why
|
27 |
|
28 | Here at [lightbase](https://lightbase.nl) we had a constantly growing
|
29 | boilerplate for new projects. To facilitate our needs more and to stop copying
|
30 | and pasting things around this project was born. This project is for now
|
31 | tailored at monolithic projects.
|
32 |
|
33 | ## Features breakdown
|
34 |
|
35 | **@lbu/cli**:
|
36 |
|
37 | - Run user scripts (in watch mode)
|
38 | - Run the linter or tests
|
39 | - A LBU based boilerplate
|
40 |
|
41 | **@lbu/lint-config**:
|
42 |
|
43 | - All necessary ESLint and Prettier dependencies
|
44 | - Default configuration for ESLint and Prettier
|
45 |
|
46 | **@lbu/insight**:
|
47 |
|
48 | - A structured logger
|
49 | - Writing newline delimited JSON in production
|
50 | - Pretty printing for development
|
51 | - Various utilities to get insight in the running process
|
52 |
|
53 | **@lbu/stdlib**:
|
54 |
|
55 | - Various lodash inspired utilities (isNil, isPlainObject, ...)
|
56 | - Wrappers for child_process execution and spawning
|
57 | - Basic templating system
|
58 | - A `mainFn` wrapper that reads `.env` and calls the provided function if the
|
59 | file is the process entrypoint
|
60 | - Replacements for CommonJS `__dirname` and `__filename`
|
61 |
|
62 | **@lbu/server**:
|
63 |
|
64 | - Wrapper around Koa instance creation
|
65 | - 404 en error handling
|
66 | - Handle CORS
|
67 | - Send file helper
|
68 | - Re-exports koa-session and koa-compose
|
69 |
|
70 | **@lbu/store**:
|
71 |
|
72 | - Wrapper around the Minio S3 client
|
73 | - Wrapper around Postgres connection
|
74 | - Utilities for providing temporary databases in a test environment
|
75 | - Postgres migrations
|
76 | - Postgres and S3 combined for file storage
|
77 | - Caching files from S3 in memory or on local disk
|
78 | - Postgres powered JobQueue implementation
|
79 | - Supports priority, scheduling, multiple async workers
|
80 | - koa-session compatible SessionStore backed by Postgres
|
81 |
|
82 | **@lbu/code-gen**:
|
83 |
|
84 | - Code generators for the following:
|
85 | - router, with wildcard and path parameter support
|
86 | - validators, with pre- and postValidate hooks
|
87 | - queries, CRUD postgres queries
|
88 | - Axios based api client
|
89 | - Typescript or JSDoc types
|
90 | - An extendable set of types:
|
91 | - boolean, number, string;
|
92 | - object, array, any;
|
93 | - date, uuid;
|
94 | - generic, anyOf, reference;
|
95 | - Remote structure loader
|
96 | - OpenAPI to LBU converter
|
97 |
|
98 | ## Docs and development
|
99 |
|
100 | See [the website](https://lbu.lightbase.nl) for the changelog, all available
|
101 | APIs and various guides.
|
102 |
|
103 | For contributing see [contributing.md](https://lbu.lightbase.nl/#/contributing).
|
104 |
|
105 | ## New features
|
106 |
|
107 | New features added should fall under the following categories:
|
108 |
|
109 | - It improves the interface between api and client in some way. An example may
|
110 | be to support websockets in @lbu/code-gen
|
111 | - It improves the developer experience one way or another while developing an
|
112 | api For example the `lbu docker` commands or various utilities provided by
|
113 | @lbu/stdlib
|
114 |
|
115 | Although some parts heavily rely on conventions set by the packages, we
|
116 | currently aim not to be a framework. However, the idea of being a bit more of
|
117 | framework is not completely out of the door yet.
|