Refresh of setup documentation needed

[tony-shannon]

Need refresh of set up documentation

Some recent threads of note

/////
[10:32:50] Simon @ Root Solutions: Thanks, I've forked this and will make changes here.
[10:39:23] Simon @ Root Solutions: Just installed locally on my mac and running under localhost. Get the following error when accessing a patient dashboard: "Error 400: synopsis has not yet been added to middle-tier processing"
[10:40:46] Simon @ Root Solutions: Does the ripple middleware need to be installed locally?
[10:55:36 | Edited 10:57:30] Bogdan Shcherban: [10:39] Simon @ Root Solutions:

<<< Just installed locally on my mac and running under localhost. Get the following error when accessing a patient dashboard: "Error 400: synopsis has not yet been added to middle-tier processing"It is because some requests can't work locally until we change them. What should you do, if you want to run this project locally:

1. Add requests from attached file to paths, which are written above each request code;
2. Login to http://dev.ripple.foundation:8000/
3. Copy token from http://dev.ripple.foundation:8000/api/patients/9999999000/synopsis/top3Things to the path:
   /src/config/for-test.constants.js
4. Restart NPM
   [11:57:41] Simon @ Root Solutions: Thanks Bogdan, this works!
   [11:58:14] Bogdan Shcherban: You're welcome!
   [11:58:53] Simon @ Root Solutions: Are there plans to get it running in dev without the need to make code changes?
   [12:01:08] Bogdan Shcherban: It is necessary to ask Rob about it. Because it isn't conveniently - change the code each time when we want to make some changes in the code.
   [12:02:08] Rob Tweed: What's the question?
   [12:05:11] Bogdan Shcherban: Each time when we want to run the project locally - we should change requests for Demographics and Headings (Allergies, Contacts etc.). And it is usually possible to forgot about this changes before commiting.
   [12:06:52] Rob Tweed: When you say "run locally" what do you mean? The APIs expected by the QEWD Middle tier are the APIs expected to be sent by PulseTile. If you're replacing the middle tier with something else locally, then that alternative back-end should emulate the same APIs. PulseTile shouldn't have to be changed
   [12:08:07] Rob Tweed: SO there's nothing I can do about it - the QEWD / Helm / Ripple APIs are the APIs that you should be working against - end of
   [12:08:54] Simon @ Root Solutions: Hi Rob, so is the best approach when working on PulseTile on localhost to also run the middle tier locally?
   [12:09:16] Rob Tweed: WHat are you running it against locally otherwise? I don't understand
   [12:09:43] Rob Tweed: I don't understand what you mean by "running locally"
   [12:10:31] Simon @ Root Solutions: I'm just running npm start of PulseTile-React on my mac.
   [12:10:45] Simon @ Root Solutions: viewing pulsetile on localhost:3000
   [12:10:55] Rob Tweed: PulseTile should be designed to work against the APIs provided by the Helm / QEWD Middle tier. Either you run PulseTile against an instance of the actual QEWD Middle tier, or you run it against something that emulates the exact same APIs and emuates their behaviour.
   [12:11:29] Simon @ Root Solutions: For the purposes of UI development, the data can just be emulated I think.
   [12:11:33] Rob Tweed: Otherwise how can it be expected to work? I don't understand what you're attempting to do
   [12:12:06] Rob Tweed: Well if you're emulating the back-end, then you need your emulation to behave exactly the same as the actual back end that PulseTile is designed to expect
   [12:13:38] Rob Tweed: ALternatively you did see my instructions on how to set up a local instance of the QEWD platform, right? It's just a set of Docker Containers that you fire up according to my instructions, and you have a local platform you can use for development
   [12:15:21] Simon @ Root Solutions: Was that on a Skype? Not sure I have that to hand. Can you resend please?
   Rob Tweed
   [12:23:09] Simon @ Root Solutions: Thanks Rob. So once this is up and running, should PulseTile run on localhost or the Ubuntu VM?
   [12:24:36] Rob Tweed: The PulseTile UI files are served up by the conductor-service-phr container. The repo already contains a copy of the files, but you'd just replace them with your latest version
   [12:24:53] Rob Tweed: See https://github.com/RippleOSI/Ripple-QEWD-Microservices/tree/master/conductor-service-phr/www
   [12:35:01] Simon @ Root Solutions: So would we just drop the PulseTile-React/src folder in here? These files look different. https://github.com/LeedsCC/PulseTile-React/tree/master/src
   [12:35:56] Rob Tweed: What you drop in there are the built files, not the source files - they need to be the versions that actually run in a browser
   [12:36:28] Rob Tweed: but yes - all you do is drop the built files into that folder
   [12:37:23] Simon @ Root Solutions: So presumably we'd need to update the npm scripts which build from src so they build to this location instead?
   [12:37:48] Rob Tweed: You need to decide how that would have to work
   [12:41:00] Simon @ Root Solutions: OK, sound like this might need a bit more thought. Maybe a quick alternative would be to run the midldeware on a cloud server then reference it in the PulseTile config and run that locally?
   [12:42:37] Rob Tweed: Whatever happens, we need a set of pre-built files that can be dropped into an instance of that conductor-service-phr container's folder
   [12:43:53] Rob Tweed: Anyone running the Helm PHR will be running the microservices as described in that document, and your PulseTile UI files will be served up from this container
   [12:44:45] Rob Tweed: I suggest you set up an instance by following the instructions in that document so you can see for yourselves how it all works for real, and you can then figure out what you need to do
   [13:00:02] Simon @ Root Solutions: Thanks Rob. Bogdan, what would you suggest as the best way forward?
   [13:09:30] Bogdan Shcherban: In Core project we have two places for build location:
   folder '/dist' - for the last build
   folder '/build' - for builds storage

But in LeedsCC we can see only the second. But we can take any of these zip-archives and unpack them
[13:09:54] Bogdan Shcherban: Later I will see, why dist folder is absent here. It must be
[13:17:55] Simon @ Root Solutions: Yes, /dist isnt' being generated on my copy either, although I can see it's defined in webpack.config.dev. Assuming we set up the server suggested by Rob, shouldn't we just update const buildPath = path.join(__dirname, 'dist'); to the www share path on the VM?

/// what lessons can we learn from this

[tony-shannon]

this is a few related notes from @simongamester

PulseTile-React Setup Notes

Clone / Download from Github
Then…

Just installed locally on my mac and running under localhost. Get the following error when accessing a patient dashboard: "Error 400: synopsis has not yet been added to middle-tier processing"
It is because some requests can't work locally until we change them. What should you do, if you want to run this project locally:

1. Add requests from attached file to paths, which are written above each request code;
2. Login to http://dev.ripple.foundation:8000/
3. Copy token from http://dev.ripple.foundation:8000/api/patients/9999999000/synopsis/top3Things to the path:
   /src/config/for-test.constants.js
4. Restart NPM
   File below…

-- LOGIN AND PASSWORD

[email protected]
IvorCox1!

-- DEMOGRAPHICS
/src/ducks/fetch-patient-demographics.duck.js

export constfetchPatientDemographicsEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_DEMOGRAPHICS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/demographics/${payload.userId}, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientDemographicsSuccess({
userId: payload.userId,
demographics: get(response, 'demographics', {}),
}))
);

-- SYNOPSIS

/src/components/pages/Allergies/ducks/fetch-patient-allergies.duck.js:

export constfetchPatientAllergiesSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_ALLERGIES_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/allergies, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientAllergiesSuccess({
userId: payload.userId,
allergies: get(response, 'synopsis', []),
}))
);

/src/components/pages/Contacts/ducks/fetch-patient-contacts.duck.js

export constfetchPatientContactsSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_CONTACTS_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/contacts, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientContactsSuccess({
userId: payload.userId,
contacts: get(response, 'synopsis', []),
}))
);

/src/components/pages/Diagnosis/ducks/fetch-patient-diagnoses.duck.js

export constfetchPatientDiagnosesSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_DIAGNOSES_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/problems, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientDiagnosesSuccess({
userId: payload.userId,
diagnoses: get(response, 'synopsis', []),
}))
);

/src/components/pages/Medications/ducks/fetch-patient-medications.duck.js

export constfetchPatientMedicationsSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_MEDICATIONS_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/medications, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientMedicationsSuccess({
userId: payload.userId,
medications: get(response, 'synopsis', []),
}))
);

/src/components/pages/TopThreeThings/ducks/fetch-patient-top-three-things.duck.js

export constfetchPatientTopThreeThingsSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_TOP_THREE_THINGS_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/top3Things, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientTopThreeThingsSuccess({
userId: payload.userId,
topThreeThings: get(response, 'synopsis', []),
}))
);

/src/components/pages/Vaccinations/ducks/fetch-patient-vaccinations.duck.js

export constfetchPatientVaccinationsSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_VACCINATIONS_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/vaccinations, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientVaccinationsSuccess({
userId: payload.userId,
vaccinations: get(response, 'synopsis', []),
}))
);

-- FEEDS

/src/components/pages/Feeds/ducks/fetch-feeds.duck.js

export constfetchFeedsEpic = (action$, store) =>
action$.ofType(FETCH_FEEDS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/feeds, {
Authorization: 'Bearer '+testConstants.token
})
.map((response) => {
return fetchFeedsSuccess({ feeds: response })
})
);

[tony-shannon]

other points from @simongamester

Docker & Vagrant repo couldnt be used to set up
@simongamester please update on that here

[tony-shannon]

According to Simon;
He followed the PulseTile install instructions, it set it up on localhost, but no dummy data was available,
(A API test harness is needed & we provide that from QEWD)
So for deploying PulseTile to develop against in, in localhost setting while accessing the relevant APIs..

Simon could have used QEWD microservices setup (inc www PulseTile files) but he wouldn't know how

So the challenge for Simon is to have a Pulsetile set up that allows him to make local changes and for them to interact with the qewdAPIs without having to move them to qewd MS www folder every time

So Simon needs a way to install PulseTile locally, easily , make changes and then deploy them in such a way that he can test them against the QEWD APIs without having to move files around

NPM is clever and may be able to do that for him
Docker may also help

[tony-shannon]

@pacharanero can you please take a look at this thread above, help understand @simongamester challenges and help out line how to tidy this approach up?

[pacharanero]

@tony-shannon yes sure. Can you ping me contact details for Simon please and I'll see if I can arrange a quick call with him.

BTW What was the above conversation from? a Skype conversation? Or Gitter? What is our 'preferred' channel for support or Ripple Stack issues

[simongamester]

Hi @pacharanero I suspect the solution to running PulseTile locally would be solved using your Vagrant Docker approach in https://github.com/RippleOSI/Ripple-Stack-Vagrant-Docker. I've tried installing this on my mac, however I've encountered some error with the VagrantFile.

One solution that comes to mind would be to:

1. Clone the PulseTile repo as is and use npm to install and build (npm installl; npm start).
2. Implement a config option within PulseTile to specify the location of the api for QEWD. This may already be in place, however there's no reference to where this is in the readme.

[simongamester]

Hi @pacharanero just sent you a contact request on skype.

[tony-shannon]

thanks both,

@pacharanero that thread happened on Skype, but would suggest we move some of this to
https://gitter.im/Ripple-Foundation/PulseTile
or to our Core Team channel on Gitter

[pacharanero]

@simongamester what you propose here is exactly what we need to do IMO

implement a config option within PulseTile to specify the location of the api for QEWD. This may already be in place, however there's no reference to where this is in the readme.

I think it might be this setting const DEV_SERVER_URL = 'http://46.101.95.245'; in webpack.config.dev.json
but I can't find any documentation and have been unable to confirm if it is.