-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
feat: self hosted flex POC #1697
base: master
Are you sure you want to change the base?
Conversation
Nice work Bo! I assume the service worker element is complementary to the move to self host but we could go without it for an MVP? I'm guessing we would still gain significant load time / bandwidth benefits from gzipping the code and distributing it via a CDN, even if we didn't use service workers. I assume that now we have a host app, we could move some of the less Twilio adjacent stuff like resource search and 'standalone' case / contact management out of the plugin, giving us the option to run them truly standalone. Obvs not a priority until we have a real need to do that, but nice to know the option would be there |
Apparently yes. I was assuming flex needed a service worker for notifications of some sort since it was part of the example repo, but apparently not. Flex hosted doesn't run a service worker. I disabled it for now.
Yup. The POC is behind cloudfront. Twilio hosted total transfer: 15.5mb
That should be possible, though it may not be very easy. We'd need to figure out how to either take over the twilio controlled react-router-dom before it is initialized by flex-ui, or replace it with our own. Alternatively we'd need a way to detect a service outage before flex manager has loaded and display an alternative version of the app. Both approaches seem messy, but doable. We could also need to reverse engineer the twilio/okta auth system to figure out how a twilio outage would impact authentication... then potentially bypass that with our own authentication mechanism. |
Another part of the dynamic appConfig loading pattern that may not be immediately obvious is this: We could stop thinking about our flex-plugin deployment process as long complicated per helpline build/deploy action. Since the appConfig is dynamically loaded and the pluginService just points at a json file (or an api endpoint) we can deploy a single git sha named plugin bundles to a single s3 bucket for each environment. Then just swap out the version that the pluginService json returns for each individual helpline. This could totally change the way our deployment flow works and allow "fast swapping". That is a huge benefit. |
Technically, if we have control over the plugin service value in "twilio hosted flex" we could accomplish a lot of the short term benefits of this pattern (and a lot of the download size improvements) by pointing that to json that we control and just self-hosting the plugins. |
I'm afraid to test it because I don't want to break development right now when I have other things to work on, but the service config has two values that I can't find official documentation around:
I would suggest we try setting those to:
And then load the flex hosted flex app and checking to see if it is used correctly and if the hrm plugin is loaded from the assets bucket. |
Gian and I tested setting the service config values and flex didn't pay any attention to them. There may be another way to set up a remote plugin service in twilio hosted flex, but I haven't been able to find it documented anywhere. |
I put in a ticket with twilio support and they got back to me. Self hosted plugins without self hosted flex is possible and is probably a good first step. https://www.twilio.com/docs/flex/developer/plugins/cli/common-uses#deploy-to-your-own-cdn |
Description
This is a very rough (not even in TS yet) skunkworks POC of self hosted flex.
See the readme and comments in the index file for key learnings.
There is a sibling PR that sets up the related s3 bucket here: techmatters/infrastructure-config#284