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.
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 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 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 3 years ago.
Improve this question
I developed a Node.js Application that I would to like to sell to my clients on monthly charges.
I'm looking for solutions to:
Keep my source code safe
Easy client installation
Serial code solution for activation
Application update method
Any advise will be appreciated.
Similar Question: Secure distribution of NodeJS applications
Your goals
Keep my source code safe
The only way you can do it is by making it a Web application that is used as a service instead of being distributed to the client. Don't trust anyone who tells you about code obfuscation or encryption as this is inherently impossible.
Easy client installation
Nothing easier than a Web application.
Serial code solution for activation
For a Web application you don't even need that. And for any application that you distribute to the client it will be trivial to circumvent and there is no way around it.
Application update method
Web application is always up to date. For a distributed application you can take a look at the Electron auto updater.
Any advise will be appreciated.
General advice
My general advice would be to keep in mind that any Node application that is distributed to the client will be very easy to analyze the source code and to circumvent any activation features that you implement. The only thing you can rely on in that case is law, not technology. Make sure that the licence is enforceable and the terms are clear. Distributing the source code doesn't mean that it has to be open source. The license is what's important, not the visibility of the code.
Your options
Depending on what the application does and how the interface looks like, something that you said nothing about in your question, you have few options:
Distribute the application as is and rely on the license to protect you but understand that anyone could be able to analyze your source code no matter what you do. Here you need to manage updates for every change. People will be able to circumvent your activation code feature.
Make it a web application and keep its inner workings completely to yourself. Here you have no updates problems or source code visibility. No need for activation code, you can give access only to paying customers.
Make it a service and keep all the important logic in your backend API and distribute only a thin client that uses that API. You only need to manage auto updates of the client, the backend code is always up to date. You don't need to implement activation codes, people can just log in to the account on your system in the client program and your backend will know who is a paying customer and who's not. The only source coude visible to the client is the client side code which can be minimal and doesn't have to include any critical logic.
Of course it all depends on the nature of your application which you said nothing about.
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 trying to catch up with modern Web application design approaches. With the latest technologies, is it still appropriate or necessary to tie a web application to a specific backend language like PHP, ASP.NET or J2EE?
I've been thinking of HTML5, JavaScript and asynchronous queries. An application could potentially consist of a series of simple, empty HTML document templates where the data components are filled in after the page load event using JQuery/XMLHttpRequest calls to a web service.
In this context, the backend web service could be implemented using any arbitrary framework and the serving of HTML pages could be handle by any web server. The application's web component would then be purely HTML5 and JavaScript with all other business logic hidden behind a web service interface.
But is this an effective design for complex applications which rely on session management and page transitions? Does anyone code this way or are traditional backend languages always used to generate the HTML documents?
Thanks.
Interesting question, I view it as this way. HTML5 is no longer HTML5.. but "HTML". We'll never see an HTML6, the new HTML5 model will continue to be improved upon and have features added to it. Some day, the days of needing third party plugins for video, audio and drawing, all devices will share the same front end presentation model.
When you think of it, frameworks like PHP just make dynamic HTML, and marry business logic with presentation logic. For the forseeable future, couldn't we always have a need for something like that? That being said, I can certainly see numerous applications in the future that leverage open data and rich client side controls. I don't think this threatens the extinction of ASP.NET, PHP or J2EE.. I think it enhances them, as now we all have a more fuller toolbox to develop with.
Scott Hanselman gave an awesome presentation 2 years ago at Microsoft's Build conference (http://channel9.msdn.com/Events/Build/2012/3-027), it's a great discussion on how JavaScript makes the web browser an incredible emulator, and that you can now front load logic and programming onto the end user... similar to what you are thinking. In the end, I think options like this just allow us to make sure that we use the tools for the appropriate reasons, just like in the ASP.NET world we now have Web Forms and MVC.. Web Forms aren't dead, they're just not the only game in town anymore, but now we can use Web Forms when appropriate, and MVC when appropriate.
Great question!
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 9 years ago.
Improve this question
Now I don't have any specific question, rather a general, ask for opinions post.
Within a month we will receive the documentation of a project we have to develop. The website has a lot of potential and will be advertised in TV and radio as well when it'll be done. So it'll have a lot of visitors, members and it'll have a rich admin panel with lots of options. My friend who was asked to be the CTO is a senior PHP developer with almost 10 years of experience and I am a junior JS developer. (or less, I don't have years of experiences in JS, but I'm committed)
Is a JS MVC framework substitute for PHP? Is a PHP MVC framework substitute for JS? Are they both working well together or is it possible to not use any framework, but write the project in MVC approach?
For example:
model: PHP
controller: JS (jQuery+Ajax)
view: HTML, CSS
As my friend is a professional PHP developer and will have a daily job next to, but only in the beginning of this project, he doesn't really want to learn an other language (like Node.js), because almost everything is a routine for him now in PHP.
I know everything depends on the documentation and what we have to develop exactly, but I'm just a curious mind and want to understand more. I know I have much to make up and sometimes I worry of my current knowledge, but then I think that be whatever big the challenge, there will always be a solution for it.
MVC does not mean to use differenct languages for all of the modules (model, view, controller), but to loose couple and encapsulate certain parts of your application.
Against many opinions, MVC is not the panacea for application development. It really depends on the application you're developing.
It's not necessary to use any frameworks in order to follow the MVC approach. In fact it's a pattern that can be tied together very quickly, in it's most basic form.
If you decide to use your backend as an API and pull the data via frontend, you don't need to use MVC come hell or high water. For an API for example it's not necessary to perform most of the view tasks. Instead you should care about building a performant and scalable data storage layer (which for example is able to easily provide your data in many common formats, such as XML or JSON) and a strong router that can handle HTTP Requests nicely (See if REST is something for you).
In this case you want a strong frontend which can handle templates, and also has a strong layer for obtaining, sending and handling data in general. A strong controller layer that can delegate tasks to certain parts of your application would also come in handy.
Well you see what I'm talking about. It really depends on your application. In my example the backend wouldn't exactly follow the MVC approach, while my frontend would completely. MVC isn't about switching programming languages for certain parts of your application. Instead it decouples your application structure making things a lot easier.
Of course Frameworks come in handy when developing such an enterprise scale application, but it's not necessarily required.
To sum things up: MVC has not much to do with the code itself, it has much more to do with architecture and structure of your code. How exactely you're implementing it is absolutely up to you.