How about an example project? about nodebestpractices HOT 42 CLOSED

@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

from nodebestpractices.

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...

from nodebestpractices.

@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'.

from nodebestpractices.

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

from nodebestpractices.

@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.

from nodebestpractices.

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

@i0natan Yes! This would be amazing 😄

from nodebestpractices.

@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

from nodebestpractices.

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.

from nodebestpractices.

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

from nodebestpractices.

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!

from nodebestpractices.

@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

from nodebestpractices.

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

from nodebestpractices.

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?

from nodebestpractices.

@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.

from nodebestpractices.

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

from nodebestpractices.

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

from nodebestpractices.

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!

from nodebestpractices.

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.

from nodebestpractices.

@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

from nodebestpractices.

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 ?

from nodebestpractices.

@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

from nodebestpractices.

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

/remind me in 3 days

from nodebestpractices.

@i0natan set a reminder for Oct 10th 2018

from nodebestpractices.

👋 @i0natan,

from nodebestpractices.

/remind me tomorrow

from nodebestpractices.

@i0natan set a reminder for Oct 12th 2018

from nodebestpractices.

👋 @i0natan,

from nodebestpractices.

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.

from nodebestpractices.

@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?

from nodebestpractices.

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

from nodebestpractices.

@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!

from nodebestpractices.

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

@i0natan yes sure

from nodebestpractices.

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?

from nodebestpractices.

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

Thanks!

from nodebestpractices.

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

from nodebestpractices.

@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

from nodebestpractices.

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

from nodebestpractices.

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! 💚

from nodebestpractices.

Ping!

from nodebestpractices.

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! 💚

from nodebestpractices.

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

from nodebestpractices.

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

from nodebestpractices.