Browse Source

init: stub out basic resources, slight restructure, update readme

main
eday 2 years ago
parent
commit
a46eafd4e0
  1. 48
      README.md
  2. 12
      package.json
  3. 2
      src/app.ts
  4. 1
      src/comment/comment.model.ts
  5. 1
      src/community/community.model.ts
  6. 4
      src/database/knex.ts
  7. 0
      src/database/knexfile.ts
  8. 0
      src/database/migrations/20201101124110_initial.ts
  9. 0
      src/database/seeds/user_test_data.ts
  10. 1
      src/images/images.service.ts
  11. 1
      src/middleware/user-token.ts
  12. 4
      src/models/knex.ts
  13. 11
      src/models/user.ts
  14. 1
      src/post/post.model.ts
  15. 1
      src/private-message/private-message.model.ts
  16. 1
      src/report/report.model.ts
  17. 1
      src/site/site.model.ts
  18. 10
      src/user/README.md
  19. 2
      src/user/user.controller.ts
  20. 36
      src/user/user.model.ts
  21. 3
      src/user/user.service.ts

48
README.md

@ -13,66 +13,68 @@ In consideration but not shown here:
## Getting Started
If you have not already installed typescript as part of working on the hexbear/lemmy frontend or are new to node:
*Install NVM*
**Install NVM**
[NVM Repo](https://github.com/nvm-sh/nvm)
You can follow the instructions on their repo to also get the latest version of node for your OS of choice.
*Install Yarn*
**Install Yarn**
[Yarn](https://classic.yarnpkg.com/en/docs/install#debian-stable)
Yarn is the package manager we already use so it's suggested here.
*Install TypeScript*
**Install TypeScript**
`yarn global add typescript`
*Install Knex*
**Install Knex**
This step is optional for if you want to run migrations/seeders through the knex cli, it's fine to skip it of you dont want to do this step
`yarn global add knex`
*Seed Database*
See the notes section for setting up PG (or ignore this part and stub the data w/ static returns)
First setup the schema:
`knex migrate:latest`
Then insert sample data:
`knex seed:run`
Clone this repo and run `yarn` and start a local env with `yarn run dev`
**Starting the App**
Clone this repo and run `yarn` and start a local env with `yarn run dev`
Go to `http://localhost:8080` to play pong or `http://localhost:8080/api/v1/users` to see sample data
*Notes*
For the database side I would rec any setup guides from the main hexbear repo or running docker, for a quick setup here if you know how to setup postgresql then [EnterpriseDB](https://www.enterprisedb.com/downloads/postgres-postgresql-downloads) has installers for windows/osx/linux that will come with some management tools for qol. We currently use *version 12*.
**Migrations/Seeders**
To create a migration: `yarn run knex:migration-make migration_name_here`
To run all pending migrations: `yarn run knex:migration-run`
To create a seeder file: `yarn run knex:seed-make seed_name_here`
To run all seeds: `yarn run knex:seed-run`
To handle running specific migrations or seeds, the same scripts can be used but you'll need to specify the file name. For migrations: `knex migrate:(up|down) file_name` seeds: `knex seed:run --specific=file_name`
**Notes**
For the database side I would rec any setup guides from the main hexbear repo or running docker, for a quick setup here if you know how to setup postgresql then [EnterpriseDB](https://www.enterprisedb.com/downloads/postgres-postgresql-downloads) has installers for windows/osx/linux that will come with some management tools for qol. We currently use **version 12**.
## Goals / Why Rewrite / Why Typescript?
We feel we have hit a dead end or brick wall with continuing to maintain the current backend in rust as-is and maintaining upstream compatibility. There are several architectural changes we would like to make that would both require forking and a significant rewrite of the current codebase. Since a rewrite is inevitable and rust/choice rust libs have shortcomings or simply arent ready for maintaining a web server, we have decided to use a new language. On the human side, the "core team" feels that the current tech stack is painful or slow to work with, makes onboarding difficult and has been a turn off from getting new contributors. So-
*Goals*
In the short/mid term we want to:
**Goals**
In the short/mid term we want to:
- Convert majority of client requests to the rest api away from websockets
- Build a v2 api with the goal of splitting the current request/response objects up (ie. make it possible to query smaller data sets so a User component isn't getting irrelevant data, basically make an actual modern/"standard" api)
- Use a mature query builder that allows rewriting the sql queries/joins to be sensible, not reliant on cross joins, can properly filter based on inputs etc
*Why Rewrite?*
In technical specifics
**Why Rewrite?**
In technical specifics
- Rust compile times are frustrating
- Many Rust libs are not mature enough for a small team web server to be a good idea, nor is the query building/orm side without strict limitations
In human terms
In human terms
- Some of us are facing severe burnout on Rust or dont find it fun for this project's specifics
- We're finding it difficult to keep contributing fixes because we have to code in a reactionary style and Rust does not lend itself to getting something quick done
- Rust learning curve is steep or the lang itself turns away new contributors
*Why Typescript?*
Technical:
**Why Typescript?**
Technical:
- It offers typing/auto-complete/other goodies to JS
- The ecosystem has _many_ mature libs web servers, middleware, querying, testing, documentation
- Iteration is quick and our BE/FE tech stack would be similar
- We do not face any optimization/performance issues that make compiled langs needed
Human:
Human:
- Most of us are familiar with TS/JS already
- Learning curve is small and we can maintain a codebase that is friendly to new devs or even someone new to coding
- The TS community is very friendly, welcoming and focused on accessibility. It's extremely fast growing and immensely popular for web projects- As such it offers the best chance to sustain the project via new members
But most importantly, *we want this to be fun*, even if that means putting in the work to fork and rewrite in a new language. There will be new pain points, new tech debt, and many human hours of work to even bring this to current 1:1 functionality, but that is _worth it_ if the end result is something we own, enjoy and can easily share.
But most importantly, **we want this to be fun**, even if that means putting in the work to fork and rewrite in a new language. There will be new pain points, new tech debt, and many human hours of work to even bring this to current 1:1 functionality, but that is _worth it_ if the end result is something we own, enjoy and can easily share.
## Thinking Ahead
Since this is just a showcase in "how it looks" and "why", we still have to decide on some things:

12
package.json

@ -1,13 +1,17 @@
{
"name": "hexscript-sample",
"version": "1.0.0",
"name": "hexbear",
"version": "0.0.1",
"main": "index.js",
"author": "the people",
"license": "MIT",
"scripts": {
"dev": "nodemon --watch 'src/**/*.ts' --exec ts-node src/index.ts",
"dev": "nodemon --watch 'src/**/*.ts' --exec ts-node src/app.ts",
"build": "tsc",
"start": "node dist/index.js"
"start": "node dist/index.js",
"knex:migration-make": "knex migrate:make --knexfile ./src/database/knexfile.ts",
"knex:migration-run": "knex migrate:latest --knexfile ./src/database/knexfile.ts",
"knex:seed-make": "knex seed:make --knexfile ./src/database/knexfile.ts",
"knex:seed-run": "knex seed:run --knexfile ./src/database/knexfile.ts"
},
"devDependencies": {
"@types/express": "^4.17.8",

src/index.ts → src/app.ts

1
src/comment/comment.model.ts

@ -0,0 +1 @@
// stub

1
src/community/community.model.ts

@ -0,0 +1 @@
// stub

4
src/database/knex.ts

@ -0,0 +1,4 @@
import Knex from 'knex';
import { default as KnexConfig } from './knexfile';
export const knex = Knex(KnexConfig.development);

src/knexfile.ts → src/database/knexfile.ts

src/migrations/20201101124110_initial.ts → src/database/migrations/20201101124110_initial.ts

src/seeds/user_test_data.ts → src/database/seeds/user_test_data.ts

1
src/images/images.service.ts

@ -0,0 +1 @@
// stub for pictrs

1
src/middleware/user-token.ts

@ -0,0 +1 @@
// stub

4
src/models/knex.ts

@ -1,4 +0,0 @@
import Knex from 'knex';
import { default as KnexConfig } from '../knexfile';
export const knex = Knex(KnexConfig.development);

11
src/models/user.ts

@ -1,11 +0,0 @@
import { QueryBuilder } from 'knex';
import { knex } from './knex';
export interface User {
id: number;
name: string;
}
export const getUsers = async (): Promise<User[]> => {
return await knex<User>('users');
}

1
src/post/post.model.ts

@ -0,0 +1 @@
// stub

1
src/private-message/private-message.model.ts

@ -0,0 +1 @@
// stub

1
src/report/report.model.ts

@ -0,0 +1 @@
// stub

1
src/site/site.model.ts

@ -0,0 +1 @@
// stub

10
src/user/README.md

@ -0,0 +1,10 @@
Just some thoughts.. At first glance it looks good to move all Resource_view to the actual resource, same for related things.
So for user this dir should hold:
user_view
user_tag
user_mention
user_mention_view
etc either as new models or baked into the User model and built up by `user.service` and repeat this for every other resource
I *also* thought that moderator/admin logic belongs here as theyre nothing more than special users whos functionality can be handled w/ middleware and additional service code

src/controllers/v1/users.ts → src/user/user.controller.ts

36
src/user/user.model.ts

@ -0,0 +1,36 @@
import { knex } from '../database/knex';
export interface User {
id: number;
name: string;
preferred_username?: string;
password_encrypted: string;
email?: string;
avatar?: string;
admin: boolean;
banned: boolean;
published: string;
updated?: string;
show_nsfw: boolean;
theme: string;
default_sort_type: number;
default_listing_type: number;
lang: string;
show_avatars: boolean;
send_notifications_to_email: boolean;
matrix_user_id?: string;
actor_id: string;
bio?: string;
local: boolean;
private_key?: string;
public_key?: string;
last_refreshed_at: string;
sitemod: boolean;
banner?: string;
has_2fa: boolean;
inbox_disabled: boolean;
}
export const getUsers = async (): Promise<User[]> => {
return await knex<User>('users');
}

3
src/user/user.service.ts

@ -0,0 +1,3 @@
// This should house biz logic related to the user resource - example - UserDetailResponse from lemmy is composed of several resources
// so this file could have a fn that calls the needed user.model logic and imports logic either from a comment and post service or model
// kinda analogous to lemmy src/api/user.rs but hopefully with more code dedupe and slimmer model/crud code
Loading…
Cancel
Save