1. Some sort of backend DB integration. It's very hard to figure out how people are interacting with NodeJS databases other than MongoDB these days, frontend alone isn't the issue. Sequelize + postgres for example would be great to get an app up and running I expect, including things like connection pooling. (Bookshelf seems okay too, but I don't like it purely because it seems to automatically infer attributes from the database, which makes coding harder as you'll need to hit the REPL or schema to know what's coming out). In addition, webpack is easy to get running. Making it sane from a module size perspective (dead code elimination...etc) is harder.
2. Test coverage. Unit + integration. There's a million test runners, mock frameworks, etc etc out there. It's not trivial to get something you know is sane working (more so from integration side). Not to mention new-style imports entirely break most frameworks like rewire in my experience, so I wouldn't encourage their usage.
And, well, for me I KNOW those answers for python (I haven't done that much nodejs backend work since ~2013. I've used the node ecosystem exclusively for frontend since, a lot), so it's a lot more simple for me to get started.
The model I was shooting for was having your API be an independent HTTP rest service (whatever framework/language you want) with the nodejs server consuming it to render the initial view and then the client also consuming it in order to carry on with execution.
Martyjs (and the marry-express module) makes this very easy to do in that you can write your application without having to consider the context in which it is running (server or client).
I think the backend DB integration is a separate concern from how to build isomorphic js apps.
In terms of test coverage I don't have much experience testing js apps so I can't speak to the pain points there.
Yeah, I think that's a reasonable model where it will make sense since the client/backend can actually be more or less identical, since they'd both just be consuming REST.
But that's a pretty painful way to start a project as well. /shrug
1. Some sort of backend DB integration. It's very hard to figure out how people are interacting with NodeJS databases other than MongoDB these days, frontend alone isn't the issue. Sequelize + postgres for example would be great to get an app up and running I expect, including things like connection pooling. (Bookshelf seems okay too, but I don't like it purely because it seems to automatically infer attributes from the database, which makes coding harder as you'll need to hit the REPL or schema to know what's coming out). In addition, webpack is easy to get running. Making it sane from a module size perspective (dead code elimination...etc) is harder.
2. Test coverage. Unit + integration. There's a million test runners, mock frameworks, etc etc out there. It's not trivial to get something you know is sane working (more so from integration side). Not to mention new-style imports entirely break most frameworks like rewire in my experience, so I wouldn't encourage their usage.
And, well, for me I KNOW those answers for python (I haven't done that much nodejs backend work since ~2013. I've used the node ecosystem exclusively for frontend since, a lot), so it's a lot more simple for me to get started.