You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Modules like Email, SMS and Storage depend either optionally or entirely on third party service providers.
Accessing and making use of said providers might not always be possible due to configured credentials being invalid, their service going down or even the backend user's account running low on credit.
Instead of just assuming a third-party dependent module is online as long as its configuration specifies active: true and it hasn't yet crashed, we should ideally be performing some checks to verify our connection is not only available, but also functional (that is to say, not connected, but unable to send emails due to a low credit block for instance).
These checks would also prove useful in notifying modules making use of a service-dependent module as to the latter's actual state.
For instance, Authentication's local authentication strategy makes optional use of Email for registration verification etc.
It's no good knowing that Email is online and "active" when in reality it could possibly be incapable of sending any emails.
This could also let us temporarily disable certain routes (route re-registration) on an inactive Email onConfig event and whatnot.
The text was updated successfully, but these errors were encountered:
kkopanidis
changed the title
[FEAT] Implevent service provider checks in module initialization
[FEAT] Implement service provider checks in module initialisation
Apr 10, 2022
Wtih gRPC health checking protocol being implemented we may now specify a NOT_SERVING (or maybe UNKNOWN) health state for modules with improper configuration.
This would result in these modules not registering as available in Config and thus not showing up as available at all.
Modules like Email, SMS and Storage depend either optionally or entirely on third party service providers.
Accessing and making use of said providers might not always be possible due to configured credentials being invalid, their service going down or even the backend user's account running low on credit.
Instead of just assuming a third-party dependent module is online as long as its configuration specifies
active: true
and it hasn't yet crashed, we should ideally be performing some checks to verify our connection is not only available, but also functional (that is to say, not connected, but unable to send emails due to a low credit block for instance).These checks would also prove useful in notifying modules making use of a service-dependent module as to the latter's actual state.
For instance, Authentication's local authentication strategy makes optional use of Email for registration verification etc.
It's no good knowing that Email is online and "active" when in reality it could possibly be incapable of sending any emails.
This could also let us temporarily disable certain routes (route re-registration) on an
inactive
EmailonConfig
event and whatnot.The text was updated successfully, but these errors were encountered: