How does the react client connect to the server via express? Many tutorials talk about Superagent and axios which is adding to my confusion. Are there any resources on server side routing in the context of react? thank you
In MERN stack, you do not necessarily have to think of the entire stack as a single entity. Mongo, ReactJS and NodeJS server can all work independently. And let us for easiness of understanding sake say all of them are on separate servers. That is we can have Mongo on one server, ReactJS on another server and NodeJS with express on a third server, then also it will be a MERN stack app.
How a MERN app work is as follows
For example, let us have an app that displays the details of all the students in a class. First, in the React app let us say you select a class, and then the React front-end will send a query to the nodejs server. The query will contain the particular class name. Now nodejs will send a query to the mongo db asking for the details of the students of that class which it will send back to the node server. The node server will then send the details to the front end and it will update it.
If you ask for connection as such, there can be no connection at all except for querying for data. Instead of using the reactjs front end you can use some other frontend and it will give you the same details. React, Mongo and Node, all are capable of working on their own in their respective fields.
Axios is a promise based HTTP client for the browser and node.js.
They are completely independent. Whether using axios, the native Javascript fetch, jQuery AJAX, etc...each of them runs in the browser and makes a GET/POST request to nodejs. You will have defined corresponding GET/POST routes within nodejs to respond to these requests and return JSON response data for them to consume.
I would start by forgetting about react altogether. Instead build an express API with various GET/POST routes that return JSON responses. Test with a simple client like postman. Once you have a handle on that, then start with a front-end Javascript framework to consume these services.
Here is a cut of my express+react api:
var express = require('express');
var router = express.Router();
router.get('/', function (req, res) {
res.render('index', {myjson: "myValue"});
})
module.exports = router;
Basically I am sending the json string to index.jsx, where the frontend is rendered.
Also I've set in express as:
app.set('views', __dirname + '/views');
app.set('view engine', 'jsx');
app.engine('jsx', reactViews.createEngine());
So the express server knows where React is.
Checkout the npm package Express-react-engine.
All the elements of the stack can be used independently, React , Node.Js, and MongoDB.
They can be installed in different servers and the communication is by using Fetch, Axios or any other tool.
Related
Despite knowing JavaScript quite well, I'm confused what exactly these three projects in Node.js ecosystem do. Is it something like Rails' Rack? Can someone please explain?
[Update: As of its 4.0 release, Express no longer uses Connect. However, Express is still compatible with middleware written for Connect. My original answer is below.]
I'm glad you asked about this, because it's definitely a common point of confusion for folks looking at Node.js. Here's my best shot at explaining it:
Node.js itself offers an http module, whose createServer method returns an object that you can use to respond to HTTP requests. That object inherits the http.Server prototype.
Connect also offers a createServer method, which returns an object that inherits an extended version of http.Server. Connect's extensions are mainly there to make it easy to plug in middleware. That's why Connect describes itself as a "middleware framework," and is often analogized to Ruby's Rack.
Express does to Connect what Connect does to the http module: It offers a createServer method that extends Connect's Server prototype. So all of the functionality of Connect is there, plus view rendering and a handy DSL for describing routes. Ruby's Sinatra is a good analogy.
Then there are other frameworks that go even further and extend Express! Zappa, for instance, which integrates support for CoffeeScript, server-side jQuery, and testing.
Here's a concrete example of what's meant by "middleware": Out of the box, none of the above serves static files for you. But just throw in connect.static (a middleware that comes with Connect), configured to point to a directory, and your server will provide access to the files in that directory. Note that Express provides Connect's middlewares also; express.static is the same as connect.static. (Both were known as staticProvider until recently.)
My impression is that most "real" Node.js apps are being developed with Express these days; the features it adds are extremely useful, and all of the lower-level functionality is still there if you want it.
The accepted answer is really old (and now wrong). Here's the information (with source) based on the current version of Connect (3.0) / Express (4.0).
What Node.js comes with
http / https createServer which simply takes a callback(req,res) e.g.
var server = http.createServer(function (request, response) {
// respond
response.write('hello client!');
response.end();
});
server.listen(3000);
What connect adds
Middleware is basically any software that sits between your application code and some low level API. Connect extends the built-in HTTP server functionality and adds a plugin framework. The plugins act as middleware and hence connect is a middleware framework
The way it does that is pretty simple (and in fact the code is really short!). As soon as you call var connect = require('connect'); var app = connect(); you get a function app that can:
Can handle a request and return a response. This is because you basically get this function
Has a member function .use (source) to manage plugins (that comes from here because of this simple line of code).
Because of 1.) you can do the following :
var app = connect();
// Register with http
http.createServer(app)
.listen(3000);
Combine with 2.) and you get:
var connect = require('connect');
// Create a connect dispatcher
var app = connect()
// register a middleware
.use(function (req, res, next) { next(); });
// Register with http
http.createServer(app)
.listen(3000);
Connect provides a utility function to register itself with http so that you don't need to make the call to http.createServer(app). Its called listen and the code simply creates a new http server, register's connect as the callback and forwards the arguments to http.listen. From source
app.listen = function(){
var server = http.createServer(this);
return server.listen.apply(server, arguments);
};
So, you can do:
var connect = require('connect');
// Create a connect dispatcher and register with http
var app = connect()
.listen(3000);
console.log('server running on port 3000');
It's still your good old http.createServer with a plugin framework on top.
What ExpressJS adds
ExpressJS and connect are parallel projects. Connect is just a middleware framework, with a nice use function. Express does not depend on Connect (see package.json). However it does the everything that connect does i.e:
Can be registered with createServer like connect since it too is just a function that can take a req/res pair (source).
A use function to register middleware.
A utility listen function to register itself with http
In addition to what connect provides (which express duplicates), it has a bunch of more features. e.g.
Has view engine support.
Has top level verbs (get/post etc.) for its router.
Has application settings support.
The middleware is shared
The use function of ExpressJS and connect is compatible and therefore the middleware is shared. Both are middleware frameworks, express just has more than a simple middleware framework.
Which one should you use?
My opinion: you are informed enough ^based on above^ to make your own choice.
Use http.createServer if you are creating something like connect / expressjs from scratch.
Use connect if you are authoring middleware, testing protocols etc. since it is a nice abstraction on top of http.createServer
Use ExpressJS if you are authoring websites.
Most people should just use ExpressJS.
What's wrong about the accepted answer
These might have been true as some point in time, but wrong now:
that inherits an extended version of http.Server
Wrong. It doesn't extend it and as you have seen ... uses it
Express does to Connect what Connect does to the http module
Express 4.0 doesn't even depend on connect. see the current package.json dependencies section
node.js
Node.js is a javascript motor for the server side.
In addition to all the js capabilities, it includes networking capabilities (like HTTP), and access to the file system.
This is different from client-side js where the networking tasks are monopolized by the browser, and access to the file system is forbidden for security reasons.
node.js as a web server: express
Something that runs in the server, understands HTTP and can access files sounds like a web server. But it isn't one.
To make node.js behave like a web server one has to program it: handle the incoming HTTP requests and provide the appropriate responses.
This is what Express does: it's the implementation of a web server in js.
Thus, implementing a web site is like configuring Express routes, and programming the site's specific features.
Middleware and Connect
Serving pages involves a number of tasks. Many of those tasks are well known and very common, so node's Connect module (one of the many modules available to run under node) implements those tasks.
See the current impressing offering:
logger request logger with custom format support
csrf Cross-site request forgery protection
compress Gzip compression middleware
basicAuth basic http authentication
bodyParser extensible request body parser
json application/json parser
urlencoded application/x-www-form-urlencoded parser
multipart multipart/form-data parser
timeout request timeouts
cookieParser cookie parser
session session management support with bundled MemoryStore
cookieSession cookie-based session support
methodOverride faux HTTP method support
responseTime calculates response-time and exposes via X-Response-Time
staticCache memory cache layer for the static() middleware
static streaming static file server supporting Range and more
directory directory listing middleware
vhost virtual host sub-domain mapping middleware
favicon efficient favicon server (with default icon)
limit limit the bytesize of request bodies
query automatic querystring parser, populating req.query
errorHandler flexible error handler
Connect is the framework and through it you can pick the (sub)modules you need.
The Contrib Middleware page enumerates a long list of additional middlewares.
Express itself comes with the most common Connect middlewares.
What to do?
Install node.js.
Node comes with npm, the node package manager.
The command npm install -g express will download and install express globally (check the express guide).
Running express foo in a command line (not in node) will create a ready-to-run application named foo. Change to its (newly created) directory and run it with node with the command node <appname>, then open http://localhost:3000 and see.
Now you are in.
Connect offers a "higher level" APIs for common HTTP server functionality like session management, authentication, logging and more. Express is built on top of Connect with advanced (Sinatra like) functionality.
Node.js itself offers an HTTP module, whose createServer method returns an object that you can use to respond to HTTP requests. That object inherits the http.Server prototype.
Related information, especially if you are using NTVS for working with the Visual Studio IDE. The NTVS adds both NodeJS and Express tools, scaffolding, project templates to Visual Studio 2012, 2013.
Also, the verbiage that calls ExpressJS or Connect as a "WebServer" is incorrect. You can create a basic WebServer with or without them. A basic NodeJS program can also use the http module to handle http requests, Thus becoming a rudimentary web server.
middleware as the name suggests actually middleware is sit between middle.. middle of what? middle of request and response..how request,response,express server sit in express app
in this picture you can see requests are coming from client then the express server server serves those requests.. then lets dig deeper.. actually we can divide this whole express server's whole task in to small seperate tasks like in this way.
how middleware sit between request and response small chunk of server parts doing some particular task and passed request to next one.. finally doing all the tasks response has been made..
all middle ware can access request object,response object and next function of request response cycle..
this is good example for explaining middleware in express youtube video for middleware
The stupid simple answer
Connect and Express are web servers for nodejs. Unlike Apache and IIS, they can both use the same modules, referred to as "middleware".
I saw a lot of ways to connect React frontend to express backend (REST API) and i don't understand which one of the them is the most common, organized and friendly. (Axios, componentDidMount function and so on..).
My project divide to backend and frontend libraries which includes a connection to mongoDB in the backend.
I am new to React so i will appreciate any recommendation.
You can easily have both on the same server, all you need to do is. Make an express route that servers your react app's index.html.
app.get('/', (req, res) => {
res.sendFile('./public/index.html');
});
Also, don't forget to serve your static files (css, fonts, etc) using express's own middleware.
app.use(express.static('public'));
After you have done that, you can have your API at /api.
We use axios for http requests such as get, post, etc.
We use express for the same purpose also.
However according to what I read, they are for different purposes.
Please explain how.
PS: If you explain it by giving an example, it would be great!
You can think of express.js as a warehouse:
app.get('/item/:name', async function (req, res) {
res.send(await findItemByName(req.params.name));
});
If you want to get an item, for example a pencil, from this warehouse, you can use axios.js.
axios.get('/item/pencil')
Axios is used to send a web request whereas express is used to listen and serve these web requests.
In simple words, express is used to respond to the web requests sent by axios.
If you know about the fetch() method in javascript, axios is just an alternative to fetch().
I would say that express is used to create HTTP servers. So the server runs somewhere and responds to a request.
Axios is an HTTP client. It creates requests!
In very simple words axios is just passing the web request to the server-side (express). They basically work together (axios -> express -> DB)
I need to query a database and I'm using create-react-app. The library to connect to the DB (pg-promise) does not work with Webpack and needs to be running on a Node server.
So I installed Express and have this:
app.get('*', (req, res) => {
res.sendFile(path.resolve(__dirname, '..', 'build', 'index.html'));
})
How can I load data from the database from the React pages? I though of using request but how can I make a request to my own server? And what should I add to the lines of code above? I think it would be something like:
app.get('/query/:querybody', (req, res) => {
// process and return query
})
Is this right? How can I make it work with a SPA?
Probably the most friction-free method would be to have a separate app.js or server.js along side your CRA application. You can use a tool like concurrently to run both your React app and the express app.
The trick is to serve your express app on a different port than the default :8080 that CRA serves on. Usually 8081 is a good choice, as it's a common convention to use port numbers that are close together when developing.
In your React app, you will need to make sure you use the full URL for the express endpoint: http://localhost:8081/query/...
On the server side you are going in the correct direction: you need to setup endpoint which will respond with data based on request. In you example you setup an endpoint for a GET HTTP request. If you will need to pass a complex request (for example add new record to database), consider using POST HTTP requests.
On the client side (in the browser) you will need a library that will assist you in sending requests to your server. I can recommend to try Axios (https://github.com/mzabriskie/axios). Usually if you omit protocol, server name and port, request will be sent to the server from which the page was loaded:
http:127.0.0.1:8001/api/endpoint => /api/endpoint
I'm new to Sails, but have used Express, and am considering Sails for my upcoming project. I particularly like that it makes the CRUD API for me and connects Socket.io automatically.
The next application I'm planning to work on has an indeterminate size; if it works well, we want to separate our CRUD/JSON API from our Web/HTTP server and load balance the Web/HTTP server. This would allow us to utilize the CRUD/JSON API in other adjacent applications, like code for statistical analysis, or external data parsers which import data, or other things which have nothing to do with Web/HTTP servicing.
In express I would consider making the API section a module then export the express.router with all the api calls like so
//appAPI.js
var routes = require('express').router();
routes.get('/user/:id', function(request, reply){
// assume db is connected database object
// and request.params.id is as expected
db.getUser(request.params.id, function(u){
reply.json(u);
});
})
module.exports = routes;
//app.js
var app = require('express')(),
api = require('appAPI');
app.use('/api', api);
Then in my application, if I want to separate the Web from the API, I can package up the appAPI.js, and associated model code, and make a small connector to redirect all routes /api/* to the ip address and port of the api server, or other possibilities.
Can I do something like this in Sails? It seems that the automated model creation and the socket.io automation would make this difficult. Alternatively, I might be able to make a module for the API with a whole sails server then embed it in the main Web/HTTP server, which has its own sails objects running, but this seems like it either would not work, break the socket.io connections, or work, but be horribly inefficient as it would have multiple instances of sails running.
Any recommendations would be helpful and I'm willing to consider alternative ways of working this. Thank you all for any help you might provide and have a wonderful day.