Nact in browser about nact HOT 15 CLOSED

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.

from nact.

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

from nact.

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!

from nact.

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

from nact.

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.

from nact.

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/

from nact.

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.

from nact.

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.

from nact.

@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

from nact.

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

from nact.

from nact.

@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.

from nact.

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.

from nact.

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

from nact.

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.

from nact.