vhp-api v0.2.3

VHP API

• Brief
• Uses
• Core
• Services
• Setup
• Mart
• JMart

Brief

The package's main purpose is to allow vhp applications to easily interface with the vhpportal. On top of that it helps to standardize how our applications interface with any call out to any api, database, or service.

Uses

To get started import the package using npm:

npm install vhp-api

This brings the most updated (newest publish date) package. Specific versions can be installed by vh-api@. Updates to the package will be logged with their version for reference.

Once the package is installed you can go to the top of a file that needs the interface and destructure VAPI from vhp-api.

const vapi = require('vhp-api);

vapi will now hold the entire module and is currently structured as follows: { Core, Store:{ Mart, JMart } } If a service is added it will follow the current structure of nesting. An example is the Store object. It holds two classes dealing with different database or data generally. This nesting allows us to import the Store branch if we only wanted to deal with data, and leave the other services behind. ` const {Store}=require('vhp-api);

let datamart = new Store.Mart({});

`

Core

At the base there is the "Core". At the core we can handle login, pings, authentication information, and the actual sending of requests. The Core can be used alone to make general calls, or extended to create custom calls. An example of extending the Core is found later, as most all the services are based on the core.

Core Outline

properties

host auth connected client config dev

methods

Ping() Login()

GETuser() GETuserinfo() SETuserinfo()

SENDrequest() REQUESTserver() REQUESTclient()

Core Setup

To use we can initialize a new Core class that takes the following aruguments to adjust its function:

read format => : ()

constructor

({ auth:{ user : String ('') pswrd : String ('') } ({}) sync : Boolean (true)

config:{ https : Boolean (false) comments : Boolean (false) }

client : Boolean (true)

dev:{ https : Boolean (false) comments : Boolean (false) } ({}) })

auth

Auth is there to quickly pass authentication to the Core. If nothing is passed, auth defaults to null and then initializes the core's This is not a needed field if the sync flag is kept at 'true'. The behavior of "sync" will be discussed later. Even if sync is

host

The host will hold the core's url. This does not mean it has to be the url used for all calls, as it is possible to pass a different url to the core's request funtion. This host will be the default path when no path is passed for any request from the Core. Since the core is built as an interface to the portal, the result of using another host is unpredictable.

sync

Sync is a property to let the initialized Core know that it needs to share the authentication and status with all of created Core classes. When a true value is passed to the constructor and nothing was passed to the auth, the auth will be set to whatever the shared authentication is. If user and pswrd where passed through auth, and the sync is true, it will attempt to Login using the authentication. A failed authentication will not be shared, but a valid one will.

connected

The connected property carries a true | false value depending if the connection to the portal has been established and is healthy. Connected is attached to the the SENDrequest, and is updated when a request failes to connect.

client

The client is used to tell the core whether request will be made from the browser or a server. If true the request will use the fetch api from the browser, and if false it will use the https module in node. There is not currently a way to send http request from the server.

config

Config will hold many different flags or values to control how the Core acts.

• https - lets the core no the calls are to a url https://. It is important to be able to navigate certificates.
• comments - a way to turn on and off the console.logs. This only exposes the basic console.logs. If more visibility is needed, the 'dev' flag can be set true.

dev

This can be set to true exposeing some features that help develop the module

Ping()

Using the ping function simply checks a connection to the portal. It should not be used if trying to ping another server. This function can be used to quickly establish a connection with the server before any further calls or authentication is made.

arguments:( full : Boolean (false) - decides the content returned )

returns - if(full) - { call: The response from server status: status of the Core } if(!full) - the reposnse.msg from server | false if failed

Login()

The login can be used to authenticate the Core (or all cores). When syncing the core you only have to login with one of the created cores for all synced cores. If authentication is not set during initialization the Login function will be required before sending any other calls to the portal. The function can be used instead of calling the Ping function first, this function can also establish the connection with the server.

arguments

( user:{ user: username pswrd: password } (null) )

returns

true - successful login false - failed login

GETstatus()

A way to check the status of the Core. if synced, this will represent all synced Cores

arguments

returns

{ syncing : Core.sync, auth:{...Core.auth}, connected:Core.connected }

GETauth()

A way to see the authentication of the Core. If synced, this will represent all synced Cores

arguments

returns

{ Core.auth }

Mart

The mart is used for connecting with the data that we have on the server. This would be different than the data we 'ask' JONAS for, or the furture connections to other external databases. When making any calls to the vhp-mart you will format the following pack:

pack:{ collect: 'collection name' store: 'store name' db: 'database name' methd: '[QUERY](#query) | [REMOVE](#remove) | [INSERT](#insert) | [UPDATE](#update)' options: {content depend on method. list below} }

All of the following models can be expanded on using the nedb documentation

QUERY

options

{ query:{} }

returns

body:{ result:[] || null }

notes

Query is pretty straight forward. The above options would return all the the items in a table. Any property of the object can be added to the query with a value to match with. If there is no error body.result will always be in the form of an array, even if the query would only result in one item.

REMOVE

options

{ query:{id:'itemid'} multi: TRUE || FALSE }

returns

{ body:{ result:{ err:null || err, num: (int) } } }

notes

Remove is very similar to query in that it needs values to be passed for matching. It would be possible to remove all the items from a table, but this action is reserved for admin users.

UPDATE

options

{ query:{id:'itemid} update:{$set:item} options:{} }

returns

body:{ result:{ err : null || err, numrep : int } }

notes

'id' could be any property of the object and carry any value to match the desired document(s). Update (the property) is where you can describe what gets updated on the object. The example above will replace the whole object found using query with the object passed to item. Options can carry flags like multi: true | false. If only one item is being dealt with, passing {} will default multi to false. When possible send a request that updates multiple items instead of request to update an item at a time. This will be important when dealing with large list.

INSERT

options

{ docs: [items] || {item} }

returns

body:{ result:{ err: null, docs: [] } }

notes

Anything can be inserted into any table as long as it meets an "ensure" requirements. An example would be a table is ensured to have a unique value of 'id'. When an item is inserted it recieves an _id property that is guarunteed to be unique and can be used to track/query specific items.

CALLING -> request:'ADMIN' ---------------------------------------------------->

pack:{ collect: 'collection name' store: 'store name' db: 'database name' method: 'ADDCOLLECTION | REMOVECOLLECTION | COLLECTIONMAPS | ADDSTORE | REMOVESTORE | ADDDATABASE | REMOVEDATABASE' }

method: 'ADDCOLLECTION'

• required - pack.collect: collection name (valid) that does not already exits.
• return

method: 'REMOVECOLLECTION'

• required - pack.collect: existing collection name
• return

method: 'COLLECTIONMAPS'

• optional - pack.collect: if existing collection name, for single map
• return

method: 'ADDSTORE'

• required - pack.collect: existing collection name - pack.store: store name (valid) that does not already exists.
• return

method: 'REMOVESTORE'

• required - pack.collect: existing collection name - pack.store: existing store name
• return method: 'ADDDATABASE'
• required - pack.collect: existing collection name - pack.store: existing store name - pack.db: database name (valid) that does not already exists
• return method: 'REMOVEDATABASE'
• required - pack.collect: existing collection name - pack.store: existing store name - pack.db: existing database name
• return

<------------------------------------------------------------------------------>

JMart