My backend is a simple dockerized Node.js express app deployed onto elastic beanstalk. It is exposed on port 80. It would be located somewhere like
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
I can call my APIs on the backend
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/hello
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/postSomeDataToMe
and they work! Yay.
The URL is not very user friendly so I was hoping to set up API gateway to allow to me simply forward API requests from
api.myapp.com/apiFamily/ to mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
so I can call api.myapp.com/apiFamily/hello or api.myapp.com/apiFamily/postMeSomeData
Unfortunately, I can't figure out (i) if I can do this (ii) how to actually do it.
Can anybody point me to a resource that explains clearly how to do this?
Thanks
Yes, you can do this. For this to happen you need two things:
a custom domain that you own and control, e.g. myapp.com.
a valid, public SSL certificate issued for that domain.
If you don't have them, and want to stay within AWS ecosystem, you can use Route53 to buy and manage your custom domain. For SSL you can use AWS ACM which will provide you with free SSL certificate for the domain.
AWS instructions on how to set it up all is:
Setting up custom domain names for REST APIs
Related
Google's CloudRun is capable of redirecting http to https without any configuration. I was not able to find any solution that would instruct CloudRun to respond 301 Permanent Redirect to all non-www requests.
I was able to instruct CloudRun to handle both www and non-www but without redirection.
I am familiar with how to set up the required logic with nginx and a traditional server. I could also do this in the application itself but since CloudRun is a serverless product, it would be better to handle this state before the app is even invoked.
Thank you.
When you reach Cloud Run, you first lands on GFE (Google Front End). This layer ensure the security (if you set your Cloud Run service in no-allow-authenticated mode, perform DDoS mitigation at Google grade, expose and manage the SSL certificates, route the request to the correct services,...). So, a lot of job for this layer but you can't customize it.
If you want to add customization, you have to add a new layer, a HTTPS Global Load Balancer. Now you can define serverless NEG backends to reach serverless product (Cloud Run, Cloud Functions, App Engine).
It doesn't offer as much as customization as a NGINX managed by yourselves, but you can perform more things.
I have two apps I wanted to have "fully managed" by Cloud Run. One is a pure Vue.js SPA and the other is the belonging backend server for it that is connected to a MySQL and also fetches some other API endpoints.
Now I have deployed both apps but am totally unaware on how I can give the frontend app access to the backend app. They should be both running on the same domain to avoid the frontend from.
Current URL of the frontend app: https://myapp-xl23p3zuiq-ew.a.run.app
So I'd love to have the server accessible by: https://myapp-xl23p3zuiq-ew.a.run.app/api
Is this somewhat possible to achieve with Cloud Run?
I was having the same issue. The general idea that one usually has is to use path mapping and map / to your client and /server to your backend. After googling for a while I found this:
https://cloud.google.com/run/docs/mapping-custom-domains
Base path mapping: not supported
The term base path refers to the URL
path name that is after the domain name. For example, users is the
base path of example.com/users. Cloud Run only allows you to map a
domain to /, not to a specific base path. So any path routing has to
be handled by using a router inside the service's container or by
using Firebase Hosting.
Option1:
I ended up creating an "all in one" docker image with an nginx as reverse proxy and the client (some static files) and server (in my case a python application powered by uwsgi).
If you are looking for inspiration, you can check out the public repository here: https://gitlab.com/psono/psono-combo
Opttion2:
An alternative would be to host your client on client.example.com, your server on server.example.com and then create a third docker run instance with a reverse proxy under example.com.
All requestes would be "proxied" to the client and server. Your users will only interact with example.com so CORS won't be an issue.
Option3:
Configure CORS, so people accessing example.com can also connect to server.example.com
Currently this is not possible in Cloud Run, as already said on the comments to your question.
You could check if there are any Feature Request for this functionality on Buganizer (Google Issue Tracker), currently there seems to be none, and if that is indeed the case, you can create a new Feature Request by changing the request type from Bug to Feature Request and as Google develops it on their road map, you will be informed.
Hope this helped you.
I use AWS Lambda as a backend service to authenticate users from my ios app. When learning about Lambda I was pointed to use the Amazon API Gateway to make the data over the network go over HTTPS:// and NOT HTTP://.
Someone recently pointed out that all calls to AWS Lambda, DynamoDB, S3, and Cognito directly from my app automatically go over HTTPS://. Is this true or not?
Unfortunately the docs are not explicit on the matter, that I could find, but inspecting the source on github:
AWSService, one of the base services used by the sdk, uses https by default, and will only switch to http if the AWSServiceConfiguration particular configuration is established with the parameter useUnsafeUrl set to true.
And AWSLambdaService, even if initialised with a configuration object, appears to set the useUnsafeUrl option to NO.
So - inspection of the source suggests that all access to the service is by default https.
This is consistent with AWS SDK defaults in other languages/frameworks as well.
-- Edited to note --
I had a thought after posting this - it's possible that the advice to use API Gateway for https was based on the common practice of exposing Lambda functions as API endpoints. If you want to do that, then API Gateway gives you a way, and if you are using API Gateway, then you do need to ensure it is configured to use https.
What is not clear from your question is - from your app, are you invoking the lambda functions via the API Gateway endpoint? Or directly via the AWS SDK? If invoking directly via the AWS SDK then there is no need to use API Gateway at all.
If you are already using the API Gateway, and issuing HTTPS web requests to invoke your lambda functions, I wouldn't necessarily stop, because it gives you a nice point of abstraction and decoupling - you could completely change your backend implementation and as long as you keep the API Gateway endpoint configuration the same, your clients will still work. Alternatively, you could start to implement other clients or expose your API to 3rd party clients who aren't in a position to use AWS SDK and they will still be able to interract with your backend via standard HTTP protocols.
I am calling a number of apis of a web service hosted on a number of servers. Requests get routed to these servers at random through a load balancer.
All these servers reside on my local network and I want one particular api call to go to one particular server.
Since I don't want other requests to get affected, I am unwilling to put a host entry on the server hosting my app.
Can this be achieved through code?
I am coding in ruby and using net-http gem to make api calls.
Any implementation using curb gem is also welcome.
Thanks
-Azitabh
I think the best way to achieve what you want is to use a proxy with DNS Spoofing.
Charles proxy does that but there might be other tools also.
One way(on the same lines as suggested by systho) I can think of is to make the api call directly using the IP and create a vhost on the server which is listening directly on a separate port.
This will work for me purely because of the fact that I have access to the servers hosting the web service.
I am starting to create a RESTful API that is built on Ruby on Rails. I would like my other applications (which are hosted on the same server) to be able to use this API. I had the idea that if the API is only available locally, I won't have to deal with the authentication logic since it won't be publicly accessible. I have never done this sort of thing before, so I don't even know if what I am asking for is possible (or if this is even a good idea).
How can I host this application so that my REST API is only locally accessible?
You can do one of the following:
Set the webserver to listen on loopback only
If you need to give access to the local network then configure your firewall to forward ports accordingly
Set the webserver to listen only on the private network interface (not public)