We have a web app (CRM type) working on Linux (Debian) with Apache, MariaDb and PHP for the backend, and AngularJS (1.x) for the frontend.
Thinking about a redesign, I need advices on a solution I have in mind, but I'm not sure it would be relevant...
A new website (e-commerce) will come along the CRM and use directly or not (API) the same database.
So my first take would be to put the MariaDb on a dedicated VM. It uses much ressource right now, so much more with another app using it.
Then the CRM and website could connect directly in remote (too risky?) or call an API. I guess the second solution would be better and means I could put my backend PHP part (already working as an API for AngularJS) along with the database, on that new VM.
I guess Debian + Nginx would be a good choice to go with them.
I prefere PHP to handle databases 'cause I'm used to it.
On the other hand I would still have AngularJS alone, a deprecated JS framework.
One thing that was hard to work with, about AngularJS/PHP, was that sometimes I needed to format data for Angular from PHP, and vice versa. It wasn't very clear where to put that formating, 'cause the backend was more about the database and not the frontend, and the frontend more about layout than PHP ORM ans design.
Furthermore, we'd like to keep the CRM as a SPA (Single Page Application).
My take on that would be to go on a MEAN stack, without de M (MongoDB), starting from scratch, just keeping Debian and installing NodeJS, ExpressJS and Angular or another JS framework (Vue, React...).
A hole JS stack to have the same language and gain speed and performance with many little transactions with the server (assets, calls and promises to retrieve data from database). Also to learn more on JS and NodeJS particularly.
NodeJS to create the environnement and a web server, in place of Apache.
Angular (or another) to put data into HTML, and have the less treatments possible.
ExpressJS to be that intermediate part I was talking to, the place where formating can be performed: retrieving data from the views, formating them, sending them to the API, handling the response, formating it if necessary and returning it to the view.
It means I would go from one VM with:
AngularJS (frontend) -> PHP framework (backend) -> Database
To two VM with:
Angular (app frontend) -> Express (app backend) -> PHP API (database backend) -> Database.
What do you think of my use-case and the solution?
There are several benefits to splitting up your services, but almost equally many different solutions, so you need to ask yourself what your goal is. Performance? High availability/failover? You might need a lot of VMs, geo-redundancy, load-balanced VIPs, etc.
You can also look into making containerized services with Docker.
You talk about moving the database onto a separate VM, but that it might be risky. Why? If they are both on an isolated network, it should not be an issue.
If you're looking for stack advice, since you're talking about a full remake, I would recommend something both stable and modern like Laravel + VueJS for the web/API part. You're already comfortable with PHP, and a setup with Nginx will probably be much faster. But of course, there are almost infinite combinations to choose from these days.
As for the "direct or not" DB access: Having a versioned API is always a benefit.
Serving the SPA frontend will require very few resources, so your bottleneck will be between the API backend and DB. You can make it scalable by putting the API behind a VIP and load balance with something like HAProxy/Nginx.
Related
Are my assumptions correct here, is there a different need for a separate backend, or can a monolithic (hopefully simpler) solution accomplish the same functionality perhaps at the cost of not scaling as well?
Looking at existing MERN or MEVN solutions, they always seem to involve two node processes where the front end process is running the client framework and backend processes DB requests using Node, Express & Mongo. This seems like a good solution performance wise when balancing across at least two servers. For my solution, where performance is not the issue, I've wondered what is the need for a separate backend. Why not just use try/catch with async/await in the front end to get to the DB data instead of an api call to a separate backend. Then once I started trying to design my more monolithic solution, I realized there is a problem that the separate backend actually solves. Trying to avoid DB concurrency issues, I realized the separate backend solution actually lowers the need for logical transactions since node is single threaded and only processes one request/response at a time.
So if I understand correctly, you're asking why do you need a backend that talks to the DB (and potential other backend services) instead of calling the DB from the front-end directly.
The answer is the following:
If you run this application on your local machine only (front-end and DB), then I can see why you wouldn't need a backend.
If this application is exposed in Internet, then your DB will hijacked in a matter of minutes maybe.
Security is the main concern here, everything that runs on client-side (JS stuff) can be seen pretty easily by the user -- this includes endpoints, passwords, etc. Not to mention that your business logic is fully exposed to the attackers.
For that reason, the backend plays a very important role in protecting the access to the DB, rate-limiting and resource usage capping, and many others.
I'm new to Node JS development. As an ASP.NET MVC developer, I normally use Repository Design Pattern where I have separate projects for Front-End and Database access in one solution. In addition, when creating a REST api, this can be added to the existing solution. So when publish, it api and front-end is separated by a different route.
I've just created a REST Service in Node JS and it's really simple and I like it. However, when it comes to Front-end I was looking at ReactJS, I've seen a blog (unfortunately, I can't find the link) where it separates the process between the REST service and react front end. I'm just wondering if this is a common design pattern in nodeJS using ReactJS. And if there's a benefit on doing this. Specially nowadays, Full Stack developers are a common thing. I can see the benefit of it from a maintenance stand point but I'm just wondering if there's a benefit in terms of server resources i.e. memory, cpu. Should the OS handle 1 vs 2 nodejs process? Will this differ from using linux vs windows?
I see a huge benefit of separating the frontend from the backend so I would propose you to have your Node backend running in its own project and let's say a React solution running on its own. The React client can then consume that API together with other APIs later. By separating you have the benefit of scaling later.
If you've already built the REST service in node, you can access it via proxy in the React project's package.json by adding
"proxy": "http://127.0.0.1:5001/"
It helps manage CORS issues.
I have done a website in Nodejs and Expressjs and a question struck me. My front-end and back-end are integrated together, meaning I needed to use routes and such to direct users and show the web page. However, if I want to make a mobile app and would like to access the same server and same database, how would I do it because my knowledge right now is limited to back-end and front-end much be developed together since I can't really separate out the front-end HTML stuffs from my Nodejs set-up.
I think it is an easy question but a confusing one to a newbie like me
The most common way to do this in my experience is to build a REST API, which you can still do using Express if you're comfortable with that. You would probably mount a separate Express app on some other url (https://api.example.com/ or https://example.com/api), for example. Ideally, you would have done this first, and then had your web site hit that API as well, but since you didn't not a big deal. If your code is appropriately modularized, then all you should really have to rewrite is a thin layer of controller code (for example to res.send() rather than res.render()).
Why I'm looking at node.js
I have a low-traffic site with .html, .css, and .js files. For the purposes of this post, a good analogy is a high school course website for learning javascript. I need to add a tiny bit of backend. I need
1) A small db to store users and their "grades." I've used php+mysql on apache for something like this in the past
2) An ability to evaluate user-submitted javascript server-side and grade the result. Node.js has vm and sandbox, so I figure I should turn to node.js (if you have an alternative approach let me know!).
My issue
I've never used node.js before, and I'm a bit confused by the tutorials out there and how they fit into the "old fashioned" web development context. The hello world tutorials start with making a server. For the purposes of having a tiny backend, that sounded like overkill, until I read this, which explained things a little better, saying that (in simplified terms) node.js replaces apache and has added benefits, etc.
In order to have the capabilities of the tiny backend I list above, is a full node.js app necessary? At this point I don't need persistent I/O. I only need the server-side javascript evaluation. Is there a way to have an "old-fashioned server" serve my html with a php backend for a database (bullet 1 above), but then add a small node.js app evaluating the user-submitted javascript (bullet 2 above)? I'm concerned that if, as a beginner, I run an http server in node.js I would be opening security holes that other super-mature web servers smoothly deal with behind the scenes. Also, if I get a hosting plan with nodejitsu/heroku/etc, do they not serve .html automatically? You have to start from scratch with a server?
First , Its not a bad idea to use node.Js to satisfy your requirement,the uniqueness of NODE and added advantage compared to conventional technologies like Apache-PHP is clearly explained in this following video Why Node.JS is better.The notion of NODE being just used for advanced or complex applications is wrong , you can use node for building applications which are very simple to anything of huge proportion.It would be a not so comfortable task for a node beginner to code without using any frameworks , but by using this web application framework called express , you need not code from scratch and its very easy to setup html pages using its simplified html templating language called JADE and route requests,also you can even use your html pages if you are not willing to use JADE for rendering the views of your application .Here are the series of tutorials which would help you Tutorials on beginning with node.js , Basics of expressJS ,
Advanced express tutorials.
The series of videos also have tutorials on getting connected to the no-SQL database MONGO-DB , Mongo is most popular database that is used alongside NODE backend , here is the video which compares mongo and SQL Mongo V/s SQL.
Using Node would also enhance the scalability of your web application , which is very important for any web based services .
Node is not meant to be used alongSide PHP , those are completly two different backend technologies , why would you want to use PHP-Apache and node together when you can very easily build the application using express framework , i suggest go ahead with NODE-Express-Mongo .
Intro
I'm trying out Node.js right now ( coming from PHP background).
I'm already catching the vibe of the workflow with it (events, promises, inheritance..haven't figured out streams yet).
I've chosen a graphic portfolio web app as my first nodejs project. I know node.js might not fit best for this use case but I it's a good playground and I need to do this anyway.
The concept:
The visitors will only browse through pretty pictures in albums, no
logging in or subscirptions, nothing.
The administrators will add,modify, reorder.. CRUD the photo
albums. So I need there Auth, ACL, Validation, imagemagick... a lot
more than just on the frontend.
Currently I'm running one instance of Node.js, so both admin and visitor code is in one shared codebase and shared node memory runtime, which to me looks unnecessary performance-wise.
Question
For both performance and usability:
Should I continue running one instance of node for both admin and visitor areas of the web app or should I run them as 2 separate instances? (or subtasks? - honestly i haven't worked with subtasks/child processes)
Ideas floating around
Use nginx as proxy if splitting into 2 applications
Look into https://stackoverflow.com/a/5683938/339872. There's some interesting
mentions of tools to help manage processes.
I would setup admin.mysite.com and have that hosted on another server...or use nginx to proxy requests from that domain to your admin.js node app.