| Home | CHANGELOG | VHP Portal | DEV Portal |
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, desktop and service.
To get started import the package using npm:
npm install vhp-vapi-client
This brings the most updated (newest publish date) package. Specific versions can be installed by vh-api@
Once the package is installed you can go to the top of a file that needs the interface and destructure VAPI from vhp-vapi-client.
const vapi = require('vhp-vapi-client)
vapi will now hold the entire module and is currently structured as follows:
{
Core,
ClienManager,
lib
}
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 { ClientManager } = require('vhp-vapi-client');
let datamart = new ClientManager({});
The client manager is class to be used to manage multiple connections. It acts as a singleton class, and shares the same connection across the application. The management part comes in because it:
All of the management can be controlled by the config passed to the Client Mangager
{
auth:{type:Object, default:{user,pswrd}},
host:{type:String,default:null},
dev:{type:Boolean,default:false},
config:{type:Object,default:{}},
client:{type:Boolean,default:true},
desktop:{type:Object,default:false},
vapi:{type:Array, default:[]}
}
Properties
Methods
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
The host will hold an api’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. If nothing is passed the host will either be https://vhpportal.com/ OR http://dev.vhpportal.com/. This will depend on the value of dev. Dev=true, then http://dev.vhpportal.com/ is used. The host will always be appended with “api/”. Doing this locks it into using the VAPI only.
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.
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.
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 will hold many different flags or values to control how the Core acts.
This can be set to true exposeing some features that help develop the module
This is an object to hold “routes” and “invoke”. If nothing is passed you are saying that there is no desktop to connect to. If passed, routes will hold the available routes and invoke holds the connection to the electron IpcRenderer.invoke() process. All of this will be used to route client request.
simple array to hold all the available routes for the vapi connection
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.
(
full : Boolean (false) - decides the content returned
)
if(full) - {
call: The response from server
status: status of the Core
}
if(!full) - the reposnse.msg from server | false if failed
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.
( user:{ user: username pswrd: password } (null) )
true - successful login false - failed login
A way to check the status of the Client manager. if synced, this will represent all synced connections
{ syncing : Core.sync, auth:{…Core.auth}, connected:Core.connected }
A way to see the authentication of the Core. If synced, this will represent all synced Cores
{ Core.auth }
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:{}
}
body:{
result:[] || null
}
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.
{
query:{id:'itemid'}
multi: TRUE || FALSE
}
{
body:{
result:{
err:null || err,
num: (int)
}
}
}
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.
{
query:{id:'itemid}
update:{$set:item}
options:{}
}
body:{
result:{
err : null || err,
numrep : int
}
}
‘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.
{
docs: [items] || {item}
}
body:{
result:{
err: null,
docs: []
}
}
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’
method: ‘REMOVECOLLECTION’
method: ‘COLLECTIONMAPS’
method: ‘ADDSTORE’
method: ‘REMOVESTORE’
<——————————————————————————>