Skip to content
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

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from
Draft

Conversation

robert-bo-davis
Copy link
Collaborator

@robert-bo-davis robert-bo-davis commented Sep 30, 2023

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

@stephenhand
Copy link
Collaborator

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

@robert-bo-davis
Copy link
Collaborator Author

robert-bo-davis commented Oct 2, 2023

I assume the service worker element is complementary to the move to self host but we could go without it for an MVP?

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.

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.

Yup. The POC is behind cloudfront.

Twilio hosted total transfer: 15.5mb
Self hosted total transfer: 5.5mb

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

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.

@robert-bo-davis
Copy link
Collaborator Author

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.

@robert-bo-davis
Copy link
Collaborator Author

the pluginService just points at a json file (or an api endpoint)

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.

@robert-bo-davis
Copy link
Collaborator Author

Technically, if we have control over the plugin service value in "twilio hosted flex"

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:

    "plugin_service_attributes": null,
    "plugin_service_enabled": null,

I would suggest we try setting those to:

    "plugin_service_attributes": {
        "url": "https://as.development.flex.tl.techmatters.org/assets/configs/as_plugins.json"
    },
    "plugin_service_enabled": true,

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.

@robert-bo-davis
Copy link
Collaborator Author

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.

@robert-bo-davis
Copy link
Collaborator Author

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants