How to distribute a Node JS Application? [closed] - javascript

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.

Related

Best practice about login [closed]

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 5 years ago.
Improve this question
I have made a decent website using HTML, CSS and JavaScript. I'm new to programming.
Now I want to give some privacy to some users and create a login space. I saw that some people are using PHP, other JS or Node.js, but I haven't seen any good guide for the best practice.
I would like to make a robust website with up-to-date technologies. What is the best practice for this kind of request?
It is very wide question and have so many answers and techniques based on your requirements, for example if you need to implement it yourself you need to use token based authentication, AKA JSON Web Token, technique where you simply send a token to you client after validating their username/pass to be saved in the browser and later on you can send this token along with any further API/HTTP request(s) for validating your encoded token that was sent before by your authentication service.
Check JWT site to know more about different libraries that will help you implementing this technique in almost all known languages (PHP, NodejJ, Python, .NET, and Java) in just 10 minutes.
Backend server or used language should not be the issue as much as you should understand the technique itself.
If you want to use Amazon Cloud, you can totally depend on their authentication services they provide, its name is AWS Cognito
If you need to implement social based authentication, then you should use OAuth protocol for integration with different sites like Facebook/Twitter
If you're using JS for your website then I would suggest using Node.js for your database. What you'll be creating is an authentication front to your app to protect the data within. Here is a good link on getting started with authentication.
Check this out
You probably would like to take a look at PHP.
If you want good security for your database, you will want to take a look into hashing passwords so in case your database gets hacked, it's not so easy for a hacker to get everyone's information. Not only that, but you're not a safe site if you're not hashing user's passwords, you'd be a phishing site considering you'd be able to see their passwords. (DON'T DO THAT) Here
You will also want to learn SQL for handling the information that will needed to be saved to a database for access through queries. SQL

Implementing a live chat system in Website [closed]

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 6 years ago.
Improve this question
I would like to add a live chat support channel in my website, mainly focused on new users who have specific questions about my services and i´be been thinking about the best way to implement this solution myself. do note that i do not intend to use third party solutions.
What i´ve thought about retrieving messages: i can have a form on the page that will activate on user click (like a "start chat" button), once the button is clicked, i will GET all messages in the database related to the client's IP address (if it's not a logged in user) through a web service and load it into the DOM. after this, i will have a javascript function that will execute every XX seconds asking whether there are new messages.
to send messages: the user will have a textArea with a "send" button that will trigger a POST to a web service in order to save their message into the database, on the Support/web admin side, everything will work in a similar fashion but with the option of having several chats at the same time. Also i think I can achieve this by using JQUERY and ajax requests.
Is this a good idea to implement a live chat services? or am I far off from the ideal way of doing this? I have browsed around and all i get is suggestions to use third party service which i definitely do not want to use. Thanks!
You should have a look at websockets, especially at the socket.io library, which provides you an event based communication between the clients and the server.
They even have an example how to create a live chat:
http://socket.io/get-started/chat/
I you want a chat that is not just a "proof of concept", you should go for using XMPP, it's the most popular (and maybe the only-one) opensource instant-messaging protocol. There are several implementations in multiple languages and it has proven its robustness.
Wikipedia :
Extensible Messaging and Presence Protocol (XMPP) is a communications protocol for message-oriented middleware based on XML (Extensible Markup Language). It enables the near-real-time exchange of structured yet extensible data between any two or more network entities.
source
You could also take a look at IRC, which is quite old but still useful.

What's the best approach to develop a SPA? [closed]

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.

With HTML5, JavaScript and AJAX, are PHP, ASP.NET and J2EE backends still required? [closed]

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!

Authenticating users without using php nor nodeJs [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
If you don't want to read what im trying to do just skip to the "My question" part :)
My goal:
developing an application that saves as much server performance as possible.
There is no such thing as 100% secure, the app of course should be as secure as its coded.
However the founder of http://lavabit.com/ actually managed to take his security as far as making it NSA-safe (which obviously is the reason he had to shut it down).
My Progress:
I already discovered the BackboneJS Framework, which has saved me a lot of server-side coding,
using javascript templating, routing, input validation,client communication using websockets.
My Question:
since installing node or php on the server is a security risk in itself (which is the reason security issues need to be patched on newer versions.).I would like to know if there is a way to authenticate users without being forced to install nodeJs or PHP.
If you're able to use HTTPS then perhaps you could look at just using Basic access authentication? The web server itself would do the authentication - more information on Basic Auth in Apache can be found here.
I really think the experience you get from using a server-side language and cookies etc. is far richer and offers a much nicer user-experience. I'm not sure I understand the security risk[s] which you allude to. Alternatively if security is something which you are hesitant about, and feel that it will slow your app down, then perhaps you should consider designing your programme in such a way that security is not an issue.

Categories