Access to context outside of marble.js streams

[jan-kacina]

Hi guys,
I have the following use case to implement (simplified):

1. User initiates login by clicking a button on front-end
   1. back-end is called by HTTP POST /auth/login-init
   2. userActionLoginInit$ stream emits
2. User put a card on card reader hardware
   1. serial port passes data
   2. cardRead$ stream emits
3. if both stream emit (and other validation is passed), user is logged in
   1. implemented as separate userLogin$ stream not related to any of marble.js components (it's pure RxJs)
4. information about user login has to be send via websocket back to front-end
   1. subscription to userLogin$, should send websocket message...

I've eagerly bound dependency injection of WebSocketServerConnection into createServer's dependencies (as described in Context doc). It's working well while I'm playing with it within HTTP effects - I can see number of connected clients as well as sendBroadcastResponse to them.

What I'm not able to do is to retrieve WebSocketServerConnection from the context within userLogin$ stream. I've tried to use createReader with useContext but with no success.

It looks to me like it's working well while ctx from useEffect is available, but I've not found any way how to retrieve it with createReader with useContext only.

Am I missing something? Is it even possible to access context without ctx provided by marble.js framework? Or should it be registered somehow on application level instead of http createServer (how?)?

Thanks in advance.

Regards,
Jan

[JozefFlakus]

@jan-kacina Hi!

Could you show me how userLogin$ is implemented? I'm afraid that till you don't treat it as Marble Effect and won't register it in a listener (either as HttpEffect or WsEffect) then you won't be able to inject anything there, without providing the ctx/ask as an argument to the function. But in order to help you solve this issue I would have to see it first in order to understand it better :)

Thanks!

[JozefFlakus]

edit:

OFC you can also register this stream as a dependency, then you will be able to inject/refer to any dependency that you have registered in the context.

Sorry, totally forgot about the obvious stuff. But let me see it first :)

[jan-kacina]

Hi @JozefFlakus ,
thanks for your quick reaction, I appreciate it.
I've prepared an essential minimum repository to reproduce the described problem.

Brief description:

• http server listens on http://localhost:1337/
• web socket server listens on http://localhost:1338/
• GET /login emits true in loginStatus$ stream
• GET /logout emits false in loginStatus$ stream
• GET /test serves as control effect to see the ctx works correctly (emits nothing)
• PropagateLoginStatus action subscribes to loginStatus$ stream, tries to get web socket server from context and should emit web socket message

Unfortunately, I was not able to get the web socket server from context even when I bound PropagateLoginStatus as dependency of http (neither web socket) server. You can see the bindings in http.server.ts

For complete information, I am using WebSocket.org echo test as a simple web socket client.

Do I use something in wrong way? Is there anything else I can do to retrieve dependencies stored in context outside of marble.js components?

Thanks and regards,
Jan

[jan-kacina]

Finally I found a solution/workaround by intercepting httpServer's context and creating ContextProvider on application level.

index.ts content:

import { lookup, ContextProvider } from '@marblejs/core'
import { IO } from 'fp-ts/lib/IO'
import { PropagateLoginStatus } from './actions/propagate-login-status'
import { httpServer } from './http-api/http.server'

let appContextProvider: ContextProvider

const main: IO<void> = async () => {
  const httpServerIo = await httpServer
  await httpServerIo()

  appContextProvider = lookup(httpServerIo.context)

  const propagateLoginStatus = new PropagateLoginStatus()
  propagateLoginStatus.run()
}

main()

export { appContextProvider }

Complete code is in the problem reproduction repository

What do you think about the solution/workaround?

Regards,
Jan

[JozefFlakus]

I think you should rebuild the concept of PropagateLoginStatus and think about it as a complete dependency with all relevant and connected actions inside. You should definitely have a deep dive into the concept of Dependency Injection - it is a powerful mechanism but sometimes hard to understand. I hope the following snippets will help you better understanding the way how it should be implemented :)

loginStatusPropagator.ts:

export type LoginStatusPropagator = ReturnType<typeof LoginStatusPropagator>;

export const LoginStatusPropagatorToken = createContextToken<LoginStatusPropagator>('LoginStatusPropagator');

export const LoginStatusPropagator = createReader(ask => {
  let subscription;

  const websocketServer = useContext(WebSocketServerToken)(ask);
  const statusSubject$ = new BehaviorSubject<boolean>(false);
  const status$ = statusSubject$.asObservable();

  const login = () =>  loginStatusSubject$.next(true);
  const logout = () => loginStatusSubject$.next(false);
  const teardown = () => subscription && subscription.unsubscribe();

  // BTW. there is no real need of having it implemented as a stream
  // generally there are plenty of possible ways how it can be implemented, eg. the stream can be modelled as a separate dependency
  // and other actions can have their own dependency as well  - then they have to inject the stream accordingly
  subscription = loginStatus$.subscribe(state =>
    websocketServer.clients.forEach(client => client.send(`${state}`)));

  return {
    login,
    logout,
    teardown,
    status$,
  };
});

Then you have to register it eagerly AFTER (thats very important in case of eager bindings!) injected websocket server.

export const httpServer = createServer({
  port: 1337,
  hostname: '127.0.0.1',
  listener: listener(),
  dependencies: [
    bindEagerlyTo(WebSocketServerToken)(async () => await (await wsServer)()),
    bindEagerlyTo(LoginStatusPropagatorToken)(LoginStatusPropagator),
  ],
});

I suppose you want to have this dependency resolved after initial bootstrap of the server. If not then you can use lazy binding.

Then in the login effect:

export const login$ = r.pipe(
  r.matchPath('/login'),
  r.matchType('GET'), // are you really sure that it should be a GET request? 🤔 
  r.useEffect((req$, ctx) => {
   // it's better to inject it here (think about returned stream as a React render function 😄)
   // https://docs.marblejs.com/other/style-guide#injection
   const loginStatusPropagator = useContext(LoginStatusPropagatorToken)(ctx.ask);

   return req$.pipe(
     tap(() => loginStatusPropagator.login()),
     mapTo({ status: HttpStatus.ACCEPTED }),
   );
  }));

[jan-kacina]

Hi @JozefFlakus ,
thanks for explanation. The missing piece in puzzle was how to work with DI container in Marble.js

I'll try the approach described herein before in my application, that's more complex than the reproduction repo.

Just for sake of clarity (you know, programmers have to have things unambiguous :) ), the following variables in your code...

  const statusSubject$ = new BehaviorSubject<boolean>(false);
  const status$ = statusSubject$.asObservable();

... should be named like this to match the rest of the code, right?

  const loginStatusSubject$ = new BehaviorSubject<boolean>(false);
  const loginStatus$ = statusSubject$.asObservable();

Thanks a lot,
Jan

[JozefFlakus]

Just for sake of clarity (you know, programmers have to have things unambiguous

Correct, but since the variable is inside of LoginStatusPropagator then it is redundant. Imagine that you have to rename your dependency naming (eg. because you would like to generalize it a bit), then all variables inside of it have to be renamed :)