First of all, i'd have two different repositories for backend and frontend, so that you can develop and deploy them separately.
Second, on Angular side i always put the api url in an environment variable so that i can create builds for different backend urls by just specifying --env=<environment_name>
I also create an APIService that prepends all the relative urls i use in the app with the api url of the current environment, and adds extra request data like authentication headers etc.
About packaging them together, if you mean to deploy them to the same domain i don't think that's an elegant solution, but it can work with some extra web server configuration
Deploying on the same domain is simple using sub-domains. An API Gateway can be configured to route each sub-domain (and even every request) to a different server or cluster. For example, serve the app directly on the default domain through a CDN like S3 and setup the "api." sub-domain as the service gateway which routes requests to a private network.
Yes indeed deploying to sub domains is the preferred method most of the times. When i said to avoid deploying them to the same domain i meant to avoid having a scenario where your app is served from the same web server that serves the api, like yourdomain.comfor the app and yourdomain.com/api for the api.
First of all, i'd have two different repositories for backend and frontend, so that you can develop and deploy them separately.
Second, on Angular side i always put the api url in an environment variable so that i can create builds for different backend urls by just specifying
--env=<environment_name>I also create an APIService that prepends all the relative urls i use in the app with the api url of the current environment, and adds extra request data like authentication headers etc.
About packaging them together, if you mean to deploy them to the same domain i don't think that's an elegant solution, but it can work with some extra web server configuration
Deploying on the same domain is simple using sub-domains. An API Gateway can be configured to route each sub-domain (and even every request) to a different server or cluster. For example, serve the app directly on the default domain through a CDN like S3 and setup the "api." sub-domain as the service gateway which routes requests to a private network.
Yes indeed deploying to sub domains is the preferred method most of the times. When i said to avoid deploying them to the same domain i meant to avoid having a scenario where your app is served from the same web server that serves the api, like
yourdomain.comfor the app andyourdomain.com/apifor the api.Yea, agreed. This would make scaling a hassle.