I have a question about rewrite configurations on Vercel, very similar to this vercel discussion. My problem is essentially the same but reverse:
I have a site on vercel (main.vercel.app), and I would like to rewrite different pages to other vercel sites. So what I want is:
main.vercel.app/page-a --> page-a.vercel.app
main.vercel.app/page-b --> page-b.vercel.app
When I tried this configuration, it would correctly load the page, but all the assets (page-a.vercel.app/styles.css etc.) would not be loaded:
{
"rewrites": [
{
"source": "/page-a",
"destination": "https://page-a.vercel.app/"
}
]
}
When I tried this configuration, it would redirect all the assets, but not the initial page:
{
"rewrites": [
{
"source": "/page-a(.*)",
"destination": "https://page-a.vercel.app$1"
}
]
}
So what's the correct configuration supposed to be?
What if you try merging the two rewrites?
According to you, one rewrite pattern is correct for the main page, and the other is for all other assets other than the main page. Since rewrites is a list and can hold multiple patterns, try merging the two objects and making it something like this:
{
"rewrites": [
{
"source": "/page-a",
"destination": "https://page-a.vercel.app/"
},
{
"source": "/page-a(.*)",
"destination": "https://page-a.vercel.app$1"
}
]
}
Related
My API it's running under another domain.. and I'm trying to configure proxy with Vercel ..
The app it's making requests to /api/test.json so I tried to... on vercel configuration
"redirects": [
{
"source": "/api/test.json",
"destination": "https://myapi.com/test.json",
}
],
"rewrites": [
{
"source": "/(.*)",
"destination": "/index.html"
}
]
And I received 404 from /api/test.json
Use the wildcard path matching :path* syntax:
// in vercel.json:
// for example proxying /api/ → https://backend-endpoint/
{
"rewrites": [
{
"source": "/api/:path*",
"destination": "https://backend-endpoint/:path*"
},
{
"source": "/api/:path*/",
"destination": "https://backend-endpoint/:path*/"
}
]
}
NOTE: You need both very identical objects under rewrites array as above in order to make things work properly. The example in the documentation is only the one without the trailing slash and it won't convert (for example) /api/auth/login/ to https://backend-endpoint/auth/login/, that example can only convert /api/auth/login to https://backend-endpoint/auth/login (without trailing slash /)
(it took me a day to realize that trailing slash / is actually very important).
Simply use rewrites
"rewrites": [
{
"source": "/api/test.json",
"destination": "https://myapi.com/test.json",
}
]
Then in your application
httpAgent
.get('/api/test.json)
.then(res => { console.log(res) })
My objective is to write a script that promotes a "stage" application in our Heroku pipeline to production, but only if there are any changes to promote.
I can promote without issues by using:
// POST /pipeline-promotions
{
"pipeline": {
"id": "<pipeline-id>"
},
"source": {
"app": {
"id": "<stage-app-id>"
}
},
"targets": [
{
"app": {
"id": "<production-id>"
}
}
]
}
My issues is that if I execute this, without any changes are present, the release actions are still started on the production application.
In other words, how can I determine if any changes are available for promotion - just like heroku does in their GUI?
Thanks to Heroku support, I managed to figure this out.
It can be done by comparing the slug id's when looking at pipelines/<pipeline-id>/latest-releases.
If the slug-ids are the same, there are no changes to promote.
I have a site built with create-react-app and hosted on Firebase Hosting. What can I do to specify the browser cache needs to be updated after new deploys, and ideally only for pages, assets, and stylesheets that have been changed since the last deploy?
Is there a way to access the deploy id and include that (or any other unique identifier) in the headers so the browser can compare to what it has in local storage or cache and determine whether a hard refresh is necessary? I looked over the Firebase Deploying as well as Full config docs but there's no mention on how to access hosting metadata like the last deploy time.
Setting a Cache-Control value to max-age=[any number] doesn't seem ideal because it disregards when the next deployment will occur (which might be unknown to begin with unless there are regular schedules).
I figured it out. Had to update the firebase.json file according to this Github comment:
{
"hosting": {
"headers": [
{ "source":"/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}] }
]
}
}
Please set "max-age=0" in your firebase.json.
"headers": [
{
"source": "/service-worker.js",
"headers": [
{
"key": "Cache-Control",
"value": "no-cache, no-store, must-revalidate"
}
]
},
{
"source": "**/*.#(jpg|jpeg|gif|png|svg|webp|js|css|eot|otf|ttf|ttc|woff|woff2|font.css)",
"headers": [
{
"key": "Cache-Control",
"value": "max-age=0"
}
]
}
]
This sounds like a rookie question, but I'm wondering what's the best way to present paged resources with HAL format? Right now I'm using Spring HATEOAS API to convert Page object into resource PagedResourcesAssembler#toResource(Page<T>, ResourceAssembler<T,R>). This results in the following output:
{
"_links": {
"self": {
"href": "http://example.org/api/user?page=3"
},
…
}
"count": 3,
"total": 498,
"_embedded": {
"users": [
{
"_links": {
"self": {
"href": "http://example.org/api/user/mwop"
}
},
"id": "mwop",
"name": "Matthew Weier O'Phinney"
}
]
}
}
Everything works fine but the only problem is the collection being returned is under _embedded field and has the class name, so the client has to know this class name as well right? Would it be better to just return the collection under content like non-HAL format? If yes how should I achieve it using Spring HATEOAS?
That's not a problem, that's the way _embedded is defined in the HAL specification.
users is not a class, it's a link relation that will allow clients to actually find the collection it was asking for in the first place (e.g. using a JSONPath expression). That's not something coming out of the blue at all but usually is the same link relation, the client used to find that resource in the first place.
Assume an API root exposing this document:
{
"_links": {
"users": {
"href": "…"
},
…
}
}
Seeing that, the client would have to know the semantics of users to find the link it wants to follow. In your case users is basically pointing to a collection resource that supports pagination.
So if the client follows the link named users, it can then find the actual content it's looking for under _embedded.users in the HAL response by combining knowledge about the media type (HAL, _embedded) and the service's application-level semantics (users).
I'm trying to create an entire site hosted purely on CouchDB (no nginx reverse proxy either) using a lot of client side Jquery/AJAX magic. Now I'm in the process of making it SEO friendly. I'm using vhosts and URL rewrites to route traffic from the root to my index.html file:
vhost:
example.com /dbname/_design/dd/_rewrite/
In my rewrite definition:
rewrites:[
{
"from": "/db/*",
"to": "/../../../*",
"query": {
}
},
{
"from": "/",
"to": "../../static/index.html",
"query": {
}
}
]
When optimizing a site for SEO, Google requires you to do a few things:
Use the hashbang (#!) in your friendly URL to tell the web crawler that you are an AJAX site with web crawlable material: http://example.com/index.html#!home
Use an http query argument to provide an HTML escaped fragment of that AJAX page: http://example.com/index.html?_escaped_fragment=home
I tried the following with no luck:
rewrites:[
{
"from": "/db/*",
"to": "/../../../*",
"query": {
}
},
{
"from": "/",
"to": "../../static/index.html",
"query": {
}
}, /* FIRST ATTEMPT */
{
"from": "/?_escaped_fragment=:_escaped_fragment",
"to": "/_show/escaped_fragment/:_escaped_fragment",
"query": {
}
}, /* SECOND ATTEMPT */
{
"from": "/?_escaped_fragment=*",
"to": "/_show/escaped_fragment/*",
"query": {
}
}, /* THIRD ATTEMPT */
{
"from": "/",
"to": "/_show/escaped_fragment/:_escaped_fragment",
"query": {
}
}
]
From what I've seen, CouchDB's URL rewriter is not capable of distinguishing the difference between a URLs with args and no args. Has anyone had luck creating such a rule with CouchDB URL rewrites?
I don't have a answer to the question, but I've developed a solution for the bigger problem of making crawlable sites hosted on CouchDB. It is a system that makes use of Facebook's React, list and show functions, ajax on the client and window.history to render the same HTML components filled with data at CouchDB and at the browser:
https://github.com/fiatjaf/reactive-couch
This solution doesn't need the hashbang, because for each unique URL the browser navigates to, using ajax and window.history or simple links (be it _list/listName/viewName/_show/displayKind/c305ee4d-8611-4e08-b9d3-3318835632a9 or something rewritten as /name//kind/c305ee4d-8611-4e08-b9d3-3318835632a9), the server can render the pertinent content.