Nact in browser - Githubissues

ncthbrt commented 6 years ago

It'd be an interesting development to get nact working in the browser. There is no fundamental reason right now why it wouldn't be possible. This would enable a few things:

It could take the place of redux.
Allow very clean client-server communication via websockets/http2/etc

utnas commented 6 years ago

Can you explain why this issue has been closed ? @ncthbrt

ncthbrt commented 6 years ago

Hi @nsewolo, I was using GitHub issues as a way to plan nact's roadmap. However I've been informed that using issues I'm this way (leaving something open for long periods of time) hurts npm rankings.

pyrossh commented 6 years ago

I was thinking if the event sourcing/queries/aggregates part of nact be implemented on top of redux then the server and client can share the same reducer code. And when the client comes up it could establish a websocket connection and lazily load events/queries records it required. And now if an event is generated at the server which pertains to what the ui/client has subscribed to then it should receive those events and pass them through the same reducer/event processor.

This framework seems to have done it well. But it doesn't have persistance and es. http://boardgame.io/

ncthbrt commented 6 years ago

Hi @pyros2097 I think that'd be awesome.

I'm not too familiar with publishing libraries which can target the browser. There is really only one API right now that is not available in all browsers, setImmediate. setImmediate can be quite easily polyfilled however. My main concern is whether a library which usesmodule.exports can work in a browser context. Perhaps babel can do this? Not sure.

pyrossh commented 6 years ago

Yes. Most node_modules, including some of the standard packages work using module bundlers like webpack, browserify. Webpack being the most widely used. What we would need to do is transpile the common code that could be shared between server and client so that when the module bundler requires it, it wouldn't need to transpile the code and then it would work seamlessly. This has already been done by this es,cqrs framework with persistence and live syncing albeit its not completely free to use. https://www.wolkenkit.io/ They also have a react integration. Hmm.. time to think and experiment a bit. My current way of integrating it with the ui was to use graphql as an api layer at the backend and apollo store for the frontend. But now thinking why use another layer like graphql/apollo where something like redux or an event sourcing engine for the frontend would be better and integrate very well with the backend.

ncthbrt commented 6 years ago

@pyros2097 I've done something similar with websockets, redux and actors before using akka.net. Worked like a charm. Architecture was more or less as follows:

Authentication layer which identified the user by userId when the websocket connection is first opened
This connection was added to a set of connections linked to the user (we modeled this as an actor)
The connection set could be sent events pertaining to the user which would be broadcast to all the connections in the set.
If a message was received from a client, it was broadcast to subscribers of the user connection set.
On the client side, events received from the websocket connection were piped directly into the redux store

ncthbrt commented 5 years ago

We could perhaps make the browser a target in the typescript port?

scott-wyatt commented 3 years ago

I'd like to chime in here. If this indeed being ported to TypeScript (💯 ), then browser support would be a really interesting effect and definitely eligible given the build targets. There's a high likelihood that some actors could even become isomorphic, which would give it an edge over node.js/redux apps. I'm also a huge fan of Actors acting as graph nodes for scenarios like GraphQL or even Gun.js between the client and servers. Is there a roadmap published somewhere for typescript? I might be able to help with that.

ncthbrt commented 3 years ago

Hi Scott.

If there is genuine interest we could definitely look at making this happen.

I personally haven't yet had a strong enough use case, but if there is evidence that there is valid use cases we can try flesh out an implementation plan

On Fri, 11 Dec 2020, 17:23 Scott B. Wyatt, notifications@github.com wrote:

I'd like to chime in here. If this indeed being ported to TypeScript (💯 ), then browser support would be a really interesting effect and definitely eligible given the build targets. There's a high likelihood that some actors could even become isomorphic, which would give it an edge over node.js/redux apps. I'm also a huge fan of Actors acting as graph nodes for scenarios like GraphQL or even Gun.js between the client and servers. Is there a roadmap published somewhere for typescript? I might be able to help with that.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ncthbrt/nact/issues/34#issuecomment-743256799, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCJEWJZN72SU6QWRLZNS43SUI2PPANCNFSM4EJ6D6XA .

scott-wyatt commented 3 years ago

@ncthbrt, it's definitely more of a nice to have then a need to have. On the other hand Typescript would have likely made onboarding a bit easier for me just from the intelisense alone (but we could just build a type definition). Then again, if "it ain't broke".

I'd much rather spend time getting some of the caveats working and then re-visit typescript.

ncthbrt commented 3 years ago

As mentioned in the chat on discord, there are typescript bindings available, just to be clear.

The bulk of getting this feature working is more to do with the module system that typescript, though of course tsc could definitely help.

attila-lin commented 3 years ago

I want to use it with deno while get error becasue of the node::crypto.

https://cdn.skypack.dev/error/node:crypto?from=nact:14:7

ncthbrt commented 3 years ago

Hi @attliaLin.

Bit of a longer project, but on the typescript branch of the project, removing dependencies on node and also converting the project to use ES modules. This should allow deno support, at least in theory.

attila-lin commented 3 years ago

Hi @attliaLin.

Bit of a longer project, but on the typescript branch of the project, removing dependencies on node and also converting the project to use ES modules. This should allow deno support, at least in theory.

Nice job!

ncthbrt commented 2 years ago

Version 0.3.0 of Nact Core is now confirmed to work in the browser.

nactio / nact

Nact in browser #34