Tools: Extending polyserve server

[jlndk]

In my latest project i found the need to extend polyserve, with extra routes. I think it would be a really valuable tool, when you develop polymer elements, that depends on some backend techologies, like WebSocket.

I found out that this could easily be done, by returning the server variable from the startServer() function. It's an easy fix, that would make development so much easier.

[jlndk]

I would propose returning a callback with the (express)app and server

startServer.js, in the polyServe package:

function startServerWithPort(options, callback){
    //Start server

   callback(app, server);
}

server.js, that extends polyserve:

var polyServe = require("polyserve");

polyServe.startServer(options, function(app,server){
    //Do whatever you want to extend the server
});

[joao-parana]

@jlndk, can you explain your WebSocket use case ?

[jlndk]

Im currently using the WebSocketServer module in Node Js, to test my WebSocket polymer element.
I've currently found a workaround, by copying the startServer function from PolyServe, and adding a callback, as the last parameter, as i explained before.

So my code looks like

var polyServe = require("polyserve");

// This function is copied directly from the polyServe npm package
function startServer(options, callback){
    //Standard polyServe code, creating app and server, using polyServe.makeApp()

   callback(app, server);
}

var server = startServer(options, function(app,server){
   //Here i use the server created by polyserve, and attatch the websocket server
    var socketServer = new WebSocketServer({server: server});

    socketServer.on("connection", function(){
        //Generating sampledata
       socketServer.send(sampledata, function(){});
    });
});

But i think that this isn't the only usecase. If a developer quickly needs to add routes to PolyServe, while creating a element, i think that it should be possible.

[justinfagnani]

makeApp is how I've been embedding polyserve into other apps. If that's not sufficient for this use, maybe we can decompose startServer into more reusable bits. It's still useful to notify when startServer has completed, but I'd rather do that by returning a Promise.

[jshcrowthe]

I have found also that, when building web components that require API interactions, there are times when I want to make requests relative to the current host (Think a UI piece that works on several different env's mounted at different subdomains but the same path).

Say for example I have an my app (with an api mounted at /api) that has 3 specific environments

• dev.myapi.com (dev)
• beta.myapi.com (beta)
• myapi.com (prod)

Instead of hard coding a URL I would make a request to /api to ensure that regardless of the env that the component is deployed in it will make a request to the proper API server.

Although I can do this programmatically without too much hassle it would be nice if we could provide a polyserve-config.json or something of the like that would allow developers to add proxy routes to their components. That way any developer who is using the CLI polyserve command to do their development (or doing it programmatically for that matter) would have the same API routes pre-configured for their component.

Thoughts?

[justinfagnani]

There are more complications when trying to access a hosted service than polyserve can handle. URLs may need help to be stable under vulcanize, services may require authentication, etc. The right approach is to allow polyserve to be embedded in a custom server, which is possible via makeApp. With startServer now returning a promise (in 0.5, about to be released) I'm going to close this as fixed.

[joao-parana]

Now we can use this:

polyserve.startServer({
  port: argv.p,
  page: argv.o,
  host: argv.H,
  browser: argv.b
}).then(function(server){
  console.log("polyserve loaded and ready");
  // something useful here ...
}).catch((e) => {
  process.exit(69);
});

Tanks @justinfagnani for 0.5 release.

[azariah001]

So as yet this use case for PolyServe doesn't appear to be documented anywhere...... other than here in a bug report. :disappointed: To the point that the startServer function is now marked as deprecated....? I hope startServers has the same core functionality... I'll investigate later.

But regardless. Here today is how to use PolyServe as a "drop-in" "replacement" for Express pre-configured to deal with Polymer 3 and the new module syntax.

````js
//> polymer-starter-kit/app.js
/* this works as a drop in file into the polymer starter kit.

• You will probably/definitely want to make some changes
• to the default folder structure, especially if you want to use
• some server-side template magic in conjunction with
• with polymer on the client side.
  */

const polyserve = require('polyserve');

polyserve.startServers({
port: undefined, // defaults to 8081: adjust as necessary
page: undefined, // defaults to '/' which by default is mapped to the index.html file in the project root
host: undefined, // defaults to localhost: you should be deploying behind an nginx proxy so you probably won't ever need to change this.
browser: undefined, // supposed to auto open your default browser, doesn't work under linux so mileage may vary
moduleResolution: "node", // absolutely essential you won't get anywhere without this line.
npm: true, // also important
lint: { // probably not necessary
rules: [
"polymer-3"
]
}

}).then(function(server){
console.log("polyserve loaded and ready");

// put all of your express extension code here like .use() etc. using server as your express session.

}).catch((e) => {
process.exit(69);

});
````

[mercmobily]

I know this is a closed issue on a barely supported file, but... I had no luck with makeApp. What worked for me, perfectly, was getApp()
If I use makeApp, I am getting a resounding "undefined"
I am doing this:

````
var startServer = require('polyserve/lib/start_server.js')

// .. various routes in my application, and then...

if (process.env.NODE_ENV === 'development' || !process.env.NODE_ENV){
var polyserveApp = startServer.getApp({
moduleResolution: 'node',
npm: true,
})
app.use(polyserveApp)
} else {
var prplHandler = prpl.makeHandler('build', polyConfigFile)
app.get('/*', (req, res, next) => { prplHandler(req, res, next) })
}
````

This means that in development I use polyserve, which is awesome AND -- more importantly -- it resolves module names correctly.

I can't imagine why this is not documented. Anybody who works on a project based on the PSK is expected to wait 30 seconds to build their software, before they can test every tiny change?

Doesn't this need to be documented?

[mercmobily]

@justinfagnani I know you are probably busy with more important stuff, but your input of this would be very beneficial. Would you support a PR that adds this to the docs? Plus can you confirm my suspicion -- that makeApp is not the way to go, and getApp is?

[krumware]

This is just what I was looking for. It would be great if this was documented!

[krumware]

Worked like a charm. Here is the source location for additional options: https://github.com/Polymer/tools/blob/master/packages/polyserve/src/start_server.ts#L40

[mercmobily]

This is a buried helpful thing in a buried closed issue. Which is a shame. It will hopefully grab the attention of a core developer.