Demo

[gyachdav]

Hello there #PokemonGo,

It is time to see a live demo of your apps. You can either:

• Stage your demo on a hosting service

or

• Give a detailed explanation in your README how to run your apps.

Either way, we need to see that status of your project.

[sockeqwe]

@gyachdav I'm a little bit confused about the general setup / deployment of the project.
Our project is not really a stand alone project. I thought it will be integrated in Project A i.e. we write into Project A's database (direct database access, we don't communicate over a REST api with project A). Also, should we provide a public API? I thought this will be part of project A, isn't it? See #8

Since we are just generating data (no GUI), what kind of demo would you like to see?

[gyachdav]

@sockeqwe the output of the apps you build is indeed being integrated into project A. However it would be beneficial for us to be able to run even a command line version of your app and see what that output is. Furthermore it would be interesting to see what params and calls we need to make to get to this output. We also want to test your apps under different use cases. No public API is needed but some form of interaction with your app is required.

Keep in mind that you're suppose to create an NPM packages for each app. Project E is suppose to assist you with that. The NPM pack should allow us to deploy your app and the docs should give us a clear idea on how to run your app and what output to expect.

Hope this clarifies it a bit. Feel free to ping me some more in case I did not answer your questions or if you have additional questions or concerns.

[phdowling]

Hi @gyachdav. We currently have an index.html file which I use to debug the websockets output generated by e.g. the pokemob detection module. We could add some more functionality there (live sentiment tweets logging and showing the output of our sentiment trend module) and have this available as a standalone demo. All you would need to do to run is run node main.js to start the server, and open the index.html file somewhere and look at the console output.

Would a setup like that be okay to test our applications stand-alone?

Regarding the other points:

• I was thinking we can point project E to our main.js, which shows what modules one needs to import and how to start the different processes. The actual modules should then be imported through npm though (any good resources on how to easily package and publish modules there would be appreciated by the way!).
• We import stuff from project A as far as I see, so if project E requires both project A and our project, will things work out? for instance, would we actually end up referencing the same objects if they are global?
• who should import our code in the end? currently project A is somehow hosted, but from what I understand, in the end project E will import every other module and set up all the server logic centrally, right? this would be important to clarify.

[gyachdav]

@phdowling yup hat setup will be perfect.

I was thinking we can point project E to our main.js, which shows what modules one needs to import and how to start the different processes. The actual modules should then be imported through npm though (any good resources on how to easily package and publish modules there would be appreciated by the way!).

Keep in mind that project E is suppose to help you pack your apps. That's why they have 8 people there. summoning @PokemonGoers/catch-em-all .

Also keep in mind that project E is not going to import your apps. You will be running your listeners as a node process. the output from that process is stored on the project A database. @sacdallago can help you set up the process on the dev server. You will need to consult with @PokemonGoers/pokedata on how to store your output in their db.

We import stuff from project A as far as I see, so if project E requires both project A and our project, will things work out? for instance, would we actually end up referencing the same objects if they are global?

I don't see project E require project A, instead they will be making API calls to fetch data for the wiki portion of their webapp. Most of the API calls to project A's data will however be initiated by the map groups who will visualize sightings, predictions and pokemobs indications.

who should import our code in the end? currently project A is somehow hosted, but from what I understand, in the end project E will import every other module and set up all the server logic centrally, right? this would be important to clarify.

The only case in which I see your apps being directly integrated into E is the sentiment visualization component. This one will need to be provided as an exported module that can be required by E.

Let me know if this makes sense.

[sockeqwe]

Also keep in mind that project E is not going to import your apps. You will be running your listeners as a node process. the output from that process is stored on the project A database. You will need to consult with @PokemonGoers/pokedata on how to store your output in their db.

@gyachdav so we provide a npm library to project A (so project A is requiring our code) so that they can include our code?

concrete example:
We periodically query Twitter for tweets with tags to run sentiment analysis. This will run as a node process. So we provide a function to start this periodically sentiment analysis by packaging that as a npm library. Then Project A (as they are hosting the backend as far as I know) will require our function to periodically run sentiment analysis and Project A will start that function as a node process.
I thought about something like this:

// This function runs sentiment analysis periodically.
// this function is provided by our npm library, but will invoked by Project A in a own node process.
function runSentimentAnalysis(twitterCredentials, databaseConfig) { 
   // 1. Query Twitter REST API for tweets
   // 2. Sentiment Analysis on each tweet
   // 3. Save sentiments into database
   ... 
} 

Do we agree on that?

if yes, then, we also have to provide a REST api for the maps team where I would take the same road.
Provide some functions like this as part of the npm module:

function getSentimentFor(pokemonId, lat, lng){
    // Execute some Database query and return sentiment data over time
   ...
}

Then Project A will add a route to their express router:

router.get('/sentiment', function(req, resp){
   // Execute our function
   getSentimentFor(req.query.pokemonId, req.query.lat, req.query.lng);
   ...
}

Have I understood that correctly? If not, can you please give me a concrete example of what the architecture / communication should look like in your opinion?

I would also do the same for mobdetection etc. just provide a exportet npm module so that Project A can require our code.

[gyachdav]

Yup that sounds about right although you may elect to just run the node process separately from A. The rest of the architecture makes sense.

[phdowling]

@gyachdav Sounds good, I think we will probably go for the separate node process in the end - two issues remain with this though:

1. Will/can we be hosted on the same server as project A? If so, we could still access their mongoDB instance without actually running in the same process.
2. One of our Apps has a REST endpoint, while the other two only provide websocket endpoints. The REST API would have to be on a different port if we run a separate process. Is this acceptable?

Cheers

[johartl]

One of our Apps has a REST endpoint, while the other two only provide websocket endpoints. The REST API would have to be on a different port if we run a separate process. Is this acceptable?

At project E we have a little node server that intercepts requests to /api and proxies them to pokedata.c4e3f8c7.svc.dockerapp.io:65014. We would then do the same for requests to /sentiment and send them to the port where your application is running at. So the different ports shouldn't be a problem at all.

In terms of deployment I see two different approaches.

1. Both server applications can be packaged into the same Docker container which runs the two processes alongside each other and also exposes both ports. One team would need to write an entry script that launches the two server instances (and shuts them down gracefully upon receiving a stop signal). This would work just fine but is somehow inconsistent with Docker's philosophy of 'One application per container'
2. The HashPokemonGo team build their own Docker container. This is a lot cleaner but also requires a bit more work at first. The mongoDB instance can still be accessed even if it is running on a different host. I think in the current setup the PokeData Docker container and the MongoDB server are also running on different hosts. This might change in the final production setup though? @sacdallago can probably say a few words here.

[sacdallago]

@phdowling @johartl
I would strongly advise to keep the REST APIs to one (as in: when you are done building that part, simply coordinate with project A to integrate it directly in their API in some route). At the end of the day, you can write the entire logic to the controller and package it in an NPM package, then the only thing to do will be for A to create the routes and use your packaged functions. Even easier is if you write an express middle layer, then they would just need to add the express.use('/some/rute', myMiddleware) directive.

As far as mongodb: it's always best to separate logic from data, so yes: currently using a cloud mongodb instance, but I'm thinking of migrating to something in RostLab because of space (we only get 500mb for free).