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