Skip to content

Instantly share code, notes, and snippets.

@banderson

banderson/remote-ui.md

Last active March 3, 2023 15:41
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save banderson/c1bfb0a453f6952a6d043bfebbd17bb6 to your computer and use it in GitHub Desktop.
Save banderson/c1bfb0a453f6952a6d043bfebbd17bb6 to your computer and use it in GitHub Desktop.
Download ZIP
Remote UI discussion
Raw
remote-ui.md

Remote UI @ HubSpot

  • What we're building
  • Where remote-ui comes in
  • Our proposed architecture
  • Open questions







UI Extensions @ HubSpot (now and vNext):

tl;dr:

  • very similar to ui extensions on your (and other) platforms – let developers add features to the UI
  • it's been around for a few years, but still very early in opening it up for public use
  • ensuring extensions match the UX of our app was an important design goal (sound familiar? :)

How UI Extensions work right now:

Screenshot 2023-03-03 at 9 38 01 AM







Where remote-ui comes in

Right now, our system is backend-driven. Developers return a JSON payload from a serverless function (or hosted server), and we convert that JSON into React components. This is similar to Slack's extension model, if you're familiar with that.

We evaluated remote-ui at the very beginning, but we weren't sure if it would work for us. We've tried sticking with the server-driven JSON approach, but it's just too painful and will take too long to make the DX good enough.

So, we went back re-evaluate remote-ui and are committed to making it work this time. We've been testing everything out, and are quite happy with the early results:

Screenshot 2023-03-03 at 9 40 11 AM

Kapture 2023-02-08 at 12 17 53







Our WIP architecture

We began with the comprehensive example and have been working backward to fit the pieces into our existing architecture.

image

Key points:
  • There can be many extensions rendered on the same screen, in different places
  • On load, we receive a JSON payload with a list of extensions to show on the screen with metadata (cdn URL, version they built it with, what data they want passed into the remote component)
  • We replaced the webpack plugin helpers for just-in-time sandboxed iframes, with a "remote-environment" deployable app so we can:
    1. manage the remote-environment library version(s) independently from the Host
    2. have different remote configs for different audiences (one for internal teams that's more permissive)
    3. experiment with supporting different authoring frameworks (vue externally, react internall)
  • To do that ☝, we've reverse-engineered the MessageChannel ports swap to connect the Host to the Remote that's hosted inside the sandboxed iframe







Open Questions & Next steps

  • Any concerns with our usage so far? Particularly around versioning or performance?
  • Anything we should be aware of when building dev-tooling? Example: triggering live-reloads for local dev (w/vite) and proper setup/teardown to avoid leaking memory / "ghost" UI issues?
    • example: See cargo-culted MessageChannel port swap mentioned above
Next Steps for us:
  • Performance stress test
  • Making internal product features available inside the extension via sdk/library
  • Cross-browser testing (and evaluating polyfilll compatibility with our stack)
  • Working toward releasing Beta over the next few months
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment