Nodejs docs

[gomorizsolt]

I've roughly made the documentations for the further NodeJS project(s). Please read these thoroughly and carefully, because some of them haven't been finished yet. For example we haven't made a common consensus about the file and variable naming convention yet, therefore naming.md doesn't contain any specific description.

Questions:

• Shall I write other examples for particular stuff? If so, should I describe their intention in a couple of words?
• I didn't copy-paste the same text that's in the frontend docs, perhaps we can use the same approach here as well. What do you think? Obviously, the What to test? part is different.
• Is anything missing here?
• What would you write in a different way?
• Could you find either any unimportant or obvious text that shouldn't be mentioned here?

I'm immensely interested in your opinions, even though it's not in the final state.

[bencevoros]

I think UpperCamelCase is the best choice.

The examples are enough and understandable. You don't have to write additional examples.

The link to frontend docs is enough in the testing part.

In my opinion, everything else is good in the docs, I wouldn't change it.

[thisismydesign]

One more thing to think about is what if we don't have views. Do we still need the MVC structure? This is the case for vanity's initial setup where you only used controllers and models folders. That makes sense to me but it might make sense to look at whether there're any backend-only alternatives (if you didn't already). If we stick with MVC for both cases let's mention that the views folder might be skipped.

[gomorizsolt]

Thanks for the suggestions and ideas. It seems that there is a long way to learn how to write documentations properly, and also how to setup initial projects. :)

I'll refine the stuff you mentioned and look into the others asap.

[thisismydesign]

Thanks! To be fair it was quite good, I'm just nitpicky about this stuff, especially when it comes to the foundations of projects.

[gomorizsolt]

Sounds good to me to leave the MVC architecture.

I found an interesting article about a company's efficient folder structuring and how they gained it.

According to the article, it uses feature-structuring and leaves the MVC behind. Therefore it eases the file-searching method and there won't be long import statements at the top of each file. Besides, it also proposes to use configs folder. :)

What do you think? I'm curious about your opinions, it looks feasible for me.

If you're interested, here are some other articles. Each of them are built on similar structure, but they're a bit convoluted for this dummy phase.

• #1
• #2

Obviously, we can change their structure according to our needs.

[gomorizsolt]

Here is a proposal based on the first article above.

.
├── configs                                # configuration files
├── models / db                            # databases, schemas
├── dummy                                  # feature / component
│   ├── controllers                        # component's controllers
│   ├── routes                             # component's routes
│   └── index.js                           # export functionalities
│   └── dummy.test.js                      # test file
├── utils                                  # utility functions

[thisismydesign]

Well yes, these are the two prevailing structures: MVC and component based. I'd say in JS component based is preferred nowadays. However in your example the 2 seems to be mixed. We should choose either-or. The proposal you outlined for MVC is good, for the component based I also used the same article as a base in cryptofolio (with some extensions as described which I still find relevant).

How about something like:

.
├── app                                  # feature / component
|      ├── db                            # databases, schemas
│      ├── component_1
│            ├── component_1.routes.js                             # component's routes
│            └── index.js                           # export functionalities
│            └── component_1.js                           # functionalities
│            └── component_1.test.js                      # test file
│      ├── component_2
│            ├── component_2.routes.js                             # component's routes
│            └── index.js                           # export functionalities
│            └── component_2.js                           # functionalities
│            └── component_2.test.js                      # test file
│      ├── utils                                  # utility functions
├── configs                                # configuration files
├── etc project meta files

[gomorizsolt]

Indeed, it's really a mixed one.

• Why is it better to store the whole stuff in a single folder, just like how the app folder behaves above?
• Wouldn't this create a little bit of mess in the component's functionality file? I mean that single file might contain a bunch of functions later.

Btw, I agree that it's a better way, I'm just curious about the things I asked. :)

[thisismydesign]

I think mixing them would create more structural overhead than we need. Plus as usual I wouldn't reinvent the wheel, these two approaches are well tested and should cover 99% of use cases.

Why is it better to store the whole stuff in a single folder, just like how the app folder behaves above?

Otherwise with many components we'd have a very messy top-level view.

Wouldn't this create a little bit of mess in the component's functionality file? I mean that single file might contain a bunch of functions later.

Depending on how you break up components, yes it could. That's something we should think about in every case. It's the same argument for MVC btw. "Couldn't a component / controller / model / view file grow too big?" Yes, in which case we have to break it down somehow (e.g. utils, different components) .

[gomorizsolt]

Thanks!

Okay, I'll re-order the folder structure then and let's see in practice how it works/behaves.

[gomorizsolt]

Docs are updated based on the recent changes in the backend.

Hopefully all the stuff that were discussed above are covered completely.