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.
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'm working on a project with a friend.
He is by far a better programmer than I am, as I have been programming for a little over a year.
I noticed he often builds components, and functionality from scratch. I'd consider him almost a "hipster" in terms of building functionality from scratch.
Is there any downside to my approach of utilizing npm libraries, etc for use? Ie. Date Pickers, Map Components, etc?
One reason I might conjure up is that perhaps there's a performance hit. Will load time be affected significantly? I'm not building a large application, in fact I'd consider it small, BUT! I'm wondering if I'm "cheating", OR this will lead to bloat.
As a quick preview, my basic functionality would currently look to include:
Emoji Picker
Date Picker
Google Maps API Maps Component & Places
Form Validation Library
Superagent
Moment.js
First of all you're not cheating.
It's quite common for developers to use third party packages.
But it can be good experience learning to build your own components.
Don't forget you can always swap them out as your experience, knowledge grows
Pros.
They can save you development time.
They can do things that you may find difficult to implement.
They can be better written and tested.
Cons.
They can be badly written, unreliable, unsupported.
If you don't know how they work they can be problematic if there's a bug or if you need to extend the functionality.
You could end up including a lot of script that is unused.
You might be able to write something better and more maintainable.
Bundling, minifying, uglifying your JavaScript and tree shaking with tools like rollup can help keep your download sizes down.
If you use packages, use reliable ones, look at reviews and ratings, check out the activity and issues log.
As with all concerns performance related - test.
Use fiddler or chrome to see how big your downloads are, measure your download times.
Where possible test under realistic device/network/load conditions.
It's a good test of knowledge on your part, since you are new, to attempt to write all of those things yourselves. It's how a good portion of the users of stackoverflow learned: take on a project that sounds doable, but has an unknown section for you at the time. It's how I personally learned just about everything I know.
That being said, I don't think it's cheating. There's a common phrase in English: "Don't reinvent the wheel." The reason that those libraries exist is because someone took a lot of time to make them, and then realized that other people could probably benefit from it as well. With the example of Moment, working with Date/Time in any language is a huge pain, and the reason Moment is so popular is because no one wants to go through all of what Moment's creator(s) went through already. Why waste time reinventing a perfectly good, well tested, and reliable wheel?
Now if ever you go "man, this wheel is nice, but wouldn't it be better if they were made out of something more durable so that they can go over more bumps?" then in this case you are improving the wheel -- and similarly there are many projects that started off as a fork from an already existing one looking to add what the author felt was missing functionality.
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.
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 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 8 years ago.
Improve this question
There are a lot of "buts" in approaches to web development. Recently I've read an article
why not to use Twitter bootstrap. One of the reasons were that it doesn’t follow best practices. Well I don't want to discuss about TB. What I wanna know is how is it with Modernizr - it looks like that has a lot of advantages, but what about dissadvantages? Is that also redeemed by using bad programming practises on web (like these mentioned in twitter bootstrap)?
By good practices I mean ideas which are connected with Html5 and CSS => this is not opinion based question - I'm basicly asking if Modernizr is in contrary with these ideas.
Modernizr itself tries to follow best practices as best as possible, however there are a few things that it does that aren't necessarily "best practice"
it basically requires being loading in the <head>. Since one of the main uses of Modernizr is the css classes that are added, you actually want it to block the rendering of the page until after it has ran. If you load it in the bottom of the page (which is the "best practice" for javascript, generally) and rely on the classes it provides, you would see a flicker between the non-support and support versions of your styles as it runs.
It can be heavy. There are ongoing discussions on the github issue tracker about how we can improve the execution time of the library, as well as new preposed updates to the lib that would group tests to increase speed
Not only that, but it can be used poorly. One of the most common issues is that people deploy their public website with the debug build of Modernizr - the one that includes ALL of the tests. This means running very large amount of javascript that never impacts your site.
Other than that, modernizr tries very hard to help define best practices, let alone just follow them. If you ever find there is any issue what so ever, I would really encourage you to open up an issue on the github repo to help us move the internet forward.