portals
portals copied to clipboard
Add server abstraction
This new feature now adds an abstraction between a VM instance and a Portal
- A portal is now a link from a Room to a VM instance (the repo name for a VM is still
@cryb/portal) - A server is a running VM instance
Here's how the flow of things works now:
- A server connects to
@cryb/portalsover WebSocket and verifies itself using a signed JWT token with a common secret - Portals then created a DB entry in both Mongo and Redis for the server. This DB entry is destroyed when the server disconnects
- When a server connects over WS, a check is made to see if there is a Portal that needs to be assigned a server. If there is, the server is automatically assigned.
- When a portal is requested by
@cryb/api, a check is made to see if there is a server/VM available. If there is, it's automatically assigned.
This change comes with some major benefits:
- We won't have to worry about
--portalIdanymore as that's handled automatically. - Hopefully there won't be any repeat
NoPortalFounderrors
There's also an option to dynamically spawn VM instances to be added to the pool when Portals runs out of instances that are currently connected. This will use the Driver format.
Let me know what you think! There are several other pull requests in the following repositories which need to be merged at the same time as this PR:
@cryb/api@cryb/portal@cryb/aperture
Here's a to-do list of things to do before this can be merged:
- [x] Add support for dynamic VMs
- [x] Add separate model for deployed VMs on cloud services
- [ ] Add reset command support
I'll add to this if anything else pops into mind