-1

I want to build an API, using Google auth (via the loopback-component-passport) and ACL for access control. I also need to extend the standard User model, as I have some additional data fields.

By default the User, AccessToken, ACL, RoleMapping and Role models use the in-memory storage, i.e. data will be lost once the app restarts. So, my questions are:

  1. To persist data to MySQL, I would need to automigrate these models from in-memory to MySQL data source. But, if I'm going to extend the User model as StaffUser, do I need to have tables for both User and StaffUser in the DB? Or, do I then keep User in-memory and StaffUser in MySQL?

  2. The passport component adds its own models (UserIdentity, UserCredential, ApplicationCredential,PassportConfigurator). Would there be any reason to persist these in MySQL, or do I keep these in-memory?

go4cas
  • 1,171
  • 5
  • 14
  • 27

1 Answers1

0

To persist data to MySQL, I would need to automigrate these models from in-memory to MySQL data source. But, if I'm going to extend the User model as StaffUser, do I need to have tables for both User and StaffUser in the DB? Or, do I then keep User in-memory and StaffUser in MySQL?

I don't think you would need to auto-migrate these models from in-memory to your data source. Instead, you should just change the dataSource property of the model in your app's model-config.json from the default in-memory to the data source defined by you. If your app uses only StaffUser and doesn't need User, you may not need to put User in MySQL.

The passport component adds its own models (UserIdentity, UserCredential, ApplicationCredential,PassportConfigurator). Would there be any reason to persist these in MySQL, or do I keep these in-memory?

The section "Connectors" in this Strongloop article says that the in-memory data source is suitable only for development and debugging purposes. We shouldn't let the login related information lie in-memory and let them get wiped out in an app restart.

Arun N. Kutty
  • 306
  • 1
  • 7