用户注册和认证（注册和登录）Node.js

Question

I have two types of users , vendor and buyer. Should i create two different APIs to register and authenticate each type of user or a single API to handle both users? Also when creating my database model , should i create two different collections or should i create a single collection and create an extra field like role and populate it with the respective role of the user? Both vendor and buyer share almost all fields, except the vendor has an extra field that has the article they wana sell. Which approach is better? I'm using Express and MongoDB , I also intend to use Angular on the front end

Any help would be much appreciated , thank you.

Answer 1

There cannot be a strict answer for the above. You can keep them separate - separate APIs, collections - advantage would be separation of concern, which on long term MAY be helpful for future development where you may want to add something specific for either of the two parties without disturbing the other. At the same time if you keep them together - then it is just less code to maintain. It is more choice which you/your organization will need to take on the long term prospect of the application you are building. If I had to make a choice, I would keep them separate.

Answer 2

That's a good question for when you are mocking up your Collection Design. You have to start thinking about your users, and how different a vendor and a buyer is. Vendors and buyers are both users, but you could have a collection for items being sold by a user, and a boolean to differentiate who is a buyer and who is a seller. Ultimately these questions are what you want to decide prior to writing your API. If you want to set up two separate APIs for each user register, that is perfectly fine, but that is completely up to you.

Let's assume you decide to unify the login API into 1. You could define your user Models something like this. I like using Typescript to typecheck everything I user. I might be over doing it but I like it.

export interface User {
    id?: string; // add it as option in the case of regisration
    name: string;
    email: string;
    password?: string;
    // you can add more fields that both Vendor and Buyer would have in common.
}

export interface Vendor extends User {
    // here we define specific fields that a vendor would have that a buyer wouldn't
    selling: Array<Object>;
    isVendor: boolean; 
    revenue: number;
    // more fields here if needed
}

export interface Buyer extends User {
    // define fields that a buyer would have that a vendor wouldn't
    cart: Array<Object>; // cart items of what they are purchasing
    cartTotal: number;
    billing: string;
    // more fields here
}

In the code above, the interface for User defines a basic User, and the interfaces for Buyer and Vendor extend the User interface, each adding their own fields unique to those models.

For your Registration API, you can simply have a checkbox in the form asking if the user is a vendor. This will enable the boolean in the Vendor interface, telling your API (this you would handle internally at the API code) that the information that is being sent is for a Vendor. Then save the basic info in the Users collection, and vendor information in the Vendor collection, keeping a common key between the two to user for reference when searching for one another.

When having a Login API, you don't have to differentiate between the two at the authentication level because the basic information for a User contains the fields needed to authenticate, when rendering the view for each User Type, simply check if the boolean for isVendor exists and is true, then route the user to the correct endpoint.

This question is hard to answer simply because there are so many ways one can approach this problem. It is up to the developer to decide which way they prefer to organize everything and lay things out. Want to keep things simply and create an endpoint for every user type? Go for it. Want to consolidate all authentication for all user Types into one? That is perfectly fine too.