Hi Would really appreciate some prompt guidance in this regard.

Hey Prashant, thanks for the reply. So keeping it hadn't worked either for me earlier too. Also, I had tried renaming the app.css to app.scss after commenting the test for \/.css$\, below is the error shared/components/ListItem/ListItem.scss: Unexpected token ( 1 : 19 ) > 1 | tn-container { | ^ 2 | border-radius: 5 px; can't tell whats messed up. I must be doing something silly somewhere. Would appreciate help resolving this since thats the missing piece and we are using mern for our production stack.

Hey Prashant, was trying to do this as per the link you shared as well. May be I am missing something. module : { loaders: [ /*{ test: /\.css$/, loader: 'style!css?modules', },*/ { test: /\.scss$/ , loader: ExtractTextPlugin.extract( 'style!css!sass' ) }, { test: /\.jsx*$/ , exclude: [ /node_modules/ , /.+\.config.js/ ], loader: 'babel' , query: { presets: [ 'react-hmre' ], }, }, ], }, /*sassLoader: { includePaths: [path.resolve(__dirname, "./client/index.js")] },*/ plugins: [ new webpack.HotModuleReplacementPlugin(), new webpack.DefinePlugin({ 'process.env' : { CLIENT: JSON .stringify( true ) } }), new ExtractTextPlugin( 'app.css' , { allChunks: true }) ], I get an error saying unexpected token, in the .scss file that I import in my container. So I have a parent level app.css file, as in the original kit. I want to keep that but for the individual components/containers, I would like to have their own scss files. Can you guide how to do that?

thanks Mayank. So then the mapStateToProps only binds the store to the state for the first render or I guess not even? Also, why not try to set the state after getting it from the value on the store in this case?

ok cool.. thanks Rick! That's what I am hoping that at some point we'll be able to build up starting from MERN to that kit.. although our deadlines are slipping by.. as is always the case.. wish there was a tutorial "From MERN to react-redux-universal-hot-example" in 10 easy lessons !

Hi Rick, we managed to do what you are saying. Like you said, MERN is defined perfectly like a starter kit should be and simple enough to separate out the api server. I put up a couple of sample repos which have the code separated out https://github.com/sudhamab/mern-without-api-server and https://github.com/sudhamab/mern-api-server . These can be run in conjunction and it took very little effort to do this. I think the kit is great in that it lets you keep things simple if you want to or then modify it. As for the other Universal Hot example you were mentioning, thats really good too and we like it a lot, but it packs in a lot of stuff so initially we got a bit overwhelmed because the reasoning behind how certain things were done were not obvious to us. I think at some point we'll have to learn from both these and create our own version of it. Thanks for mentioning it though. PS: The credit for the underlying code for the 2 sample repos above has been given to the Hashnode team. I just wanted to share it as an example for reference in case it helps others like us.

We went through a lot of thinking and research with regards to this as well. It boils down to a few things Learning curve :- Erlang, along with the XMPP protocol are well designed for messaging, but have some learning curve. Where as for Socket.io, the learning curve is next to nothing and you can implement something quickly Scale :- I think it depends on where you are in your journey. Node & Socket.io work pretty well. So if you want to get up and running quickly, I think they are a good choice. Our understanding is that it can support you for quite a while. Once you hit massive scale, then you can perhaps rethink these. Availability of resources :- Granted whatsapp was built only by a few engineers, but they had to customize a lot of things, and again, they solved for those things at scale. It required engineers who know erlang and if you can't scale your product development, how will you scale your product? I don't know for sure but perhaps there weren't too many alternatives then. Here's one other technology we've been keeping an eye on but haven't really seen too many people talk about it for chat applications - MQTT. It's used for IOT, has a light weight header which is what makes it appealing, and can do pub/sub. There are examples out there of using it with Node as well and it offers clients for IOS and Android. You'll need a broker for it as well. We chose node and socket to get things going and later on we may look at erlang or mqtt or whatever else is new. If you get going with mqtt please let us know too. We'd be interested :) Lastly, we haven't looked at some of the other technologies mentioned in this thread but the 3 I have mentioned were the ones we looked most closely at, because they seemed to orient well towards messaging.

thanks so much Zach! Tried the cors package. Works beautifully. the link was really helpful. .. so now by just moving out the api handling from the server code to another code base, I've been able to make it work.. I'm a happy man! this stack is cool

hey Zach, I was not planning to use the same server domain, so basically one server ( on a different host perhaps ) would only be responsible for rendering and serving the components, and the other would be responsible for serving api calls - addPost, deletePost , etc. This would allow the api server to not worry about the rendering n stuff. We think later on this model could scale better. Any thoughts? But ya, I am running into Cross-origin issues and somehow simply setting 'Access-Control-Allow-Origin': '*' did not fully help.. so trying to debug it

thanks Prashant! We'll give it a shot with react-bootstrap and keep an eye out for SCSS support in the future.