Hello!<p>I have to build out support for various integrations to third party services like calendars, task management systems, email etc. I'm just looking for some feedback open the approach I'm considering<p>I'm a bootstrapping founding engineer so would greatly appreciate your feedback. This is for a startup small scale app that could of course grow.<p>Here's the situation:<p>Most of these integrations will use oauth2 though not necessarily. I don't know how many there will be eventually.<p>I would like to store all these integrations in a single table to simplify maintenance and build out.<p>Inevitably, there is going to be some custom data. For this I plan on using a JSONB field called custom_properties.<p>My table schema would look something like this:<p>access_token<p>refresh_token<p>scopes<p>expiry_time<p>api_key<p>...other auth standard props<p>client_id<p>client_secret<p>custom_properties (JSONB)<p>type<p>As you can see in some cases client_id and client_secret will be populated. In others access_token, refresh_token for oauth.<p>My goals are:
- Simplify maintenance and build out
- Semantic field names that are self documenting
- Avoid gnarly data parsing<p>Does this seem like a sound approach? Are there any alternatives approaches to consider?
My recommendation is to use a json blob for everything but type (that I would rename) and a unique user identifier (that I don’t see in your schema).<p>You will never have to query by any of these fields, and the schema is not well defined as you said. Therefore you can load all user properties by user id (or combo type + identifier), parse json blob, access any field you need.<p>You’ll never need a (painful) schema change.<p>Hope this helps, good luck!