3 ms·

Depends on the project, but most likely just Node + express + TypeScript on the backend (so no "framework" in the traditional sense). On the frontend, React +

Depends on the project, but most likely just Node + express + TypeScript on the backend (so no "framework" in the traditional sense). On the frontend, React + MobX + TypeScript. This of course means it would be a single-page application. Benefit of using TypeScript on both client and server is that you get to automatically share the schema of the data they're exchanging (and maybe some more code as well, like validation). For free. And when you change the structure of something - and you will - you get immediately alerted to any issues on both sides (e.g. this property is now required, and you omitted it in this function!). This is huge because maintenance is often more difficult than writing the initial version - and I don't even mean the initial released version. Also you get to potentially reuse some of the code in the future for a React Native based mobile app. I'm also eyeing GraphQL and Apollo a bit, but I don't have enough experience with them to use them in a "real" project just yet.

mercer 9y ago
I would do pretty much exactly what OP suggests. I might just go for React+Redux instead of MobX, but that's not too important. What I'd like to hear is arguments as to why I might want to consider other options. Why Elixir, compared to the above solution? Why Phoenix, or for that matter Django? Or for the front-end-ish side: why MobX instead of what seems to be a more industry-standard Redux? Why Node.js and Express instead of the alternatives (Django, Rails, but also Hapi and Sails)?
GeneralMaximus 9y ago
> Benefit of using TypeScript on both client and server is that you get to automatically share the schema of the data they're exchanging (and maybe some more code as well, like validation). For free. How do you do this? Do you have a separate NPM package that just contains your schema/validation code? Or do you keep your backend and frontend code in the same repository?
- realharo 9y ago
  Same repository, 3 different directories (client, server, shared). This also makes it easy to have shared docs, dockerfiles, and other things needed for the complete setup on any machine. But you can also just do this with a git submodule for example, or any other method that will physically get you the shared files there.
  - GeneralMaximus 9y ago
    Thanks for answering. I've always wanted to try breaking projects down into separate NPM packages, but I usually end up using git submodules. Path of least resistance and all.
    - realharo 9y ago
      Not sure what you mean by NPM packages, but I don't publish anything to NPM (not even a local repository). On the other hand, the client and the server obviously each have their own package.json, with their own dependencies, etc.
      - GeneralMaximus 9y ago
        > Not sure what you mean by NPM packages, but I don't publish anything to NPM (not even a local repository). Break your applications into separate Node modules and publish them to a private NPM. Now that I type it out, it sounds like more trouble than it's worth.

mercer 9y ago

I would do pretty much exactly what OP suggests. I might just go for React+Redux instead of MobX, but that's not too important. What I'd like to hear is arguments as to why I might want to consider other options. Why Elixir, compared to the above solution? Why Phoenix, or for that matter Django? Or for the front-end-ish side: why MobX instead of what seems to be a more industry-standard Redux? Why Node.js and Express instead of the alternatives (Django, Rails, but also Hapi and Sails)?

GeneralMaximus 9y ago

> Benefit of using TypeScript on both client and server is that you get to automatically share the schema of the data they're exchanging (and maybe some more code as well, like validation). For free. How do you do this? Do you have a separate NPM package that just contains your schema/validation code? Or do you keep your backend and frontend code in the same repository?

realharo 9y ago
Same repository, 3 different directories (client, server, shared). This also makes it easy to have shared docs, dockerfiles, and other things needed for the complete setup on any machine. But you can also just do this with a git submodule for example, or any other method that will physically get you the shared files there.
- GeneralMaximus 9y ago
  Thanks for answering. I've always wanted to try breaking projects down into separate NPM packages, but I usually end up using git submodules. Path of least resistance and all.
  - realharo 9y ago
    Not sure what you mean by NPM packages, but I don't publish anything to NPM (not even a local repository). On the other hand, the client and the server obviously each have their own package.json, with their own dependencies, etc.
    - GeneralMaximus 9y ago
      > Not sure what you mean by NPM packages, but I don't publish anything to NPM (not even a local repository). Break your applications into separate Node modules and publish them to a private NPM. Now that I type it out, it sounds like more trouble than it's worth.