hyper-nano 1.3.1 → 2.0.0

package/README.md

@@ -16,40 +16,35 @@
 
 ## Motivation
 
-A core tenant of the hyper service framework is that an application should not
-need to care about the underlying service implementation. By building an
-application to consume an api, your appliation, and ergo your business logic, is
-kept separate and decoupled from the services that power it.
+A core tenant of the hyper service framework is that an application should not need to care about
+the underlying service implementation. By building an application to consume an api, your
+appliation, and ergo your business logic, is kept separate and decoupled from the services that
+power it.
 
-> Learn more about
-> [Clean Architecture](https://blog.hyper.io/the-perfect-application-architecture/)
+> Learn more about [Clean Architecture](https://blog.hyper.io/the-perfect-application-architecture/)
 
-This allows for _swapping out_ the service api implementations, without having
-to change business logic. `hyper-nano` is an embodiment of this approach.
+This allows for _swapping out_ the service api implementations, without having to change business
+logic. `hyper-nano` is an embodiment of this approach.
 
-`hyper nano` is an instance of hyper running an `http` based api, and a set of
-`in-memory` [`adapters`](https://docs.hyper.io/oss/building-your-own-adapter)
-for all of the hyper service offerings:
+`hyper nano` is an instance of hyper running an `http` based api, and a set of `in-memory`
+[`adapters`](https://docs.hyper.io/oss/building-your-own-adapter) for all of the hyper service
+offerings:
 
 - data (powered by [PouchDB](https://github.com/hyper63/hyper-adapter-pouchdb))
 - cache (powered by [Sqlite](https://github.com/hyper63/hyper-adapter-sqlite))
-- storage (powered by your local
-  [file system](https://github.com/hyper63/hyper-adapter-fs))
-- search (powered by
-  [Sqlite and Minisearch](https://github.com/hyper63/hyper-adapter-minisearch))
-- queue (powered by
-  [DnDB and an in-memory queue](https://github.com/hyper63/hyper-adapter-queue))
+- storage (powered by your local [file system](https://github.com/hyper63/hyper-adapter-fs))
+- search (powered by [Sqlite and Minisearch](https://github.com/hyper63/hyper-adapter-minisearch))
+- queue (powered by [DnDB and an in-memory queue](https://github.com/hyper63/hyper-adapter-queue))
 
-This allows running a hyper instance locally, great for development, or for
-sandboxed short-lived environments ie. GitHub Workspaces or GitPod.
+This allows running a hyper instance locally, great for development, or for sandboxed short-lived
+environments ie. GitHub Workspaces or GitPod.
 
-> At hyper, we exclusively use short-lived ephermeral environments for all
-> development. We dog food hyper to build hyper.
+> At hyper, we exclusively use short-lived ephermeral environments for all development. We dog food
+> hyper to build hyper.
 
-Then when you deploy, your application consumes your _actual_ hyper application
-in [hyper cloud](https://docs.hyper.io), with no code changes required; (hyper
-cloud is just hyper instances running a different `http` based api set of
-`adapters`)
+Then when you deploy, your application consumes your _actual_ hyper application in
+[hyper cloud](https://docs.hyper.io), with no code changes required; (hyper cloud is just hyper
+instances running a different `http` based api set of `adapters`)
 
 ## Documentation
 
@@ -80,20 +75,18 @@ npx hyper-nano --domain=foobar --experimental --data --cache ...
 
 ### Deno Usage
 
-Alternatively, if you use `Deno` you may run `hyper nano` directly from the
-source:
+Alternatively, if you use `Deno` you may run `hyper nano` directly from the source:
 
 ```sh
 deno run --allow-env --allow-read --allow-write=__hyper__ --allow-net --unstable --no-check=remote https://raw.githubusercontent.com/hyper63/hyper/main/images/nano/mod.js
 ```
 
-If you'd like to programmatically start `hyper nano`, you can import `main.js`
-and run `main`:
+If you'd like to programmatically start `hyper nano`, you can import `main.js` and run `main`:
 
 ```js
-import { main } from "https://raw.githubusercontent.com/hyper63/hyper/main/images/nano/main.js";
+import { main } from 'https://raw.githubusercontent.com/hyper63/hyper/main/images/nano/main.js'
 
-await main();
+await main()
 ```
 
 and then run:
@@ -102,25 +95,23 @@ and then run:
 deno run --allow-env --allow-read --allow-write=__hyper__ --allow-net --unstable --no-check=remote foo.js
 ```
 
-All of these examples above will start a `hyper nano` instance, listening on
-port `6363`. You can then consume your hyper instance
-[`hyper-connect`](https://github.com/hyper63/hyper/tree/main/packages/connect)
-(recommended) or using `HTTP`.
+All of these examples above will start a `hyper nano` instance, listening on port `6363`. You can
+then consume your hyper instance
+[`hyper-connect`](https://github.com/hyper63/hyper/tree/main/packages/connect) (recommended) or
+using `HTTP`.
 
-To consume using
-[`hyper-connect`](https://github.com/hyper63/hyper/tree/main/packages/connect)
-pass `http://localhost:[port]/[domain]` to `hyper-connect` as your
+To consume using [`hyper-connect`](https://github.com/hyper63/hyper/tree/main/packages/connect) pass
+`http://localhost:[port]/[domain]` to `hyper-connect` as your
 [`connection string`](https://docs.hyper.io/app-keys#nq-connection-string)
 
-Consume with
-[`hyper-connect`](https://github.com/hyper63/hyper/tree/main/packages/connect):
+Consume with [`hyper-connect`](https://github.com/hyper63/hyper/tree/main/packages/connect):
 
 ```js
-import { connect } from "hyper-connect";
+import { connect } from 'hyper-connect'
 
-const hyper = connect("http://localhost:6363/test");
+const hyper = connect('http://localhost:6363/test')
 
-await hyper.data.list();
+await hyper.data.list()
 ```
 
 Or consume via HTTP
@@ -129,31 +120,32 @@ Or consume via HTTP
 curl http://localhost:6363/data/test
 ```
 
+> Starting with Node 17, Node has changed how it resolves `localhost`, when using global `fetch` and
+> `fetch` from libraries like `undici`. This may cause requests to `localhost` not to resolve
+> correctly and fail. To get around this, you can use `127.0.0.1` or `0.0.0.0`, in lieu of
+> `localhost`. For more info, See [this issue](https://github.com/nodejs/node/pull/39987)
+
 ## URL Structure Disclaimer
 
-> If you use
-> [`hyper-connect`](https://github.com/hyper63/hyper/tree/main/packages/connect)
-> to consume hyper, you may disregard this section.
+> If you use [`hyper-connect`](https://github.com/hyper63/hyper/tree/main/packages/connect) to
+> consume hyper, you may disregard this section.
 
-`hyper nano` is built on the open source version of hyper, and has a different
-URL structure than `hyper cloud`. This is because `hyper cloud` allows for
-groupings of services made explicit by the url.
+`hyper nano` is built on the open source version of hyper, and has a different URL structure than
+`hyper cloud`. This is because `hyper cloud` allows for groupings of services made explicit by the
+url.
 
-For example, assuming the domain `foo` that has a `data` and `cache` service,
-`hyper nano` urls are structured as `/data/foo` and `/cache/foo`, whereas
-`hyper cloud` urls are structured as `/foo/data/default` and
-`/foo/cache/default`.
+For example, assuming the domain `foo` that has a `data` and `cache` service, `hyper nano` urls are
+structured as `/data/foo` and `/cache/foo`, whereas `hyper cloud` urls are structured as
+`/foo/data/default` and `/foo/cache/default`.
 
-If you're consuming `hyper` using straight HTTP, you will need to take this
-difference in url structure into account. If you use `hyper-connect`, no changes
-are required since `hyper-connect` supports both `hyper oss` and `hyper cloud`
-url structures and knows which structure to use based on the provided connection
-string.
+If you're consuming `hyper` using straight HTTP, you will need to take this difference in url
+structure into account. If you use `hyper-connect`, no changes are required since `hyper-connect`
+supports both `hyper oss` and `hyper cloud` url structures and knows which structure to use based on
+the provided connection string.
 
 ### Bootstrapping services
 
-> **This feature is experimental and will need the `--experimental` flag to be
-> enabled**
+> **This feature is experimental and will need the `--experimental` flag to be enabled**
 
 `hyper nano` can be supplied arguments to create services on startup:
 
@@ -163,12 +155,10 @@ string.
 
 Other command line arguments can be provided:
 
-- `--purge`: destroy the existing services. You may also pass in which service
-  types to purge. ie
-  `./nano --experimental --data --cache --storage --purge=data,cache` will
-  delete `data` and `cache`, but not `storage`
-- `--domain`: the name of the domain your services will be created under. This
-  defaults to `test`
+- `--purge`: destroy the existing services. You may also pass in which service types to purge. ie
+  `./nano --experimental --data --cache --storage --purge=data,cache` will delete `data` and
+  `cache`, but not `storage`
+- `--domain`: the name of the domain your services will be created under. This defaults to `test`
 
 Examples:
 
@@ -189,7 +179,7 @@ Examples:
 or programmatically:
 
 ```js
-import { main } from "https://raw.githubusercontent.com/hyper63/hyper/main/images/nano/main.js";
+import { main } from 'https://raw.githubusercontent.com/hyper63/hyper/main/images/nano/main.js'
 
 /**
  * - Listen on 6363
@@ -197,7 +187,7 @@ import { main } from "https://raw.githubusercontent.com/hyper63/hyper/main/image
  * - Create data, cache, and storage services in the test domain
  */
 await main({
-  domain: "test",
+  domain: 'test',
   experimental: true,
   services: {
     data: true,
@@ -207,7 +197,7 @@ await main({
   purge: {
     data: true,
   },
-});
+})
 ```
 
 ## Contributing

package/bin/index.js

@@ -1,71 +1,73 @@
 #! /usr/bin/env node
 
-const { existsSync } = require("fs");
-const { exec, execSync } = require("child_process");
-const { platform, arch } = require("os");
-const { dirname, join } = require("path");
+const { existsSync } = require('fs')
+const { exec, execSync } = require('child_process')
+const { platform, arch } = require('os')
+const { dirname, join } = require('path')
 
-const chalk = require("chalk");
-const ora = require("ora");
+const chalk = require('chalk')
+const ora = require('ora')
 
-const destDir = join(dirname(__filename));
-const binaryDest = join(destDir, "hyper-nano");
+const { version } = require('../package.json')
+
+const destDir = join(dirname('.'))
+const binaryDest = join(destDir, 'hyper-nano')
 
 function getBinary() {
   const binaries = {
-    linux: "hyper-x86_64-unknown-linux-gnu",
-    win32: "hyper-x86_64-pc-windows-msvc.exe",
-    darwinx86_64: "hyper-x86_64-apple-darwin",
-    darwinarm64: "hyper-aarch64-apple-darwin",
-  };
+    linux: `hyper-x86_64-unknown-linux-gnu-${version}`,
+    win32: `hyper-x86_64-pc-windows-msvc-${version}.exe`,
+    darwinx86_64: `hyper-x86_64-apple-darwin-${version}`,
+    darwinarm64: `hyper-aarch64-apple-darwin-${version}`,
+  }
 
-  const os = platform();
-  let binary = undefined;
+  const os = platform()
+  let binary = undefined
 
-  if (os === "linux" || os === "win32") {
-    binary = binaries[os];
-  } else if (os === "darwin") {
+  if (os === 'linux' || os === 'win32') {
+    binary = binaries[os]
+  } else if (os === 'darwin') {
     // darwin, so if arm64, use aarch64 binary, otherwise use darwin x86-64 binary
-    const architecture = arch() === "arm64" ? "arm64" : "x86_64";
-    binary = binaries[`${os}${architecture}`];
+    const architecture = arch() === 'arm64' ? 'arm64' : 'x86_64'
+    binary = binaries[`${os}${architecture}`]
   }
 
-  return binary;
+  return binary
 }
 
 async function main() {
   if (!existsSync(binaryDest)) {
-    const binary = getBinary();
+    const binary = getBinary()
     if (binary) {
-      const spinner = ora("Downloading hyper {nano}").start();
+      const spinner = ora('Downloading hyper {nano}').start()
       await new Promise((resolve, reject) => {
         // TODO: make cross platform
         exec(
           `curl https://hyperland.s3.amazonaws.com/${binary} -o ${binaryDest} && chmod +x ${binaryDest}`,
-          { cwd: destDir, stdio: "ignore", stderr: "inherit" },
-        ).on("close", (code) => code ? reject(code) : resolve(code));
-      });
-      spinner.stop();
+          { cwd: destDir, stdio: 'ignore', stderr: 'inherit' },
+        ).on('close', (code) => code ? reject(code) : resolve(code))
+      })
+      spinner.stop()
     } else {
       console.log(
         chalk.yellow(
           `Platform ${platform()} not supported by hyper nano. Skipping hyper nano binary install...`,
         ),
-      );
+      )
     }
   }
 
   if (existsSync(binaryDest)) {
-    const args = process.argv.slice(2, process.argv.length);
+    const args = process.argv.slice(2, process.argv.length)
 
     execSync(
-      `./hyper-nano ${args.join(" ")}`,
+      `./hyper-nano ${args.join(' ')}`,
       {
-        stdio: "inherit",
+        stdio: 'inherit',
         cwd: destDir,
       },
-    );
+    )
   }
 }
 
-main();
+main()

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hyper-nano",
-  "version": "1.3.1",
+  "version": "2.0.0",
   "license": "Apache-2.0",
   "description": "In-Memory hyper http server using in-memory adapters",
   "homepage": "https://github.com/hyper63/hyper/tree/main/images/nano",