How can I use my own domain when hosting on vapor cloud?
I have never written an API before and just started playing around with Vapor, I purchased a domain from godaddy and would like my API to use that for my routes instead of the domain Vapor is creating ex "appname.vapor.cloud"
Have a look at the docs for adding your custom domain to Vapor Cloud - https://docs.vapor.cloud/custom-domain/add-domain/
Related
On version updates the appspot domain may change for Composer environments. Is it possible to get something static to point a domain to?
Currently, adding custom domain and SSL to Airflow is still not possible in Composer. You can follow the progress of this on the feature request report here.
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 am new to backend world, currently I am very confused with these concept relationships and really need some help here.
So currently I already have an iOS app and backend server(using python, hosting at AWS) ready. Now I need to register a new domain name and build a basic website to explain and promote my app.
Let's assume I am using goDaddy to register a domain name as "hello.com", now I have my basic website ready as well, I guess I need to upload html files to goDaddy hosting server then the website should be able to run, but then how can I link it to our python server?
For example, in the iOS code when I am sending a http request, I will need to send it to "https://hello.com/api/xxx", correct? Please correct me if I am wrong.
You should use subdomains for the different servers:
www.hello.com = your static website hosted on Godaddy or wherever
api.hello.com = your Python api server
etc...
To make this work you would just edit your DNS zone on Godaddy (or wherever you have your domain hosted) and create a record for "www" that points to your website server and a record for "api" that points to your API server.
My web database server is being moved from the DMZ to the company LAN (don't ask why!). The downside of this is that my MVC 4 website is now gonna have to talk to an app server with web services (or web api) to get to the database. This isn't a major headache for most of my stuff, but I'm using the SimpleMembershipProvider for user authentication and that seems to need direct access to the database.
Is there any way to get SimpleMembership to talk to a web service or do I have to use a custom membership provider instead ?
I'm faced with the same situation, and while I haven't written or tested the code yet, I'll be writing a class to inherit from SimpleMembershipProvider and overriding the methods to call methods from the service (web api).
Is this the approach you ended up using?
Imagine two Grails applications which share a domain class. Maybe a Book domain class.
One application is identified as the owner of the data, one will have to access the domain data. Something like amazon and the amazon web services.
I guess it is trivial that the owning application will use a normal domain class and will expose the data through web services - no problem in grails.
But what would be best practice to implement the domain in the other application?
use a service to access the remote domain and not implement a local domain class at all?
implement a local domain class, overwrite the get()-method in order to fetch the remote data and use the local database as cache?
what other solution comes to your mind?
Ryan Geyer has a very interesting article Modularizing your Grails application domain classes which lists 3 solutions to this problem:
As a RESTful JSON Service - easy to get this setup in Grails but then you lose the automatic GORM functionality.
Separate out the domain classes into a library JAR file and reference that library in both of my other applications. This is not as easy as it first sounds
Create a Grails plugin. Put the domain object in the plugin. Each of your applications can then import this plugin. You can then create different controllers with different functionality as required. The sample code for this is available at:
git clone git://ec2.nslms.com/grails/blog_example_modular
Ted Naleid gives a great tip later in the post and recommends...
"create a grails-app/conf/BuildConfig.groovy file and put the plugin name and path to the source in it. ... If you do this, your applications will see the live changes to your domain/controller/service/etc classes as if they were actually in current app and there isn't any need to repackage and reinstall the plugin when you make changes."
Using memcache should enable both applications to have a consistent view of the data and would avoid each individual application having it's own inconsistent cache.
I think you can make JAR file of your domain classes and add reference to other grails application .
Found another interesting solution:
Riak is a key/value database with a first class REST API. There is a grails plugin for riak which maps most of the GORM functionality (relations, dynamic finders etc) to the REST API of riak: http://grails.org/plugin/riak
Now comes the part which I haven't tested yet: if you make use of the DataSources feature of grails 2.0, it should be possible to only connect those "remote" domains to a riak database.
As a result, there would be a domain stored in a riak database and several applications would be able to access it via a clean REST API without effort.
OK. This also show how silly my question is - it would be the same if you connect several apps through the same SQL-database. But sometimes people want to have something more funky like webservices.