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()).
Related
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.
I have built a Rest-API with Express and mongoose, now it's time to connect it to a Frontend and I am bit confused, I have started building the Frontend of the app with hbs as the templating engine and that works well but I was also considering React for example and that brings me to my question.
What is the best solution here? to build the whole App in one folder so to speak, with a templating engine taking care of the Frontend or to create the API, host it and then use it with a Frontend application? It is a matter of preference or one is better than the other?
This really is a matter of preference. There are many benefits and trade-offs for each method. Here are some:
API with Single-Page Application
Benefits
Easier to make a more dynamic app
With an API you can allow third-parties to integrate with your app easily
Fast - after the app has been initially downloaded only data needs to be transferred!
API and frontend separation can help keep business logic in one place (on the backend)
Offline and caching are easy!
Downsides
SEO isn't as easy (but still very much possible)
Slow - if your app is big, the initial download speed can be slow (there are lots of solutions for this)
Multi-Page Application
Benefits
Fast (page download can be faster)
SEO is slightly easier
More secure by default (due to cross-site scripting on SPAs)
Downsides
Slow - unlike a SPA, you have to download every page
Harder to build and debug
This is by no means a comprehensive list of trade-offs but hopefully, it will help you make an informed decision. Personally, I prefer the SPA approach because I have multiple sites/apps using one backend as well as the ease of development.
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.
I'm currently developing a community (like a lightweight "social network") for a limited (local) target.
This is the first project where SEO doesn't matter and where I can happily exclude no-js users. That's why I'm thinking to start the project over and write my first site that is completely build with Javascript and my first Node application for educational reasons.
Details so far:
Browser: jQuery, maybe JavaScriptMVC (there are some things I don't like about JavaScriptMVC (like the routes), maybe I write my own little MVC or do you know a better suited framework?)
Server: Node.JS, Express framework, (maybe socket.io or nowjs for further features)
I got a few questions so far. I know it's better to ask a single question but there are more or less connected:
Express looks really nice but I'm missing MVC. I couldn't find any project that implements mvc and is build on Express. Is there a reason for that? Routing is nice in Express but I need a way to spread code across multiple files (controllers would be the best way I guess, the application won't be small and I need it maintainable)
The application will be more or less completely based on AJAX (json) requests. Is Express the right framework for such applications, anyway? I think the best way to write this project is to expose a json REST api which can then be queried by the web application over AJAX and by a mobile device app (which I'm also going to write). In my opinion Express' route system is quite suited for REST. But feel free to recommend other frameworks.
Have you seen Swagger? An API server available in Node.js with an automated UI Generator.
(source: wordnik.com)
To answer your primary question, yes there are controllers in Express. They are more akin to Sinatra (express is modeled after Sinatra rather than Rails). By that I mean they are light-weight method mappings to routes you define.
Browser: jQuery, maybe JavaScriptMVC (there are some things I don't
like about JavaScriptMVC (like the routes), maybe I write my own
little MVC or do you know a better suited framework?
I'd go with spine.js or backbone.js personally.
Express looks really nice but I'm missing MVC. I couldn't find any
project that implements mvc and is build on Express. Is there a reason
for that? Routing is nice in Express but I need a way to spread code
across multiple files (controllers would be the best way I guess, the
application won't be small and I need it maintainable)
You can spread files out all you want. I answered this here.
The application will be more or less completely based on AJAX (json)
requests. Is Express the right framework for such applications,
anyway? I think the best way to write this project is to expose a json
REST api which can then be queried by the web application over AJAX
and by a mobile device app (which I'm also going to write). In my
opinion Express' route system is quite suited for REST. But feel free
to recommend other frameworks.
I haven't built a 1 page app yet in node but from what I can tell, almost everyone seems to be using socket.io with backbone. That's not to say you can't, just that you'll find more examples that way.
You could check out Sails. Its structure is based on Rails.
I've build several websites using PHP and mySQL as backend, and believe that I'm fairly familiar with both. However during research for my new website I've come across node.js and mongodb (and socket.io, since the site is gonna contain a chat).
I've decided to use node.js and mongodb to run the chat - but don't know if I should just do the entire site with those two things?
Since I'm gonna run a node server anyway should I just run another (seperate) one hosting the website? Or is that an bad idea? - is it stable?
I could do the programming in PHP and still be using mongodb - but wouldn't node be way faster?
And another question:
I've planned to use ajax to handle all the posts to the page - but since I'm allready using socket.io to the chat - should I do all my post request using that?
For the ajax I've planned to use jQuery (also for all frontend effects).
don't know if I should just do the
entire site with those two things?
If you want to learn node.js then there is nothing better than coding it.
Since I'm gonna run a node server
anyway should I just run another
(seperate) one hosting the website?
You can use existing server and run your node.js app on other free port(o). I think for learning node you don't need to have dedicated machine.
is it stable?
Even versions of node.js are stable releases, however until there is 1.0 with feature freeze there could be breaking changes to its API.
I could do the programming in PHP and
still be using mongodb - but wouldn't
node be way faster?
It most probably (and definitely) would.
I've planned to use ajax to handle all
the posts to the page - but since I'm
allready using socket.io to the chat -
should I do all my post request using
that?
I would recommend stick to MVC model and use express since you can get into lot of time consuming troubles if you would use socket.io for classic stuff. Socket.io is namely for real-time functionality and things related to that.
There are already some solid web frameworks for node.js, in particular check out Express. Here's a really good article outlining some lessons and experiences from building a node.js website:
What it’s like building a real website in Node.js
Regarding your second question, it's probably still best to use AJAX handlers and HTTP with jQuery. I'm not sure that jQuery supports callbacks over raw TCP sockets.
node.js + express + jade + stylus + jQuery is my preferred environment.
Using forever to auto restart the server I've never had any real up-time issues even when I have bugs crashing the server on a regular basis.
As for socket.io + jQuery, they do get along fine, but it's just not as natural as the express + jQuery combo. I'd stick to making ajax calls for most things.
Node.JS can still be a little wild west like, but its improving. It is a very different model from coding in php, but it is very well suited for a lot of websites. You'll probably want to do the thin server (expose a REST API and your websocket endpoints) with a fatter client using something like BackBone.js to keep interactions clean.
The big win from doing the whole thing in node is that you will not have duplication of code between php and js for dealing with the DB or any other services required by both. Node.JS is also fantastic at handling tons and tons of concurrent requests.
Good Luck