How about an example project?

[Aditya94A]

I'd love to see a simple todo or a chat web app made with these best practices in mind 😄

[BrunoScheufler]

That would illustrate our points in a practical way, so that would be a good idea!

[goldbergyoni]

@AdityaAnand1 great idea, it's already on our milestones and work in progress.

What should be our example use case: char or complex multi-component app?

I suggest demonstrating a complex web app that has many services (chat might one of them), this would allow showing real-real-world scenario and not rather simple example. Practically I suggest to show e-commerce site with orders, customers, discounts, products, etc

[elouizbadr]

@i0natan I agree with, that would be very useful since a great amount of us "Node & JS developers" will work on medium to large web applications.

[Aditya94A]

I suggest to show e-commerce site with orders, customers, discounts, products, etc

@i0natan Yes! This would be amazing 😄

[goldbergyoni]

Should it be conservative (Express, Rest, Winston, manual context, etc) or innovative (GraphQL, Pino, CLS with async hooks, etc)?

[BrunoScheufler]

I think we may mix that up a bit. We could use some shiny new tech and also some proven software that is really used by many people and built to be solid for projects!

[TheForgotten69]

Like Hapijs ? There isn't much love for this framework unfortunately.

[BrunoScheufler]

Well not as much as for Express and other frameworks I guess but Hapi really is awesome, just depends on the team and the use case. I think we should collect some and then vote and select the most wanted frameworks and libraries if this works.

[sepehrvakili]

I think this is good idea too. Would be nice if the sample application included patterns for role-based authorization as well.

[goldbergyoni]

@TheForgotten69 Hapi is great (and Joi is amazing) but it just not too... different. I mean, for a conservative example I would show Express because this is what most people use and struggle with. For early adopters I would prefer to use something that demonstrates a new paradigm (GraphQL) and now just 'better Express'.

[zacol]

When it comes to the example, do you know any resources about structuring project by components? I really like the idea but I can't find any example or even article about that. Each project that I found was build with MVC pattern. It seems to be a great solution but nobody uses it...

[pchc2005]

Hello~ How is this going? I am trying to refactor my project to these practices, especially Section 1.1 & 1.2. However, I can't quite differentiate the usage of API and service. It will be nicer if there is a demo project as references.

[zacol]

@pchc2005 I'm trying to follow those practices in my simple application. I've modified some of them but an effect is still better than MVC structure ;)

https://github.com/zacol/chronicler

[goldbergyoni]

@pchc2005 @zacol

unfortunately, we haven't come to this yet but I can share with you my own draft, feel free to share any questions. Look at the service: ~/services/order

https://github.com/i0natan/nodebestpractices/tree/course/services/examples/microservices

[aqidd]

We're currently in the process of creating a starter project based on this best practices. mind giving the feedbacks @i0natan ? It's here : https://github.com/medigoid/express-component-starter

cheers!

[goldbergyoni]

@aqidd I would love to see this. Planning to do so in the next week, then bounce back here with thoughts and questions. If you have any dilemma that you encounter - feel free to discuss it here.

p.s. we're also starting a boilerplate project soon, I'll be glad to cooperate

[aqidd]

thanks @i0natan ! currently got a question : if a model requires another model(s) from another component to update the data/relationships, should we require them directly into the file ?

[goldbergyoni]

@aqidd I haven't got a chance to look into the repo yet, will do so soon.

I assume that a model is part of a component/microservice, right? does it tries to approach a model in another component or within the same component? if you can share prtscn of the project structure while highlighting the models (e.g. prtscn of the solution within the ide) it could be benefical

[aqidd]

sorry for the late reply @i0natan , perhaps below illustration will help

components
 doctor
   doctor.js (model)
 nurse
   nurse.js (model)  

doctor will have nurses assigned to them. should doctor component require directly from nurse.js or we should make some kind of bridge for that to make them more decoupled?

[goldbergyoni]

@aqidd Interesting discussion. I'm on a travel until Wed, answering soon...

/remind me in 3 days

[reminders[bot]]

@i0natan set a reminder for Oct 10th 2018

[reminders[bot]]

:wave: @i0natan,

[goldbergyoni]

/remind me tomorrow

[reminders[bot]]

@i0natan set a reminder for Oct 12th 2018

[reminders[bot]]

:wave: @i0natan,

[imVinayPandya]

I am looking to create Micro-service architecture using node best practices. it will cover Es-lint, Docker, Docker Compose, Swagger, Api Test Cases (integration test cases), SonarQube etc.

[goldbergyoni]

@aqidd Here again, sorry for the delay, my plate was full. Here are my thoughts on the great doctor & nurse example you brought up:

When I refer to independent components - I actually mean something similar to microservices. If we separate those as two different components, then doctor & norse are autonomous components (i.e. microservice) and cant have a direct link to each other (they won't even live on the same server). Doctor must get instead a reference to nurses, for example addTreatment(doctorInfo, **nurseId**).

The left question is - should you separate them as two different components or maybe they should co-exist in one? This is actually the classic microservice boundary question which is covered in many tutorials: if they must share the same DB, are always get updated together, developed by the same team and shouldn't grow to a huge code base - keep them as one component. If the opposite holds true - separate them and never hold a link from Doctor to Nurse.

Does this resonate with you?

[goldbergyoni]

@imVinayPandya That sounds great, we also will start our boilerplate/starter soon, would you like to join and build with us?

[aqidd]

@i0natan I see, but should there be a fine line between component and microservice? By your description, you seem to treat those two with the same definition. I was under the impression that component should be similar to microservice but with some loose coupling / relation flexibility. Please correct me if I'm wrong.

Let's expand further and put doctor and nurse into hospital component. I still want to separate those two into different subfolder / subcomponent. Are those component allowed to have tight coupling or should I go with loose coupling - relationship method? And in case doctor is growing too big and I want to separate the subcomponent into different project, should I expect that a lot of work will be required?

Thanks!

[imVinayPandya]

@imVinayPandya That sounds great, we also will start our boilerplate/starter soon, would you like to join and build with us?

@i0natan yes sure

[goldbergyoni]

but should there be a fine line between component and microservice?

A very thin one. The precise wording should be "autonomous components" - a component which has a high degree of autonomy. How? it's left for the developer judgment. A microservice is a very opinionated form of autonomous components, it mandates that component should have their own repo, and process and many other guidelines. As you correctly suggested, even when you design your app for autonomous components - you want to have freedom in choosing to which extent are they autonomous, for example, you may locate them in the same code based (hence the possibility to refer directly)

Are those component allowed to have tight coupling or should I go with loose coupling - relationship method?

No need to describe this in absolutes - loose vs tight. There is a whole spectrum here of autonomy, on the tighter end a nurse can be within the same aggregate with doctor, on the other loose end a doctor and nurse are different modules. In between there are also other design patterns where Doctor and nurse can be different entities of the same module. A module can refer to other module but only to the public members that were exposed so you gain a certain amount of autonomy. Now you have to choose where in this scale (spectrum) your design belong, do most Doctor operations involve a nurse? go to the tigher side, half of them? maybe somewhere in the middle. Otherwise go to the looser side.

And in case doctor is growing too big and I want to separate the subcomponent into different project, should I expect that a lot of work will be required? Depends where on the tight-loose spectrum did you opted, the tighter it's the easier is to get started but you may expect greater costs when aims for refactoring

@aqidd Did I help?

[aqidd]

yep @i0natan , planning to dive deeper into this topic and will get back to you later if I have some issues to discuss

Thanks!

[okonon]

we have used following starter project successfully which follows many of best practices: https://github.com/KunalKapadia/express-mongoose-es6-rest-api

[goldbergyoni]

@okonon That's one looks very nice, can you share here the highlights of the things you liked in this repo? maybe (always) we can learn some lessons

[okonon]

@i0natan sure. What I liked about that starter was the right balance of tooling - no gulp or Babel just plain ES6. I also liked express validation, Docker support and the biggest one for me was central error handling middlewere. It was really surprising to find that a lot of starter projects tutorials online do not even mention how important it is to handle your errors correctly.

[goldbergyoni]

@okonon Sounds great. I'll ping you once our is ready to get your feedback

[stale[bot]]

Hello there! 👋 This issue has gone silent. Eerily silent. ⏳ We currently close issues after 100 days of inactivity. It has been 90 days since the last update here. If needed, you can keep it open by replying here. Thanks for being a part of the Node.js Best Practices community! 💚

[carlkentor]

Ping!

[goldbergyoni]

@carlkentor Unfortunately this currently not our top priority, I believe it will be sometime soon but not over the next 3 months

[stale[bot]]

Hello there! 👋 This issue has gone silent. Eerily silent. ⏳ We currently close issues after 100 days of inactivity. It has been 90 days since the last update here. If needed, you can keep it open by replying here. Thanks for being a part of the Node.js Best Practices community! 💚

[HamzaAmar]

Hello @goldbergyoni do you still has a plan to make the example Project ???

[rluvaton]

@goldbergyoni Should we reopen this issue because there have been repeated requests?