I've an angularjs project with an express 4 backend, both hosted in one cloud9-ide workspace. The node backend is running under process.env.IP (0.0.0.0) and process.env.PORT (8080). The Angular Project is living under a 'client' subfolder needs access to the backend within the workspace. The Angular App needs it's own port - right? How can I accomplish this task?
Thank you for helping me out, Günther
I'm not entirely sure what an 'angular project' means. From what I know from Angular it is more common to run Angular code on the client. This is probably why it is in a folder called 'client'.
If this is the case then express will serve the angular files to the client over the port specified. Angular will run in the browser and do all it's magic there.
If this is the case the answer to your question would be that you don't need another port and all should work as you've set it up.
Do note that Cloud9 only supports 1 port that is accessible from the outside. For most express + angular apps this is all you need.
Related
I'm coming into an existing application where a single React application exists that calls multiple APIs. The APIs are written in .NET Core and I've been instructed they are typically hosted with IIS Express when debugging locally.
Where I'm running into trouble is understanding how the React application will hit the backend API projects, when the API projects are running on multiple IIS Express instances that don't have static ports.
For instance, I'll hit "run" on the React project which launches the React application along with a controller that might be running on localhost:5888. I can easily hit the controller from the React application using window.host + /Controller/ which will handle resolving the port for me. However, if I "run" another API, from a separate Visual Studio instance, it'll get hosted on a random port, something like localhost:5889. If I try to hit that API with window.host + /SecondAPIMethod/ from the React application, it'll come up with a 404 error, because the React app doesn't know what port the IIS express instance with the second API is running on.
I've been told by coworkers that Swagger is the key to managing this, but I'm unsure how.
It is not running on any random port. Port number is specified in the project properties. When you are debugging in visual studio, you can set the port number by going to project properties -> debug -> App URL.
When you deploy the web api on IIS Server, it will run on the port you have specified when configuring the web api.
Now when you know the web api (with port number) in advance, you can hard-code the url or put it in app settings file of your react app. Hope this helps.
I pulled a project from github and it works fine for me.
However, I want just to know how to separate server side and client side projects (sockets part).
In other way, how can I run the two projects (angular project and express project) into two differents servers (for example angular project on localhost:8080 and express project on localhost:3000).
That's gonna help me also to use this code into ionic framework project :)
Solved !
1) in index.html I must call the socket.io file on my server :
<script src="http://localhost:8080/socket.io/socket.io.js"></script>
2) in components/socket.Srvc.js
var socket = io.connect('http://localhost:8080');
backend server port : 8080
Now I can run separately two servers without socket.io errors :)
I am currently working on an Angular website that communicates with a RESTful API running on node.js that I built only for this app. They are two separate projects that runs on different ports.
While developing, I make the Angular app communicating with the local API. In production, the path to the API will be the IP address of the server. This is not a lot of work but I then need to change the address every time I want to deploy to production.
So here is some questions (sorry if this is a duplicate, I couldn't find it) :
Is it possible to create a two-sided variable (in grunt, in angular) in order to use some address (localhost) for development and another address for production ?
Maybe I got it all wrong and I should merge the API with the app ? I would have one big web server running on the same port and I could use relative paths and get rid of hostnames. How can I do to merge the express routes for the API with the angular routes ?
Thank you !
I have a client/server app running on NodeJS with an AngularJS frontend. I want to use the built in debugging features of Webstorm, but it just won't work.
Imagine following scenario:
I have a webstorm project with a client folder and a server folder. I can start the debuggers for the client and the server, and it works. But both sessions are on different ports. So an AJAX request to the server inside the client doesn't work without using CORS and telling AngularJS to use a different server address.
In the production version the client will be published under the server, but for developing there is no need to do this.
Does anyone know how achieve this? Something like: The system should behave like one server, under one URL.
Or is my approach stupid?
Best regards,
Kersten
Do i need to host my angular application on a node server for it to work?
I have been doing local development and am trying to integrate ui.router into my application but it does not seem to work because of the root/file/file/index.html file directory when running in the browser. Is that what is causing it or is it that I need to utilize these tools with a NodeJS server for them to cooperate.
Here is what I am doing with the ui.router
var app = angular.module("myapp",[
'ui.router'
]).config(function($stateProvider, $urlRouterProvider){
$stateProvider.state('login',{
url:'/login',
templateUrl:'views/login.html'
});
Solved the problem by just running the application on my server which resolved the ui.router problem.
You will need a server to run your Angular app, not necessarily a node server.
From https://docs.angularjs.org/tutorial/ :
While Angular applications are purely client-side code, and it is possible to open them in a web browser directly from the file system, it is better to serve them from a HTTP web server. In particular, for security reasons, most modern browsers will not allow JavaScript to make server requests if the page is loaded directly from the file system.