Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am new to Node.js coming from a C#.net background. When coding in .net, I was use to using several of the design patterns to organize my code, service layer, repository, etc. When I needed to add logic that spanned multiple models, I could use services for this as well. Moving to Node.js and reviewing examples and sample code, etc. I do not see a lot of utilization of service layer, repositories, etc. What are some of the recommended practices for the following:
Code organization and structure, especially for apps rich in business logic?
How to handle logic that spans multiple models?
What are some good tutorials and sample code sites that demonstrate some good project and code structure with items (1 and (2 in mind?
.net comes with a lot of recommended approaches, practices, patterns and coding structure techniques that are actually very good recommendations. Sites like www.asp.net, etc. provide pretty good articles, etc. for these recommendations.
I am having trouble finding a consistent approach reviewing Node.js examples.
Like you I have come from C#/.NET to Node.js and found that much of what I thought was good practise in C# to be less than useful in Node.js.
Domain Driven Design (DDD) is not often discussed in a Node.js setting since DDD is usually associated with Object Oriented Design and Javascript is not an OO language (even though Javascript has prototype-based inheritance, a lot of OO patterns simply don't translate well to Javascript).
Instead we see more Microservice architectures whereby we break large domains down into smaller, decoupled services which perform one business function well. Node.js is perfect for these sorts of lightweight HTTP services.
The interesting thing I have found is that after trying a Microservices approach over DDD I actually find it much easier to implement and easier to keep things decoupled along appropriate lines. In fact when I go back to C# I find myself applying a Microservices approach there too.
In terms of patterns, abstracting away persistence is still an very good idea - something similar to the Repository Pattern translates well from OO to Node.js. As for where to put your business logic, I find I sometimes need a "Service" or "Application" layer over my repositories so I can reach into several repositories to compile a complex response. Sometimes you don't need that additional abstraction, so just put it where it's needed - don't get too religious about having layers for business logic - that's N-Tier thinking and it causes a lot of unnecessary code to be written. Add abstractions when they become useful, not as placeholders just in case they are needed - that's a kind of premature optimization.
When we need really high-level business logic, we may need to coordinate the actions of several Microservices. Node.js is your friend here too - you can write lightweight orchestration services that consume messages off an ESB and react to them.
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 4 years ago.
Improve this question
I am doing some research into the possibility of code splitting a huge monolith SPA (AngularJS) into multiple repositories. Whether we should do it or not? The benefits and pitfalls.
The Idea:
The application consists of multiple features (user management, analytics, event management) which are made as individual angular.module.
The idea was to split these different modules into their own repository and have some kind of master repository which would put all the pieces together before deploying.
The reason
Our application is huge now and will only get bigger. Also, the number of developers working on it is increasing.
Other reasons:
More manageable and maintainable - only feature specific files available
Easier to update to newer version of angular - one repo at a time
Findings
I have read that micro frontend architecture is becoming a more and more popular way of structuring big applications.
On the other hand, this will scatter files making it more difficult when fx. refactoring shared modules. It also appears that fx. Facebook and Google have mono repo.
After several days of research, I'm still torn. I see advantages with both, mono repository and multiple repositories.
I have also looked into git submodule as a way to "import" the features into the main repository. This is my least favorite options though. Also, I've never heard of git submodule before now so if anybody has some experience in that area please feel free to jump in.
Finally, the most important question: Is it even possible to have one AngularJS application split into multiple repositories?
Additional information:
Microservices: Mono repo vs. multiple repositories
Handling Monolith Code Bases
I have had the same issue the internal conflict that comes with it. The best answer I have found is this. "You and your team are the best people to answer this question." I know this goes against the hype of things like Micro FrontEnds will rule the world but it is the truth. This explains why some people use monoliths and are really successful like Facebook and others have the opposite outcome go with Micro Frontends and then become successful.
The only real problem in managing large amounts of code is a human problem not a technical problem. So this is a social issue. Sure, technical things change with this decision but in the end of the day you are just changing the human interaction between programmers and this code base.
So why is your team the most qualified to make this decision. You know the social dynamics of your team and corporate culture better then the rest of us.
I asked myself these types of questions when I was making this decision.
How does the team work together?
How is your team trained?
How flexible is your team?
How clear and open is the communication between teams and team members?
I would answer these types of questions and continue using case studies like Facebook which proved size of the team on a monolith does not really matter but how you work together on that monolith does and make the decision based on that.
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
When developing single page applications I always question myself which is the best way to design my project. Should I de-couple client and backend? Should my client application be in the same server as my backend code? Should I invest in multiple hosting plans for client and server ? So I'm asking, which is the best approach to organize and develop a single page app?
When I was first getting started, this is a question I had and it was hard to find a complete answer online. Generally speaking, although this will be an oversimplification, here is how companies move through this process.
Monolith: An application where the back-end and front-end code live within the same project.
What this means: The codebase is easy to maintain because it is all right there. There are less complexities initially and much less time to production because it is easier to get "out the door". You don't have complexities such as how different parts of the "system" talk to each other, etc. All start-ups start here.
The cons here are that eventually the code base becomes very unmaintainable as developers cram new features and ideas into it. Also, your API is not exposed, so it can only be used for this application (more on this below).
Front-End & API: An application where the front-end code and API live separately in different codebases. The API provides just the data, usually in a JSON format in which the front-end code consumes and displays this data.
What this means: Now that you've broken out the API and front-end code bases, you can use the API to provide data for ANY front-end application that needs it. For instance, think web vs. mobile. They can both use the same API. For a larger app, this becomes much more maintain able and now you can build teams around both back-end and front-end processes. You can now achieve better scaling and efficiencies too as the project grows.
The cons here are that you now have two separate codebases to maintain, up-keep, make updates too, make sure are in sync, etc.
FEBE & Micro-services: An application where all parts of the "system" live in very siloed codebases, architecture, etc. A FEBE is a "front-end, back-end" and a micro-service is a service (could be an API) that serves a VERY specific function within the business logic. The front-end in this world may need to consume several micro-services to accomplish its goal.
What this means: This is where successful, larger companies land eventually, if they make it. Again, oversimplification, but all of the major companies are running infrastructures in this realm. This architecture is much more for teams than for coding or development. Companies with hundreds of engineers can give them each a piece of the system to own and maintain, enabling them to release at their own pace to production, etc.
The cons here are that the system is now broken into hundreds of pieces and without the man-power becomes extremely difficult to maintain. Again, the reason companies do this is because it allows teams to operate extremely efficiently and independently.
All companies as a start-up generally migrate down this list, starting with the monolith, as they survive, turn revenue, become profitable, hire more people, etc.
My advice to you is this: Start with a monolith using a Node.js (Express) back-end and either an React.js or Angular front-end.
I say this because Node.js is the future and is very easy to learn and either React or Angular are good starting places in terms of frameworks.
When you move to Phase 2 (the front-end and API), stick with Node.js and probably React at that point OR if it were me, I would just consume my API's data in Handlebars and be done with it (not using a front-end framework at all).
Hope this helps. I replied because I know how frustrating this was for me when I was searching for an answer years ago.
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
I'm writing an app, which does OAuth authentication to several providers (e.g. twitter, facebook). I'm new to Angular, the UI / model is written in Angular without an issue.
But, I've got a lot of helper methods, e.g. callApi, checkVerification, getToken, etc. etc.
I think about 8 methods. I've been looking into creating factories in AngularJS, but I don't know why I should do this? It will require a lot of rewriting and I don't see the advantage? Why not keep it simple with helper methods?
A factory is just one way of creating an angular service. You can group your helper methods into these services.
Being a angular programmer and not using services is exactly like being a electrician and not using the ground wire, its not really needed for anything and saves time to not have to hook it up, but you are taking risks of starting a fire if some appliance has a short. In programming the risks are in terms of code flexibility, maintainability, and test-ability. If one of your modules does not work as intended, it will be harder to debug, etc.
When you have a significant amount of code, logical groupings of helper functions into services helps you more easily organize or find them and test them.
This best practice is suggested by many senior developers who worked on large angularjs projects and have had successful experiences by structuring code in this way. It provides another layer into which you may find you want to insert code later. If you don't have it in place, you won't use it (for the reason you just said, it will take you time to rewrite) and then your code will just end up messier and messier over time. A major feature of angular is to encourage code organization and test-ability.
Of course, you can write code any way you want that works, but using services (via factory or other methods) will help you not end up with large project that becomes a very difficult to maintain mess over the long term. Like other design patterns, very smart programmers have discovered coding structures and best practices that yield powerful long term maintainability benefits.
See: Why use services in Angular?
for more views on this.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 months ago.
Improve this question
I'm loving node JS and, coming from a Java background, am interested in even trying it out for some projects where node may seem a bit of a stretch, such as a search engine project.
One thing I've been a bit confused by is it seems JavaScript is lacking traditional data structures, for example a set, which has a precise definition extending even beyond computer science as it has been used in mathematics before computers existed (basically a list that doesn't allow duplicates). It seems when using node JS there is no library like Java.util that has these basic data types that I have grown accustomed to, I realize I could create them myself but this just adds more overhead to the project.
Are there any libs for node (or JavaScript in general) that address this? I think node has a lot of potential to replace the use of a language like Java for a lot of projects as it has so many advantages in terms of development speed, but having to recreate data structures that are taken for granted in a more mature platform could be too much overhead for a small project.
I apologize if there are other questions like this, however I spent some time searching and didn't come up with much.
es6 has a Set class built in:
new Set([iterable]);
see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set
Collections.js has Lists, Maps, Queues, Sets, and Heaps, all with consistent interfaces. Github.
it seems JavaScript is lacking traditional data structures...
Yes, this is javascript, the very concept and implementation of data structure is done quite differently from languages like Java.
I'm not sure that you're really going to find what you're looking for with Javascript. Howver, there are some libraries like underscore that should make it easier to build the type of structures that you want.
Its no longer true that node.js doesn't have Set and Map objects among other things. node.js has had them since at latest v12.
But of course, if you want libraries like java has, check npm or github. You're not limited to what comes standard in node.js.
Have you looked into Underscore.js? http://underscorejs.org/
It's not a one to one with java.util but it provides a bunch of commonly needed utility functions.
As a lighter and faster alternative to Underscore.js, Lo-Dash (http://lodash.com/) is getting traction those days... But this is not Java.util! :-)
Have a look at this one: https://github.com/chenglou/data-structures
I think it fits what you are looking for.
js-sdsl
A javascript standard data structure library which benchmark against C++ STL.
This library has strict time complexity guarantee and can be used with confidence.
The latest beta version includes iterator functions which can be used like iterator in c++.
Included data structures
Vector
Stack
Queue
LinkList
Deque
PriorityQueue
Set (using RBTree)
Map (using RBTree)
HashSet (for reference only)
HashMap (for reference only)
Usage
To help you have a better use, we provide this API document.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I need to develop quite simple web application with some Ajax functionality and GUI components with Java as a server-side language. The main purpose for me is to learn sth about designing web app that I can make use of when I start looking for a job ... .I ran into lots of framework (RAP, Nice JSF implementations etc.) and there are also GWT and JQuery . I started reading about GWT and it seems to be great at the beginning, but there are limited number of visual components. When You missed one it seems to be much harder to write it with GWT than in JavaScript/JQuery (e.g sortable components).
Also:
If JavaScript is is easy why to learn API to just make translation?
The main argument seems to be that GWT is for developers who don't
know Java Script very well, but is JS harder than GWT API and
configuration to work with?
GWT offers also very nice Remote Procedure Call and translating
objects to JS, but there are lots of libraries like DWR.
You need also to use standard servlet to e.g send file stream to a
user, so You need also to save it to a Database or as a hidden XHTML files to make them available to servlet.
So should I start to learn GWT? It is really wide spread? Or maybe JSF implementations with Ajax support outperforms GWT in usability? The biggest problem I have that I cannot imagine how to solve simple problems in GWT while they are almost complete solutions with JQuery. Mixing JavaScript native code with GWT don't seems to be a good option also.
When working with GWT, its always better to now whats going on behind. So you have to learn HTML, CSS and JavaScript as anyway. Maybe you can start with less knowledge on browser frontend technologies. But you will come to the point where you need to know whats going on.
So ask yourself. Is your app large enough that its worth to start with complex GWT app. Also if you're on a large team and familiar with JAVA, Maven and Junit it makes senses.
On the other hand there are a bunch of small (backbone.js with jquery), middle (mootools) or large (extjs) JavaScript frameworks to build RIA.
I've never work with JSF, but all people a meet that used it, wasn't really satisfied.
After all I dont think its a good idea to select a framework by the current feature set of your app. As this can change of the time, you will have to implement it later with a technologie you not familiar with.
Note there is a table sort library for GWT as well: http://code.google.com/p/gwt-advanced-table/
GWT contains several unique features which make it difficult to be compared with other frameworks. The key point is that GWT isn't just a framework or library -- it's a toolkit. Consider:
Ability to use Java IDE's and debugger during development
Automatic generation of compiled scripts optimized for different browsers
Benefits of java for organization of code-base: OOP, package system, checked exceptions, compile-time type-checking etc.
These features make GWT suitable for big projects built by large teams that should be enhanced and maintained over a large time-frame. Off course, many projects do not have such requirements and therefore developers should give more weight to other consideration like widget library and learning curve.