I'm currently developing a simple webapp with seperated frontend (Vue) and backend (quarkus REST API) project. For now, I've setup a MVP, where the frontend is displaying some simple data which is called from the backend. To get a working MVP i need to setup CORS support. However, first i want to explain my setup:
Setup
I'm starting developing environment of my frontend with npm run serve and of my backend with ./mvnw quarkus:dev. Frontend is running on localhost:8081 and backend running on localhost:8080.
Heroku allows to run your apps locally aswell with the command heroku local web. Frontend is running on port 0.0.0.0:5001 and backend on 0.0.0.0:5000.
To achieve this setup i setup two .env files on my frontend which are pointing to my backend api. If i want to work in development mode the file .env.development is loaded:
VUE_APP_ROOT_API=http://localhost:8080
and if i run heroku local web the file .env.local with
VUE_APP_ROOT_API=0.0.0.0:5000
is loaded.
In my backend I've set
quarkus.http.cors=true
in my application.properties.
Now I want to deploy those two projects to heroku and use it in production. Therefore I setup two heroku projects and set a config variable in my frontend project with the following value:
VUE_APP_ROOT_API:https://mybackend.herokuapp.com
Calls from my frontend are successfully working!
Question
For the next step, I want to restrict it more and just enable my frontend to call my API. I know i can set something like
quarkus.http.cors.origins=myfrontend.herokuapp.com
However, I dont know how i could do this on quarkus with different environments (development, local and production)? I've found this link but I don't know how to configure heroku and my backend app correctly. Do i need to setup different profiles which are applied on my different environments? Or is there another solution? Do i need Herokus Config Variables?
Thanks for the help so far!
quarkus.http.cors.origins is overridable at runtime so you have several possibilities.
You could use a profile and have everything set up in your application.properties with %prod.quarkus.http.cors.origins=.... Then you either use -Dquarkus.profile=prod when launching your application or you use QUARKUS_PROFILE=prod as an environment variable.
Another option is to use an environment variable for quarkus.http.cors.origins. That would be QUARKUS_HTTP_CORS_ORIGINS=....
My recommendation would be to use a profile. That way you can safely check that all your configuration is consistent at a glance.
Related
I'm playing around with the new Cloudflare Functions functionality, specifically the file based routing. However I've found it tiresome to have to deploy and debug my functions in the cloud
I found this, which seems to say I can use Wrangler to connect to the Cloudfalre network and run functions locally:
https://developers.cloudflare.com/pages/platform/functions/#develop-and-preview-locally
But it keeps asking me for a root worker file: but there is no root file, its file based routing.
How do I get Cloudsflare Functions to work with wrangler local dev or miniflare?
I'm trying to figure out a way to have one repository that is my front-end code pulled into another repository that houses my application code. Both of these repos are hosted by Azure Dev Ops, however they are under different accounts (if that matters).
I have followed the directions I found on Microsoft's site for setting up the .npmrc file on my development machine, but I'm getting lost at how to structure my URL on the application site to pull in my front-end code package.
Everything I've tried has given me a authentication error so I must be missing something.
According your statements, I noticed that you need to pull the front-end code into your application code repository. Since these two repos are under different accounts and hosted by Azure Dev Ops.
We recommend you can try to Import the front-end code repository to your application code project. And then we can refer the doc: Check out multiple repositories in your pipeline.
Here are the detail steps:
Go to your front-end code repos and use the admin account to create a new PAT with full access.
Go to the application code project, then use the ‘Import repository’
Create a new pipeline and check out the both repos.
And for the authentication error, you can try to use the npm Authenticate task in your pipeline.
in a current project I have a problem understanding (and configuring) routing within my vue.js app.
Our Setup
We have a setup, where for each Pull Request in our repos a new Snapshot Environment is created. This environment is one namespace within a kubernetes Cluster. All services in a current develop state are deployed with the new "snapshot" version of the service that triggered the CICD pipeline. To have a clear route for each snapshot environment, we use the namespace as part of the URL (https://HOST/NAMESPACE/APP/paths)
Our Problem
As you can see, the URL is highly dynamic, but currently, we could just build the container with the path and be happy. Thats our current setup. Unfortunately, we want the possibility, to deploy each and every container image on every HOST as well as every NAMESPACE, those parts are only known at runtime, not in the CICD Pipeline.
Is there any way to handle such a scenario with vue.js. I have basically every freedom to edit the app as well as the container, but can't change the way we want to host our app. Currently we build the App on the cluster and inject the NAMESPACE, which was the "easiest" way to do this. But if there is any other way, I would love to not have the build and run step together.
Thanks in advance.
I have an ASP.Net Core app running on Ubuntu on the server (I dev on Windows). In a block of code, I use Environment.GetEnvironmentVariable("API_KEY"));. In dev, the key is retrieved succesfully. However, when I publish the code to the server, the key cannot be retrieved for some reason. API_KEY ends up being null.
Note: The ASP.NET Core runtimes are both the same versions (5.0 preview 7) on dev and prod and yes, I have the environment variable setup on the server and can printenv it out. When I plug in the actual key into the app rather than use an environment variable name, my app works as I want it to.
Typically you have to manually put that setting in your applications "configuration" section. When running on you local machine, it will pull from the local.settings.json, but on the server running in Release mode, it will pull from the server-side config. That config is located here:
This is done because your local environment should be running different (safe) settings than something running live on a server.
If you accidentally commit your code to a repo and that local.settings.json goes along with it, someone who gets in to your repo won't be able to get critical data.
Currently I am using ms-deploy to build and deploy on several machines using team-city. In my current scenario, I need to build, package and deploy on Dev. After this I need to deploy this package on test and Live servers (which are on different domain. I understand how we do it but problem is Web transformation only occurs for test and live configs if we build a package. It means if I want to use the same package that is created for Dev cannot be used, as web transformation only occurred for Dev web config. Also know that we can change web config when un-packaging but that parameters are very limited. We have a lot of changes not just the connection string or db changes.
Another solution is to add another step to build packages for test and live as part of Dev deployment but then it means a lot of copying on remote servers, once for test and once for live which is a lot of time consuming due to different domains.
Can you please guide what is the best solution in this scenario. So I can use team-city to publish to Dev and test and live using same package and different web configs in one go.
To configure items at deployment time which are not automatically created for you. You can add a file named parameters.xml to your project and extend what you want to make available at deployment time.
Here's some documentation on the approach Using Deployment Parameters for Web.Config File Settings.