I am currently having two nginx servers and an AWS load balancer in front of them. The static content is served with nginx. Can I use nodejs for the application logic and routing. I dont want to use nginx as a reverse proxy.
You can create two target groups, one for each application.
Then use the AWS Application Load Balance to manage your requests.
In the Application Load Balance you must configure the listeners to forward the request to the correct target group.
Related
I'm currently developing a full-stack web application + mobile app. I've pushed my API backend (node.js express) to an AWS EC2 instance.
Now I'm looking to create the frontend with React. As well as a landing page which I think will be just plain HTML (or even WordPress if possible?) to get it running asap.
Questions are:
should I upload all 3 to the same instance? if so how?
can I point my domain in a way where mydomain.com - serves the landing page, api.mydomain.com serves the backend for requests, and app.mydomain.com serves the react app.
This solution is entirely upto you here, if this is a personal project or one with a tight budget then yes you can put all applications onto the same server.
If you have a HTML only application then you could deploy that specific application to Amazon S3 with a CloudFront distribution in front to provide CDN functionality.
If you do run the applications on your server then you will need to ensure that the web server can resolve each set application individually through hostname for example Nginx uses server_name to define the web domain name for that vhost.
I would suggest if you're running all on the same box run each node application on a seperate port, then use Nginx as a proxy based on the domain name. More information on how to set this up is available here.
Finally add DNS records to target the host IP (or CNAME if you use CloudFront).
I currently have an API backend deployed as a pod inside EKS which I exposed it through using ELB via kubernetes service, and an AngularJS frontend hosted in S3 delivered through Cloudfront, which calls the API.
Is there any way that I could have frontend and backend as domain.com and domain.com/api respectively with the current setup?
The only other way I could think of is not using Cloudfront to host the AngularJS frontend, but instead dockerize it and deploy as a pod in the same cluster as the backend API but I am just wondering if there is a way that I could use Cloudfront (or any other services or ways) to do some kind path-based proxying to decide which end it should redirect.
Thanks in advance.
DNS records work with domains and subdomains but not paths. This means for /api to be interpreted and routed you need a proxy server or an ingress in Kubernetes case.
A simpler approach would be to use api.domain.com and domain.com then create separate A records pointing to your backend and CDN/S3 bucket, respectively.
If you swap the hosting of your AngularJS frontend from S3 to a Nginx container in EKS you can run your frontend and API behind an ingress controller. You can then target the load balancer created for the ingress from CloudFront with a single DNS record.
Note - You will need to configure the cache settings on your API otherwise CloudFront will cache the API output.
I set up an Application Load Balancer(AWS) for my website. In my website, I have angular as my frontend, and I have NodeJs and Neptune DB as my backend.
Browser(Local Machine) -> ALB -> EC2 Instance(Web).
I have an url for my web(https://example.com), so when I made a request to https://example.com in my local machine browser, Angular will do a api call using httpclient.get() to fetch data from nodejs at https://example.com/api/ticket.
So my question is when Angular fetch data from NodeJS, will the api call bypass the ALB, what is the host then? Or NodeJs will recognize the request is from the local?
I assume you are using an ALB with Host based routing. In this case you can have a 443 rule for example.com forwarding requests to the EC2 instance. Then in the Nodejs application you can have that api called using the same url.
This means that the request will be routed through the ALB which is also the best practise to do the same.
I have 3 database servers in Azure , I want to load balance between them , For application servers I am using application gateway.
Now I am not sure which one ( application gateway or traditional load balancer) should I use for load balancing database servers.
Can anyone clear my confusion?
Application Gateway is a Layer 7 load balancer, which means it only works with web traffic (HTTP, HTTPS, WebSocket, and HTTP/2).
I believe a database server would expose a TCP endpoint, but not a web endpoint.
For this reason, you would need a traditional load balancer, which works on Layer 4.
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-faq#how-do-application-gateway-and-azure-load-balancer-differ
Currently I am using aws ec2 instance to host my backend and frontend . Backend is in nodeJs and frontend is in angular. ALso using route 53 for routing . and bought domain from goDaddy.
I have used following steps for hosting.
for backend :
clone my backend files on ec2 instance.
run backend nodejs program using pm2(used to run nodejs in background)
used nginx as reverse proxy to point localhost to my sub domain.
for frontend:
cloned frontend production files on ec2 instance.
used nginx to point frontend file to my main domain.
Now nginx is little bit complex to handle for me. Is there any way to avoid nginx or to host though any other way ?
Thank you for your time.
If your frontend app uses angular, then presumably it's a 'Single Page App' that is only dynamic in the sense that it makes some kind HTTP calls to an (RESTful?) API provided by your nodeJS application.
If this is the case, then you can host the built version of the angular app in a public S3 bucket configured as a 'static' site, which will still be able to communicate with your backend via angular's HttpClient. You can use Route53 to point your bought domain at the bucket's index.html file, and also set up a CloudFront distribution if desired.
Your nodeJS app will continue to live on the EC2 instance, although you could consider either using Elastic Beanstalk to deploy the backend app for you, or at least setting up yourself a load-balancer and autoscaling group to give you fault tolerance and availability for the backend.