Local gateway + Hot Reload using WebSocket #16
Conversation
|
@elliotBraem I think this is done for now, I've tested it but I appreciate if you can test it again to see if anything breaks.
Some things that need to be addressed in future PR:
|
There was a problem hiding this comment.
The experience is awesome.
It does take a very long time to npm install for the gateway -- I'm over at least 3 minutes right now, maybe more.
May be a future improvement, but we should explore ways to cut this down. Maybe we can deploy bundles that it uses.
Have you taken any influence from near-social-local-viewer? I haven't used this project in a long time, I'll have to give it a shot and see if it boots up faster, there may be some take aways.
To maintain support for existing bos-workspace workflows that are setting flags and not using a local gateway, we may want default behavior to not start a gateway and enable it with a flag, or vice versa.
| import io from "socket.io-client"; | ||
| import { flags } from "../config/flags.js"; | ||
|
|
||
| function useRedirectMap() { |
There was a problem hiding this comment.
This is sick.
Can you explain more the decision of full local gateway vs near-bos-webcomponent? (it was related to websockets, right?)
There was a problem hiding this comment.
near-bos-webcomponent is really great for quickly launching a consumer gateway, but my vision is to have a gateway for developers, and to implement it we need to have direct access to the gateway code.
Some dev features I think will be useful on a local gateway but not needed in normal gateways:
- Hot reload
- SocialDB/API mocking
- Debuging Tools like this
No description provided.