A set of best practices for JavaScript projects

Re:A set of best practices for JavaScript projects by andreasklinger on Wednesday July 05, 2017 @07:02AM (#14701400)

you want to slice your abstractions by domain logic boundaries

essentially by "what it does, not by how it does it"

eg let's say you want to do notifications for your site.

you want to have everything related to notifications within one folder and have the outside connect to it via one api (eg component)

in backends this would enable you to easily scale in performance (eg move to microservice or separately hosted instance) or team size (isolation in code, less awareness of the overall codebase "needed")

imo the next big web framework after rails will have this setup as a default

    `app/services` instead of 
    `app/controllers, app/models, app/decorators, app/workers, app/assets, app/views, etc`

[ Parent | on HN ]

Re:A set of best practices for JavaScript projects by whatnotests on Wednesday July 05, 2017 @03:17PM (#14705323)

Interesting point.

    app/services/signup
    app/services/signin
    app/services/newsletter_subscribe
    app/services/create_report
    ...etc

In larger Rails projects I've been on, we often start with a monolith but then break it into different services to scale out.

Starting with different services at the beginning may cause some other problems: what if the boundaries between services was wrong?

[ Parent | on HN ]

Re:A set of best practices for JavaScript projects by andreasklinger on Wednesday July 05, 2017 @03:41PM (#14705530)

if the abstraction was wrong you have the same issues. no matter if you colocate files or not. most likely it is just less of a mess

[ Parent | on HN ]