Ask HN: Is this a good table schema for handling third party integrations?

by babbledabbleron 7/8/2023, 10:06 PMwith 4 comments

Hello!

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

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.

Here's the situation:

Most of these integrations will use oauth2 though not necessarily. I don't know how many there will be eventually.

I would like to store all these integrations in a single table to simplify maintenance and build out.

Inevitably, there is going to be some custom data. For this I plan on using a JSONB field called custom_properties.

My table schema would look something like this:

access_token

refresh_token

scopes

expiry_time

api_key

...other auth standard props

client_id

client_secret

custom_properties (JSONB)

type

As you can see in some cases client_id and client_secret will be populated. In others access_token, refresh_token for oauth.

My goals are: - Simplify maintenance and build out - Semantic field names that are self documenting - Avoid gnarly data parsing

Does this seem like a sound approach? Are there any alternatives approaches to consider?

by ecesenaon 7/9/2023, 4:29 AM

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).

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.

You’ll never need a (painful) schema change.

Hope this helps, good luck!