Proxy front-end HTTP calls in development - spring

I' building a small website. The back-end is written in Kotlin and uses Spring boot, and the front-end is built in Elm.
The generated javascript app will be served statically by my back-end on deployment.
For development, I currently work as such :
Serve my spring boot application on localhost:8080
Serve my Elm app on b using create-elm-app
The main reason is that create-elm-app allows for hot-compilation and hot-reload of the Elm app, which makes it very convenient.
The problem with this is that I have to set up all my elm http calls against another port locally, which means I have to alter the code for production.
Ideally, I'd like to:
Either have live-recompilation of elm code that changes ( I used chokidar in node, but didn't find a direct java alternative) coupled to a spring boot hot reload
Have create-elm-app redirect my API calls
Or auto-proxy all my calls to another location via a third party
Does anyone have experience with this? What setup would you recommend?
Cheers,

Alright, using the word proxy did help!
It seems that the create-elm-app documentation already expects this use case. You can read more about it here.
Basically what needs to be done is:
Create a elmapp.config.js file at the root of the elm project, with the following content (in my case, you can adapt):
module.exports = {
proxy: "http://localhost:8080",
}
Then, in your elm code, use absolute URLs. For example :
makeCreateGameUrl : Model -> String
makeCreateGameUrl model =
absolute
[ "game" ]
[ string "players" (joinListOfStrings model.newPlayerNames) ]
After this, your API calls will be directly redirected to your backend.

Related

How to properly connect Nuxt.js with a laravel backend?

I am starting a new project, Nuxt.js for the frontend and Laravel for the backend.
How can I connect the two?
I have installed a new Nuxt project using create-nuxt-app, and a new laravel project.
As far as I have searched, I figured I need some kind of environment variables.
In my nuxt project, I have added the dotenv package and placed a new .env file in the root of the nuxt project.
And added CORS to my laravel project, as I have been getting an error.
The variables inside are indeed accessible from the project, and im using them
like this:
APP_NAME=TestProjectName
API_URL=http://127.0.0.1:8000
And accessing it like this:
process.env.APP_NAME etc'
To make HTTP calls, I am using the official Axios module of nuxt.js, and to test it i used it in one of the components that came by default.
The backend:
Route::get('/', function () {
return "Hello from Laravel API";
});
and from inside the component:
console.log(process.env.API_URL)//Gives 127.0.0.1:8000
//But this gives undefined
this.$axios.$get(process.env.API_URL).then((response) => {
console.log(response);
});
}
What am I doing wrong here?
I have tried to describe my setup and problem as best as I can. If I overlooked something, please tell me and I will update my question. Thanks.
Taking for granted that visiting https://127.0.0.1:8000/ in your browser you get the expected response, lets see what might be wrong in the front end:
First you should make sure that axios module is initialized correctly. Your nuxt.config.js file should include the following
//inclusion of module
modules: [
'#nuxtjs/axios',
<other modules>,
],
//configuration of module
axios: {
baseURL: process.env.API_URL,
},
Keep in mind that depending on the component's lifecycle, your axios request may be occurring in the client side (after server side rendering), where the address 127.0.0.1 might be invalid. I would suggest that you avoid using 127.0.0.1 or localhost when defining api_uris, and prefer using your local network ip for local testing.
After configuring the axios module as above, you can make requests in your components using just relative api uris:
this.$axios.$get('/').then(response => {
console.log(response)
}).catch(err => {
console.error(err)
})
While testing if this works it is very helpful to open your browser's dev tools > network tab and check the state of the request. If you still don't get the response, the odds are that you'll have more info either from the catch section, or the request status from the dev tools.
Keep us updated!
Nuxt has a routing file stucture to make it easy to set up server side rendering but also to help with maintainability too. This can cause Laravel and Nuxt to fight over the routing, you will need to configure this to get it working correctly.
I'd suggest you use Laravel-Nuxt as a lot of these small problems are solved for you.
https://github.com/cretueusebiu/laravel-nuxt

Where do I get the value for `shopOrigin` when using Shopify app bridge?

Throughout the documentation for the new App Bridge, Shopify refers to the shopOrigin value and how it's used to configure the Provider from app-bridge-react but they never specify how to get this value?
The react app is loaded inside of an iframe and the src includes the shopOrigin value as a query string param called shop, but when I try the following code I get the error window is not defined:
const params = queryString.parse(window.location.search);
const config = {
apiKey: process.env.SHOPIFY_API_KEY,
shopOrigin: params.shop,
};
1) Why would I be getting window is not defined in javascript code running in a browser?! This makes no sense to me
2) If this value can be read from of the provided libraries such as #shopufy/app-bridge-react please tell me how
Unless you're using a library tailored specifically to Shopify, you have to manually save the shop origin during OAuth authorization.
Hopefully this Shopify tutorial is of some assistance
The shopOrigin is available within your browser cookies.
If you followed the Shopify development for react and Node.js, you should already saved this after the Shopify authentification.
I am not sure what exactly is the need for shopOrigin, if you just wanted to go to admin section of the shop from client side you can use Redirect in app bridge. otherwise you can store the shop detail on server during auth process and create a get api to retrive the details on client side as needed.

WebApi: Use different Route prefix for http reservation and WebApi routes

I have a Windows Service which exposes some APIs via WebAPI and OData using http.sys (to facilitate port sharing):
/api
/odata
/swagger
I also have reservation with http.sys for the prefix https://+:1234/.
Additionally, I have a web site (SPA) which uses this API and I'd like it to run on the same port. UP to now, this was no problem, because I had static file hosting in the service. For various reasons, I moved the static file hosting to its own service. and changed my http.sys reservation to this:
Static file hosting (Weak wildcard):
https://*:1234/
Service (strong wildcard):
https://+:1234/api/
https://+:1234/swagger/
https://+:1234/odata
And in my service I changed my
WebApp.Start("https://+:1234", Startup);
to
var options = new StartOptions
{
urls =
{
"https://+:1234/api/",
"https://+:1234/swagger/",
"https://+:1234/odata/",
}
};
_Service = WebApp.Start(options, Startup);
However, now the routes to the WebApi are https://+:1234/api/api/ and I can even use https://+:1234/api/odata/, which is kind of understandable, but not what I intended.
Can I trick WebApi that while it registers itself with http.sys on the three listening urls but always uses https://+:1234/ as the base for the routing?
This is nice question, I was tried different ways ..., But I had same experiences what you got right now....
Finally, I have understand, We can achieve your excepted out put with the UrlPrefixCollection Here is Url : https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.server.httpsys.urlprefixcollection?view=aspnetcore-2.2

Swagger page being redirected from https to http

AWS Elastic Load Balancer listening through HTTPS (443) using SSL and redirecting requests to EC2 instances through HTTP (80), with IIS hosting a .net webapi application, using swashbuckle to describe the API methods.
Home page of the API (https://example.com) has a link to Swagger documentation which can bee read as https://example.com/swagger/ui/index.html when you hove over on the link.
If I click on the link it redirects the request on the browser to http://example.com/swagger/ui/index.html which displays a Page Not Found error
but if I type directly in the browser URL https://example.com/swagger/ui/index.html then it loads Swagger page, but then, when expanding the methods an click on "Try it out", the Request URL starts with "http" again.
This configuration is only for Stage and Production environments. Lower environments don't use the load balancer and just use http.
Any ideas on how to stop https being redirected to http? And how make swagger to display Request URLs using https?
Thank you
EDIT:
I'm using a custom index.html file
Seems is a known issue for Swashbuckle. Quote:
"By default, the service root url is inferred from the request used to access the docs. However, there may be situations (e.g. proxy and load-balanced environments) where this does not resolve correctly. You can workaround this by providing your own code to determine the root URL."
What I did was provide the root url and/or scheme to use based on the environment
GlobalConfiguration.Configuration
.EnableSwagger(c =>
{
...
c.RootUrl(req => GetRootUrlFromAppConfig(req));
...
c.Schemes(GetEnvironmentScheme());
...
})
.EnableSwaggerUi(c =>
{
...
});
where
public static string[] GetEnvironmentScheme()
{
...
}
public static string GetRootUrlFromAppConfig(HttpRequestMessage request)
{
...
}
The way I would probably do it is having a main file, and generating during the build of your application a different swagger file based on the environnement parameters for schemes and hosts.
That way, you have to manage only one swagger file accross your environments, and you only have to manage a few extra environnement properties, host and schemes (if you don't already have them)
Since I don't know about swashbuckle, I cannot answer for sure at your first question (the redirect)

WebAPI SignalR Negotiate response different on different browsers

The main problem about Access-Control-Allow-Origin I think. But when I configure the Web API project as defined in the given documentation, it still not working in chrome and firefox but working in IE well (it is about IE thinks localhost is not cross domain, AFAIK). I tried different ways to make it work but no result.
I put the example project to github repository. Project is very simple. There are two applications working on cross domains. It is very simple chat application like in signalr examples.
You must change the value of api host in client javascript file:
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApp/Scripts/app/chat.js#L2
When you open the Chat page in mvc project, there will be two requests to api application
1- Regular ajax request (which is working fine)
2- Signalr negotiate request (cancelled)
And also I don't think browser disables the CORS because of if it disables there would not be an hit to server. So I think it is about browser but not about browser disables (something else).
Details are in repository
Readme: https://github.com/yusufuzun/WebApiSignalR/blob/master/README.md
Fiddler Results: https://github.com/yusufuzun/WebApiSignalR/blob/master/FiddlerResults
The bad part about it also is server returning 500 with this error:
System.InvalidOperationException: 'chat' Hub could not be resolved.
Which hub name is chat also.
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Hubs/ChatHub.cs#L10
You can enable CORS for Web Api in project with different ways for test purposes. Each one is giving different errors all about XMLHttpRequest Access-Control-Allow-Origin.
I commented them, so you can uncomment and make test for each one:
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Global.asax.cs#L24
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/App_Start/WebApiConfig.cs#L14
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/App_Start/WebApiConfig.cs#L16
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Controllers/ChatController.cs#L17
So what is going on here?
After I talked with David Fowler in JabbR, he mentioned the thing about using CORS with SignalR. My signalr startup code was wrong. So after changing the startup code like in his advice it worked well.
He also mentioned SignalR and Web API are working with different CORS definitions. So enabling or disabling one doesn't affect other.
Here is the new startup code:
app.Map("/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
map.RunSignalR(new HubConfiguration()
{
EnableDetailedErrors = true,
EnableJavaScriptProxies = true
});
});
The old one:
app.MapSignalR(new HubConfiguration()
{
EnableDetailedErrors = true,
EnableJavaScriptProxies = true
}).UseCors(CorsOptions.AllowAll);
Hope it helps to somebody out there.

Resources