Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I try to find a good directory structure for my nodejs/express/mongoDB application.
Currently I use the native-mongodb driver which feels nice and fast but is limited when a proper structure should be defined... when MVC is the express/node way to go defining proper db models is not that easy.
Although mongoose and its concept of schemas would make the actual design of models easy but I am not that big of a fan of another layer on top of my stack... it feels kinda bloated to me.
I looked for an alternative and found mongoskin which is a thin wrapper on top of the native-driver but adds some features to support MVC-ish patterns.
In general I found this to be a common problem for other people too. I appreciate the idea presented in the link: https://stackoverflow.com/a/8428281/1055685
Nevertheless the query inside the model directory is not really MVC-like (as mentioned in the comments...) - I do not like it...
The MVC demos in express are not that helpful... did you find some inspiration there?
Which pattern do you recommend to follow (if MVC is recommended models are the real problem)?
Do you recommend mongoskin in general?
I would suggest looking at either LocomotiveJS or RailwayJS
LocomotiveJS is more "lightweight" and there is a great boilerplate available to get you started.
RailwayJS contains more "generators" to make it more rails-like however.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a legacy Ruby on Rails API project, I notice that the project uses both active_model_serializer and Jbuilder. There are app/serializers diretory for active_model_serializer, and app/view/api/ for Jbuilder.
I'm new to Ruby on Rails API. From what I have read from the internet it seems active_model_serializer and Jbuilder are both used to deal with JSON data, there's even an article arguing which one is better.
I don't know which one is better, but is it a good practice to use both?
There's no problem in using both, but it's definitely not a good practice. It can be confusing for new people coming to the project. I'd say it's ok to use both if you transition from one to the other (most often from Jbuilder to AMS), but it's good to eventually stick with one of them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is there any rationale why HapiJS endorses using 4-space indentations?
Source: http://hapijs.com/styleguide
Short answer: No better reason than anyone else - styleguides are typically only rules for project maintainers. They had to adopt some convention and that was the choice. As a user, you don't really need to care.
Long answer: Hapi is a great framework, built by the folks at Walmart. and specifically a person named Eran Hammer who was unhappy about some architectural choices made by Express, another server framework for Node. It is somewhat opinionated in general, it was effectively created in an environment of opinion, not to mention a large company (which means it desperately needed a convention). That said, you can safely use the Hapi API with any indentation you want, including tabs, though. Likewise, the Hapi internals could have been written the same way. Their specific choice likely comes down to established tools or conventions already in use at the company. Many different projects make different choices for a variety of reasons. In my experience, many large JavaScript applications go with 2 spaces and the Node.js core itself is written with 2. But there's nothing wrong with those that do otherwise.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are building a university website and finding a search solution for it. Our university website has high-traffic because it has faculty of open university so very much students (approximately 1.5 million). Even we use caching for speeding up the website. Anyway, which search engine do you suggest for our situation?
Note: We think Solr, Elasticsearch or Sphinx for now, but also it can be one of the others.
Update: We need a full-text search engine which must be fast, extendable and with the features like query likening and indicating priority support.
Thanks.
It really depends on your use-case, what features you want, and whether you have any experience with any of the technologies. I could paraphrase arguments, but there's a very good discussion here: ElasticSearch, Sphinx, Lucene, Solr, Xapian. Which fits for which usage? that covers the pros and cons of each.
Edit (in response to the question's edit):
Of these technologies I have only used Solr (and SQL), but I've found it to be easy to use and would recommend it. It supports native sharding and replication, which should cover the extendibility issue. It also supports things like joins and field weighting, which I think covers all your needs if I read your requirements correctly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
It's been a really long time since I worked with UML Diagrams.
I started working with UML Use Cases again, for a real world project. I would like to ask some questions.
How should I approach writing use cases?
I believe the tasks that leads to a "Major/Bigger" task should not be considered as use cases by themselves. Am I right?
Okay, what if I have a task like View tutorial and it has Comment on Tutorial, Favourite Tutorial, etc. Should these be separate use case, Extending View Tutorial? If yes, but, aren't they small features, why we should include them?
I'm mixing some stuff here, I hope someone could enlighten me .
Thanks!
Read Alistair Cockburn's Effective Use Cases book (see it on Amazon: 1). He does an excellent job of explaining practical use of use cases in a structured and effective way.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
looking into the nodejs server stack with nodejs/express and mongoose
What is considered a best practice solution?
(1) Creating a mongoose datamodel module then working with the model objects
(2) Creating a wrapper datalayer module that will internally use the mongoose model
Pros for (1)
I really like the OOP style classes mongoose gives me, add my own methods, my own setters and getters, I can add validation and event-handlers, and use the DataModel without redefining it in another module.
Pros for (2)
I should be able to mockup the data layer with simpler implementation (tests, etc..)
or switch a database if needed.
What do you think?
I usually start with the easiest and least complex option to start and only move to a more complex one when it's really needed. So in this case I always start with Option 1 and have yet to find an instance where I wish I had started with Option 2. If I really need to change databases, I'll do the work then instead of doing more work upfront for something I may never need.
Keep in mind that this depends on how big of a project it is and how many people are working on it. If it's a small team (or just you) extra layers of abstraction generally aren't needed. If it's a large project with a large team, I'd take a bit longer figuring out the best architecture for long term maintainability.