Coder Social home page Coder Social logo

binaris's Introduction

Binaris

Binaris is a fast, low-latency FaaS (Function as a Service) platform. With our performance and scale, you can run real production workloads on Node.js.

Getting up and running in seconds

  1. Install using npm
npm install -g binaris
  1. Setup Binaris credentials

    • If you already have an account it's as simple as exporting your existing credentials
    • Otherwise head over to Binaris to sign up
  2. Generate a Binaris template function

# generates simple NodeJS template function
bn create node12 hellofunc
  1. Deploy a function
# makes the function available via Binaris cloud
bn deploy hellofunc
  1. Invoke a function
# calls the function endpoint via https
bn invoke hellofunc
  1. Make changes to a function
git diff
--- a/function.js
+++ b/function.js

-    console.log('Hello World');
+    console.log('Hello Binaris');

# redeploy the function
bn deploy hellofunc
  1. Get logs for a function
bn logs hellofunc

It's as simple as that.

Running without Node & NPM

There's a docker version of the Binaris CLI, published on Dockerhub as binaris/bn.

Usage

To run in the current directory:

docker run --rm -v $(pwd):/src binaris/bn --help

You'll want to forward your API key. So add -e BINARIS_API_KEY like so:

docker run --rm -e BINARIS_API_KEY -v $(pwd):/src binaris/bn

For convenience, you can create an alias for this in bash:

alias bn='docker run --rm -e BINARIS_API_KEY -v $(pwd):/src binaris/bn'
bn create node12 hello
bn deploy hello
bn invoke hello

Storing secrets and other configuration parameters

You can pass configuration parameters to functions as part of the deploy command. These parameters will be available to the function during runtime as environment variables. All parameters are encrypted at rest and in-transit, which makes them the preferred way to store API keys, passwords, etc.

To pass parameters into a function, add an env: section to binaris.yml, like so:

functions:
  hello:
    file: function.js
    entrypoint: handler
    runtime: node12
    env:
      SOME_API_KEY: XXXXXXXXXXX

If a parameter is sensitive and you don't want to commit it to SCM, you can leave out the value in binaris.yml:

functions:
  hello:
    file: function.js
    entrypoint: handler
    runtime: node12
    env:
      SOME_API_KEY:

And pass it as an environment variable to the deploy command:

You can then access these parameters as environment variables:

function.js

exports.handler = () => {
  const apiKey = process.env.SOME_API_KEY;
  // ...
}

Or in Python:

import os

def handler(body, req):
    apiKey = os.environ['SOME_API_KEY']
    # ...

Only string values are supported in the env: section.

SOME_API_KEY=XXXXXXX bn deploy hello

Learn more about the Binaris platform at the developer resources page.

This project is licensed under the terms of the MIT license

binaris's People

Contributors

arielshaqed avatar bergundy avatar lavie avatar michaeladda avatar rylandg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

rylandg

binaris's Issues

CLI should avoid "you wish"

E.g. s/The path to the Binaris function you wish to remove/path of function to remove/ in option description.

Add login functionality to the CLI

We need a fully working login function that correctly writes the users AUTH_KEY to a well known file in their home directory(overridden by env var).

use async await in our code

There are cases where raw promises are not needed in our code.
Exception due to parallel waits such as await Promise.all(list) are obviously ok.

running 'bn' prints an node error

had old node version, so got this error:

ubuntu@yuval-bastion:~/src/binaris$ bn
/usr/local/lib/node_modules/binaris/index.js:5
const { init, invoke, deploy } = require('./sdk/sdk');
      ^

Proper case for first word of printouts

i.e. basic Spelling...

~/binaris/user $ bn deploy
starting function deployment process
validating Binaris credentials
your current directory does not contain a valid binaris function!
~/binaris/user $ ls
aloof-pigs
~/binaris/user $ cd aloof-pigs/
~/binaris/user/aloof-pigs $ bn depl
You have new mail in /var/mail/assaf
~/binaris/user/aloof-pigs $ bn deploy
starting function deployment process
validating Binaris credentials
function was not deployed successfully, check logs for more details

Should all be:

Starting ...
Validating ....

no entryPoint name inside package.json

bn init -> bn deploy -> cd .binaris -> tar -zxvf undefined.tgz ->

ubuntu@yuval-bastion:~/tmp/ad-mark/.binaris$ ls
function.json  handler.js  package.json  undefined.tgz
ubuntu@yuval-bastion:~/tmp/ad-mark/.binaris$ cat package.json
{
  "name": "ad-mark",
  "version": "1.0.0",
  "description": "Binaris Functions sample for the Serverless framework",
  "main": "handler.js",
  "keywords": [
    "binaris",
    "nodejs"
  ],
  "devDependencies": {}
}ubuntu@yuval-bastion:~/tmp/ad-mark/.binaris$ cat function.json

logger.js is duplicated

there's no need to keep it twice.
if the cli-sdk is indeed an sdk it should not print anything on its own accord. at most one can pass a logger to the cli-sdk functions to allow it to print.

Deploy fails because "file already exists".

flutterby:prettywax ariels$ export BINARIS_LOG_LEVEL=debug
flutterby:prettywax ariels$ node ~/Dev/binaris/index.js deploy
Deploying function...

	{"funcConf":{"file":"spin30.js","entrypoint":"spinHello"}}

	{"message":"EEXIST: file already exists, mkdir '/Users/ariels/Google Drive/Work/Dev/my-function/prettywax/.binaris/'","stack":"Error: EEXIST: file already exists, mkdir '/Users/ariels/Google Drive/Work/Dev/my-function/prettywax/.binaris/'","errno":-17,"code":"EEXIST","syscall":"mkdir","path":"/Users/ariels/Google Drive/Work/Dev/my-function/prettywax/.binaris/"}
Error creating working directory: .binaris/

Unless some fail-don't-fix semantics are desired, we shouldn't fail deploy because mkdir said EEXIST. If they are desired, let's give a good error message!

Add a spec for the sdk

SDK interaction should be documented in a spec and any change to it should increase its version.
Every possible function call, argument, and return values should be documented.
This will be the source of truth for the sdk interface.

copy template file using a package

currently we read and write the file entirely with

await fs.writeFile(path.join(newDir, file),
  await fs.readFile(path.join(__dirname, templateDir, file)));

it should use node-fs-extra or something similar

versions mismatch

the code has .version('0.0.1')
package.json has "version": "1.0.0"
and the tag is 1.0.0

Support multiple functions per one binaris.yml file

The default behaviour when a function name is not given should be to loop on all functions or print an error asking for a specific function.
bn deploy should deploy all functions.
bn deploy foo should deploy only foo.
bn invoke should error and require a function name.

unit tests for the CLI

This along with the hostname envar should allow us to test it thoroughly with a local stub http server.

DRY in errorMessageAndExit

Right now, every log.error is followed by errorMessageAndExit, such as

log.error(err.message.red);
errorMessageAndExit();

This should become errorMessageAndExit(err.massage) for example

Add logs support

Add a function to the SDK, based on the API at gobinaris/picard#6
Use the SDK from the cli/cli-sdk

separate colors from strings

choice of color should be centralized.
if errors, for example, should be red then the logger should take care of it, not marking every message red. Right now the case is

Michaels-MacBook-Pro-2:binaris michael$ git grep '\.red' cli.js
cli.js:    log.error(err.message.red);
cli.js:    log.error(err.message.red);
cli.js:    log.error(err.message.red);
cli.js:    log.error('Options json (-j) and file (-f) cannot be provided together'.red);
cli.js:    log.error(err.message.red);
cli.js:    log.info(`Unknown command: ${env}`.red);

log.error or a wrapper should take of it and not every message.
(and btw, if unknown command is an error, it should be printed with log.error and not log.info)

getting exception on invoke error

The code does not check if resp is defined or if there's error

      TypeError: Cannot read property 'statusCode' of undefined
          at Request.request.post [as _callback] (/opt/binaris/node_modules/binaris/sdk/invoke.js:20:15)
          at self.callback (/opt/binaris/node_modules/request/request.js:188:22)
          at emitOne (events.js:115:13)
          at Request.emit (events.js:210:7)
          at Request.onRequestError (/opt/binaris/node_modules/request/request.js:884:8)
          at emitOne (events.js:115:13)
          at ClientRequest.emit (events.js:210:7)
          at TLSSocket.socketErrorListener (_http_client.js:401:9)
          at emitOne (events.js:115:13)
          at TLSSocket.emit (events.js:210:7)

ESLint-check CLI code

We have some ESLint errors. We should add a Makefile (or similar) to check for ESLint, and also support for Jenkins to check it on and after all PRs.

Add a spec for the cli

User interaction should be documented in a spec and any change to it should increase version.
Every possible command, option, output or error should be documented.
This will be the source of truth for the cli code.

No need to JSON parse user data on invoke

Currently, the code uses attemptJSONParse to convert the user supplied string into object and then converting it back to string to send it on the wire.
This stage is not needed. The user should have full control over the data she's sending.

BINARIS_HOSTNAME envar for debugging

So that we can easily direct the API to another realm.
Default value should be api-prod.binaris.com and we'll override it individually to api-staging.binaris.io or whatever we need.

names should only be generated once

when generating a name with moniker which does not pass validateFunctionName it should be fixed instead of generating names in a loop.
While at it, the entire name generation/choosing should be in a function and not part of init

try catch to print an error should be generalized

throughout the code there are many try { ... } catch { log.debug('message'); throw new Error('new message') }
They should be refactored to avoid repetition.
Also, throwing a new error without attaching the stack from the origin err might make debugging more complex

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.