[matchu]

Interesting! I really like the architecture here. I think the next major opportunity for abstraction is all the server/client detection you still have to do. Do I want `request.headers['Cookie']` (server), or `document.cookie` (client)? Do I want to create a fresh Redux store (server), or hook into a global one (client)?

It's definitely not hard for community members to build these abstractions themselves (`cookies = (req) => req ? req.headers['Cookie'] : document.cookie`), but some of these are going to play into major use cases like authentication, so, as Next matures, it'll start to make sense to provide these especially common abstractions out of the box.

That said, these are next steps; the first release is all about showcasing the fundamental architecture, and it's looking gooood :D

[girvo]

That is something that react-server[0] is doing reasonably well, though some of the abstractions I would like OOTB are missing currently

[0] http://react-server.io/

[proyb2]

and Electrode.io is exactly you need OOTB.

[firasd]

Maybe I'm misunderstanding but I don't think universal apps will share so much code with the client. It's just the view layer that is shared (React components in this case). You wouldn't make changes on the server side by piping them through Redux, you'd just use your regular code paths to read the JSON data from the client and send an update query to the database.

[chncdcksn]

You may be interested in Opa (http://opalang.org). I'm unsure how well it abstracts away client/server detection, but from what I understand about it, you have one codebase for both your client and server. I've never used it however, so I can't vouch for it entirely, but it certainly looks interesting.

[sillysaurus3]

If someone wants to solve this problem and wants inspiration, look into how Unreal Engine's scripting/networking architecture works. Gamedev and webdev can be very similar at times.

[greyskull]

Interesting! Might you be able to elaborate?