tgiardina / typescript-typeorm-realworld-example-app Goto Github PK

This requires three things:

1. Refactor POST /users to additionally return a JWT token.
2. Create an authentication middleware that parses a JWT token and adds the resulting user model to req.locals.user.
3. Create an endpoint that requires authentication (maybe GET /users).

This article is a good starting point. This answer should help override Express's request type to allow the canonical locals key.

We need to add JWT authorization. Let's start with POST users. A pull request should:

1. Install a token generator (maybe jsonwebtoken?).
2. Add IUserDto next to UserModel and IUserModel. It should insist on a token key.
3. Add a toDto method to UserModel that returns a IUserDto.
4. Refactor services/user.create to return a IUserDto.

This was mentioned as an aside in #26. Currently DTOs are located with models (which should probably be called entitites). Does this make sense?

This is a sub-issue of #14. It is the subject of PR #26, but I'm codifying it here. The rest of this post is copied from #26 for convenience:

Currently, (pretty much) every class has a colocated interface. This was an attempt to code to an interface, which is good if executed correctly. But I don't think it is executed correctly right now. In particular, colocating interfaces makes for both unnecessary and leaky abstractions. Move interfaces where they're used, not where they're implemented.

• E.g., let's put a IUserService next to a UserService class. This is redundant, because UserService already documents its interface via its implementation. Meanwhile, UserController, which requires a user service interface, does not document it, relying instead on servicess IUserService interface. So services has redundant abstraction and controllers is leaking.
• But you need to code to an interface! Yes, and we still are. We've just moved the interface away from its implementation and to its client.
• But this is coupling! Now UserService is based on an interface in UserControllers. True! But it always was! We implemented UserService to meet the requirements of UserControllers regardless of where we placed IUserService. The coupling was always there, it's just more explicit now.
• But colocating UserServicess makes unit testing easier! Maybe if we were coding in Java 20 years ago. Sinon handles our stubbing needs just fine.

According to the official specs, newbies should be able to parse our architecture in 10 minutes. There are two levers we can pull here:

1. Simplify our architecture,
2. Improve our documentation.

I don't think we can completely solve this problem using Lever 2 alone, but ideally we can solve it without losing our core stack to Lever 1.

I think this will play our one of two ways:

1. This project generates enough feedback that we're able to develop really tight code around our core stack, write very to-the-point documentation, and avoid an uneven learning curve.
2. This project is too complex to garner significant interest and we have to develop a simpler intermediary project, which can point to this project if users are interested in taking the next step of engineering complexity.

A template should be (among other things) a learning tool. Why MVC? Why IoC? At the very least, we should link to articles that explain the when and how of these larger concepts.

We don't currently validate req.body, leaving it to the database to reject invalid data. This is bad practice. In particular, this means that the user service may be passed parameters that don't adhere to the appropriate interface, causing coupling and the need for weird tests (see create.invalid.test.ts). Security is probably also an issue.

Instead, we need middleware (either via a package or coded ourselves) that handles validation before req.body reaches the controller.

We need a tsconfig file to add configurations and to fix experimental decorator issues

This issue shows InversifyJS is dying/dead. This demo won't be very useful if it does indeed die.

In particular, it should have separate tests for running a method and testing the result. E.g.,

it('should return a correct result', async () => {
  const result = await userService.create(data);
  assert(result.isOk);
  assert.equal(result.value.username, data.username);
  assert.equal(result.value.token, data.token);
})

Should be split into

it('should run successfully', ...)
it('should have correct username', ...)
it('should have correct token', ...)

Currently, our user table only has the necessary id and username columns. The Real World specs also require an email, bio, image, and password columns.

A possible roadmap would be:

1. Update the create-user migration to include these columns (note: this will be a breaking change for people who already have a database set up locally).
2. Update models/user to include the new columns (both class and interfaces).
3. Update the POST /users endpoint to require the additional fields.

If interested, open a pull request with updated create-user tests that fail with the current setup.

These are the same thing by different names.

Let's implement the GET user endpoint as specified here. A pull request should:

1. Add a refreshToken method to services/user that returns a IUserDto.
2. Add middleware at src/controllers/middleware/authenticate that calls refereshToken from 1.
3. Add a get method to controllers/user.

Note: This is blocked by #10 because step 1 will use the UserModel.toDto() method that #10 will implement.