So I am creating a multiplatform application using React & Spring (Java)
I want to make the Spring backend a REST webservice that can be called by both a React-Native and a React frontend.
I currently have my project broken up into 3 sub projects: backend (Spring), webapp-frontend (React webapp), mobile-frontend (React native)
My question is on how I should actually serve the React webapp frontend. I will have the webservice on a server somewhere so that the React code can hit it to make API calls, but as far as serving the React webapp would it be better to do serve it with the same backend server or would it be better to make a seperate frontend server with something like express? Also, are there any other alternatives?
Serving the react webapp with either express or the same server as the REST backend is both valid options. I would say that if there is no specific reason for choosing express, serving it on the same server as the spring backend is your best choice.
Recall that the frontend and backend will still be decoupled and only communicate through the REST-interface so to extend the backend-server to host the react-webapp should be quite simple, here's an example that could be helful: React,Spring,Rest example
However there is a couple arguments that I see that could make you choose a separate server then the REST backend, for example:
Isolated restarts and failures. If you want to be able to restart only your react-frontend without affecting the REST backend you will probably want to run them on different servers. Another thing to consider is if you expect that the backend will need to scale heavily and you'll need to replicate the backend across multiple servers, that might be easier to do if the frontend is running on its own separate server.
Server-side rendering of JavaScript (React) is possible through a node.js server like express but I don't think it is possible with a Spring server.
Also, are there any other alternatives?
Other alternatives then express/Spring, Yes. Other alternatives then hosting the fronted on the backend-server or on its own server? No
There are pros and cons with both choices and what is best depends on your needs.
Related
I am currently in the process of creating a portfolio website for myself but due to hosting restrictions, I cannot make use of Node.js.
I know Angular can run on any web server, but is it possible to make use of Express.js to create web api's with relying on Node.js to run these web api's using Express.js?
If not, is there an alternative solution to create web api's that I can call using Angular and later for my mobile version of my website?
Please note that my shared hosting runs using cPanel.
As per definition Express.js, or simply Express, is a web application framework for Node.js so you can't do that. Alternatives would be to use a different backend language.
That also depends if your server supports them, for example, you can go with .NET CORE
You cannot use Express without NodeJS by definition so you have to deploy your backend somewhere else in you want to use it.
I suggest giving a look Firebase: you could write your backend using http cloud functions in express without paying anything until a reasonable amount of traffic (after that, is pretty cheap). You could also get rid of cPanel and deploy your frontend there via Firebase hosting.
Maybe you can try to build at first a web application with express. Of course you can create a web app without express if you need it. With express and Node.js I created a MySQL REST API. With HTML and Ajax you can fetch the Data from the API. So you can create two applications. One application where you need to run Node.js because it`s much easier to create a REST API with express. The second one is fully without Node.js.
Maybe there are better solutions, but inside each Web Application you can than but you can then access this API in any web application using jQuery. It doesn't matter if it is written with PHP, ASP.Net Core, Java EE / EE4J. You can also access this API in Ruby, Angular, React, Vue etc. using an AJAX request.
In some scenarios you can't start Node.js as a server because an application is already running on apache2 or nginx. There this would be a workaround to use something like this. For example, one could also integrate applications with HTML+JS in a CMS system that accesses other database tables and thus extend such a system without an iframe.
So can be helpful for few scenarios. Now just doesn't get around the actual goal of doing without Node.js completely or even express. But why are there REST APIs? So that you can query the data and incorporate it somewhere else. Otherwise you would have to build a REST API with another technology. Especially in the example of accessing MySQL with JavaScript, this would not be quickly feasible.
If you are looking for a similar solution to separate the web app and the REST API, but you don't need Node.js, then you should really build a REST API with .Net Core or with another technology, depending on what is possible and installed on your server. It could be Java or PHP behind it or Ruby.
The API that provides the REST access does not have to be written in JavaScript. You only need to be able to access it with JavaScript. So you can use many different approaches to access JSON data. I hope that in the short time with my bad English I have explained the basic idea, how to proceed stylistically and where advantages exist in REST interfaces.
With this, it should be self-explanatory that you don't have to use NodeJS and Express, but with JavaScript it's a pleasant solution. Only you have to ask yourself if a JavaScript application has to provide this interface at all or if in the end only a JavaScript application has to access this interface. Very big difference.
For backend rest api you can use golang with gorilla framework. Golang simple keyword and easy to learn.best important point is performance. If your server support golang you can use golang for backend..
ExpressJS is NodeJS framework so it's impossible to create an API without NodeJS.
Angular is front-end framework so you can host it on web hosting server.
If you need to create back-end APIs, you can use other clouding host servers that support NodeJS.
It's fairly simple to build this with just the net/http package. Set up a router that handles various commands and deal with the response accordingly.
I am quite new to javascript and web application environment. I have seen a react web application project which had a public directory, a client directory and a server directory. I have few question
Why do we need an express server file setup in the frontend project if we already have backend APIs ready and backend server ready
Do we need an express server if we make the frontend on react and call the APIs to fetch the data for application.
Isn't the backend server and express server in the frontend project are same?
Why do we need an express server file setup in the frontend project if we already have backend APIs ready and backend server ready
You don't.
You need an HTTP server to listen for and respond to any Ajax requests you make from your client side code.
You need an HTTP server to listen for and respond to any requests for the HTML documents and static resources (JS, CSS, images, etc) that your pages need.
These can be the same HTTP server, different HTTP servers, written with Express or not written with Express.
React tutorials tend to ignore mentioning this and just dive in showing how to use Express for everything. Don't read too much into that.
Do we need an express server if we make the frontend on react and call the APIs to fetch the data for application.
No. See above.
Isn't the backend server and express server in the frontend project are same?
Maybe. It is up to you. See above.
There is no such thing as a "backend server" and a "frontend server", a simple web application is composed of two main parts:
1/ an application that serves html pages, which runs on a backend, so it is usually called a server, but a typical cloud server nowadays can run hundreds of different serving apps at the same time
2/ a frontend, which is typically a complex piece of JavaScript software and html pages that are dynamically send to the user browser and execute locally
The minimum that you require to have a working website is a server application that will return one or several html pages upon user request. A typical React + Node project is organized as follow:
A server directory: which contains all the code for the serving app - the one returning the webpages, it can also contains code that handle the REST API, in case your client app requires dynamic data or if your server connect to a database. Note that the webpage server and the API server could be two different- or more - applications.
You usually dont want to share to users your server code, so typically you have a public directory that contains the html pages and this is the only location on the disk - theoretically - that can be access by users. This directory can also contains required images and resources needed by the webpages, it is also called static resources
To keep thing more organized, the code of the frontend application is placed in a client directory but on production is usually bundled in one or few files, depending on the size of the app, and also placed in the public directory, so it contains everything needed to serve the app.
Hope it helps
We don't need an Express server, however, adding it comes with great benefits:
It helps add compression to an angular / react application that uses only in-memory server (if that is your case).
Defines base path where to serve static files for your project and can also add gzip compression headers for each of the request so that the server returns the compressed versions.
Helps you parse your API calls to the correct format expected by the UI so that the parsing logic stays in the express server and not the UI. This is helpful in the event that the API response changes in the future, or when the final backend endpoint changes, no need to modify the UI, but the route in the express server.
I have found out these and other benefits while looking how to add compression to an angular application (turns out you cannot without express or an actual web server).
I've developed a web application using React and Redux and then packed it with Webpack, it's hosted using IIS and presumably just runs client-side and makes calls to a Web API (.net for reasons); also hosted on IIS.
How do I make the jump and make this application 'isomorphic' so that the React code runs both client and server side?
You'll need a few things:
1) some way to run node: Really the only things that happen server-side with React are a renderToString call to give you strinigfied HTML you can send to clients (it's just a static HTML rendering of your app w/ React), hydration (see more on that in a bit) to get data into your components, and route-matching.
2) a router (if you have routes): If your app uses multiple routes, you'll need to use React-router to tell node what component(s) should be rendered
3) a good reason to go universal: there are some relatively simple aspects to going universal and there are some relatively complicated ones. Matching the routes isn't all that hard, and it will essentially just be you telling your server what to send down. The harder, more complicated part of universal JS w/ React is fetching data to send down to clients on initial render. This usually involves some server-side data fetching, so you have to have a way to both get the data and pass it into your app to be rendered correctly. There are ways to do this, but it is certainly a significant step up in terms of overall complexity.
This is how I did it, w/o the need for any server-side data fetching: Server side rendering with react, react-router, and express
See also:
https://ifelse.io/2015/08/27/server-side-rendering-with-react-and-react-router/
http://jamesknelson.com/universal-react-youre-doing-it-wrong/
You need Node.js to make an isomorphic web app.
This is because an isomorphic application requires an appropriate server-side runtime to execute the React Javascript code on the server. I don't believe IIS has support for parsing Javascript exactly - only Node has this runtime.
If you aren't using Node, then you should introduce it at some stage in your application. You can use IIS as a reverse proxy: create a Node server for IIS to forward requests to, let Node render the React as static HTML using renderString, and then have Node respond to requests from IIS with the rendered HTML. IIS will act as middleman for all incoming requests and responses.
Reverse proxies add some minor latency to an application, but, as always, premature optimisation is the root of all evil.
is there a possibility to only use the frontend part of meteor and serve the files via a static vanish server?
I want to build a web app which uses an existing PHP REST API, but I lice the reactivity and the tempting of meteor, which I can get with the Session variable.
If there is a simple way to separate the frontend parts from the back so that I can easily serve them, would be awesome. Especially the web socket is not needed. Because there will be no after connection to the deliver server.
This cannot be done. For meteor to get live updates you need a connection to a server of some sort to relay the message down.
There are a couple of methods you could use, however
If you like the DOM reactivity and all the data is locally hosted/you would like to fetch it from php would like to use it in a static application something like angular or react could help you.
The other is you could use a deployed instance of an application & have it stored on a static/varnish server. But use DDP to have the server relay data. See http://arunoda.me/blog/hosting-meteor-apps-as-a-client.html
One of my team members is working only on client-side (Javascript) development for a web app with a large and complex backend.
I would like to avoid the need for him install and configure a local copy of the backend.
However, I wouldn't want him to need to push every small change to the dev server just so that he can test it.
We thought about getting the client to make the requests directly to the dev server, instead of to the same domain (the localhost) but this doesn't seem practical due to cross-domain request policies and authentication problems (cookies aren't getting sent).
What are some elegant solutions for developing clients without having a local backend?
Depending on how complicated your backend is, you might be able to create a mock backend using a lightweight web framework like Sinatra. I've had some success with this technique, but the services I've been mocking have been fairly simple. In some cases the mock backend mostly serves static JSON files.
I use Charles Proxy to map the URIs of the dev server's web services to localhost (where I run a light weight web server that serves up my static development code).