anbaric 1.60.0 → 1.61.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -46,12 +46,12 @@ unrouted absolute path that arrives with a `Referer` from your app is redirected
|
|
|
46
46
|
back to `/app/<name>/…` (a `307`, so form POSTs keep their body). So ordinary
|
|
47
47
|
absolute links followed from a page of your app just work.
|
|
48
48
|
|
|
49
|
-
## Your app's own
|
|
49
|
+
## Your app's own address
|
|
50
50
|
|
|
51
|
-
Every app
|
|
51
|
+
Every app answers on an address of its own:
|
|
52
52
|
|
|
53
53
|
```
|
|
54
|
-
https://<
|
|
54
|
+
https://<address>.<platform domain>
|
|
55
55
|
```
|
|
56
56
|
|
|
57
57
|
There your app is at the root, exactly where it was when you ran it locally, so
|
|
@@ -59,10 +59,29 @@ absolute paths, `fetch("/api/…")` and anything else that assumes the root work
|
|
|
59
59
|
without being rewritten. This is the address to share and the one to prefer; the
|
|
60
60
|
`/app/<name>` form below stays available and unchanged.
|
|
61
61
|
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
62
|
+
`anbaric app deploy` prints the address, and the console shows it next to the app
|
|
63
|
+
on the **Manage apps** page.
|
|
64
|
+
|
|
65
|
+
### How an address is chosen
|
|
66
|
+
|
|
67
|
+
An address is one label under the platform's domain, so it has to be unique
|
|
68
|
+
across every customer, not just yours. When an app is first deployed it is given
|
|
69
|
+
its own name if that name is free. If it is not, a word is added — `invoices`
|
|
70
|
+
becomes something like `invoices-walnut` — and if even that is crowded, a short
|
|
71
|
+
number. A handful of names are reserved and never handed out.
|
|
72
|
+
|
|
73
|
+
Your app's name is unaffected by any of this. The name is what you deploy,
|
|
74
|
+
reference and tear down by; the address is only where it answers.
|
|
75
|
+
|
|
76
|
+
### Changing an address
|
|
77
|
+
|
|
78
|
+
A builder can set an app's address on the **Manage apps** page in the console. An
|
|
79
|
+
address someone else already holds is refused, and the old address stops working
|
|
80
|
+
as soon as the new one is saved — so change it before you share it, not after.
|
|
81
|
+
|
|
82
|
+
An address lasts as long as the app. Tearing an app down frees its address for
|
|
83
|
+
anyone to take, including another customer, so a torn-down app's links should be
|
|
84
|
+
treated as gone for good.
|
|
66
85
|
|
|
67
86
|
## Under /app/<name>
|
|
68
87
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "anbaric",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.61.0",
|
|
4
4
|
"description": "Everything needed to write an Anbaric app: state machines, jobs, document and secret stores, local in-memory implementations and the Anbaric Cloud clients",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|
|
@@ -24,9 +24,9 @@
|
|
|
24
24
|
"prepublishOnly": "npm run build"
|
|
25
25
|
},
|
|
26
26
|
"dependencies": {
|
|
27
|
-
"anbaric-impl-cloud": "^1.
|
|
28
|
-
"anbaric-data-store": "^1.
|
|
29
|
-
"anbaric-state-machine": "^1.
|
|
30
|
-
"anbaric-tsapi": "^1.
|
|
27
|
+
"anbaric-impl-cloud": "^1.61.0",
|
|
28
|
+
"anbaric-data-store": "^1.61.0",
|
|
29
|
+
"anbaric-state-machine": "^1.61.0",
|
|
30
|
+
"anbaric-tsapi": "^1.61.0"
|
|
31
31
|
}
|
|
32
32
|
}
|