Upload API Prep Part 3: Add Project and User Insert API #34
Conversation
francisduvivier
force-pushed
the
feature/26-upload-api-part-3
branch
from
100db5c to
47029b6
Compare
francisduvivier
force-pushed
the
feature/26-upload-api-part-3
branch
2 times, most recently
from
5dce7f9 to
4dcd6d7
Compare
francisduvivier
changed the title
francisduvivier
force-pushed
the
feature/26-upload-api-part-2
branch
from
bbd055c to
da8d725
Compare
francisduvivier
force-pushed
the
feature/26-upload-api-part-3
branch
from
dbbb2c2 to
102bf05
Compare
francisduvivier
force-pushed
the
feature/26-upload-api-part-3
branch
from
102bf05 to
79342cb
Compare
francisduvivier
force-pushed
the
feature/26-upload-api-part-2
branch
from
a94a1e4 to
2a470fd
Compare
francisduvivier
force-pushed
the
feature/26-upload-api-part-3
branch
from
79342cb to
abd80bd
Compare
| * Create a new user | ||
| */ | ||
| @Post("/users/{userId}") | ||
| public async insertUser( |
There was a problem hiding this comment.
We should:
- Get some validation middleware on all of these so we can return proper status codes instead of waiting for the DB insert to fail and sending back what I assume to be a
500and a raw DB error - Create a different implementation of the data port interface that doesn"t talk directly to the database. Going straight from post data to a SQL insert is iffy imo.
There was a problem hiding this comment.
-
I agree about the raw DB erros being sent back from the API should change. Maybe we can indeed use some TSOA middleware for that. Could you create a ticket for this?
-
Extra manual validation is not really that necessary I think because TSOA is already checking the input shape of the requests so that they match the typescript types.
-
Now I was also wondering whether I should make an extra layer for the DB, but it felt a bit overengineering for now. Idea currently is that the BadgeHubDataPostgresAdapter translates between Badgehub Domain and DB, the Badgehub domain is used by the API. The abstraction is a bit broken because in some places it made sense to reuse the DB insert typings. But if we want extra validation and shielding, I think we can do that in the BadgeHubDataPostgresAdapter.ts or private-rest.ts.
There was a problem hiding this comment.
| @@ -19,7 +22,7 @@ create table badges | |||
|
|
|||
| create table users | |||
| ( | |||
| id text primary key, -- using text as recommended | |||
| id serial primary key, | |||
There was a problem hiding this comment.
I think at some point we may want to switch to UUIDs instead of sequential, since we"re dealing with a write API and a bunch of hackers.
There was a problem hiding this comment.
yeah uuids instead of these increasing numbers would make sense.
Shall we make a ticket for using uuidv6?
But for the users I actually would prefer to use unique readable user ids that users have to choose. Nicer to read API"s that way. So I changed it in #35 to strings, but then I saw it cause extra migration work, so I just changed it back here the scope of these PR while keeping everthing that currently works working.
There was a problem hiding this comment.
Update: I created #44 for this
francisduvivier
force-pushed
the
feature/26-upload-api-part-2
branch
from
2a470fd to
c290e27
Compare
francisduvivier
force-pushed
the
feature/26-upload-api-part-3
branch
from
abd80bd to
ef76ebc
Compare
francisduvivier
force-pushed
the
feature/26-upload-api-part-3
branch
from
c04df81 to
dadfd31
Compare
francisduvivier
force-pushed
the
feature/26-upload-api-part-2
branch
from
7f679a1 to
15fdef0
Compare
Co-authored-by: zera1ul <[email protected]>
Since we wer currently just inserting the unsalted password into the DB.
francisduvivier
force-pushed
the
feature/26-upload-api-part-3
branch
from
dadfd31 to
a57a210
Compare
This PR implements the first working upload api parts: