We followed some counsel to augment our Visual Studio 2013 installation with “node.js” tools, with a view to running NAR’s open source webapi server.
We learned about NAR’s open source material from a member’s only resource:
which referred to
Using these sources and the knowhow taught by bloggers, we launched visual studio with a view to getting the point where we can run and debug the NAR webAPI server. This required using git, in visual studio, to clone the repository for the reso-api-server and then make a new node.js project, that imported the (existing) repository files.
Using the npm tools, we download the referenced packages. Next we followed the instructions to get the main package:
we had to change the dependency type from the default (and chose GLOBAL) to avoid the error shown in the console, left.
This all teaches us that perhaps we are going down the wrong path – not know what Global even is, etc.
So we start again, simply creating a new node.js application, to which we install the reso-api-server as a standard package. Then we following the metadata and configuration setup instructions:
we take a guess at some reasonable configuration parameters:
# Configuration file for a RESO API Server
# API Service
SERVER_NAME: RESO API Server
# Data Processing
# HTTPS Certificates
#AUTH_REALM: RESO API SERVER
# OAuth2 Services
Running the sample startup file, we get
we attempt to fix by taking the “alternative” configuration path, using the data dictionary package.
Augmenting the instructions, we consult
This fixes one startup issue, but then we hit a next – obviously related to SSL setup:
we install openssl (that NSA-friendly package full of strangely broken crypto and security protocols, supported by “american foundations”);
Several things seem to fix, on merely installing openssl (and adding the bin directory to the system path).
Without creating any ssl/ directory (or keys), and having adjusted the test.js and service.conf to be in the root project directory (and out of the metadata/ directory), we now get
which we guess means we are missing a mongodb server (listening on the port mentioned).
Lets guess, given the code below, that we followed bad instructions, initially – and somehow were not reading the correct files, in the right directories etc.
as it actually stands, after all this confusion:
a) we have a mongdb instance
b) a visual studio debugging instance of the node.js process (THAT evidently has a connection to a mongdb with zero entities).
at which point we seem able to boot a components hosting a couple of services