Implement run_server for setting host and port in Dash.jl

[rpkyle]

In Python, the Flask server is launched via app.run_server; R launches the Fiery server in almost identical fashion (replacing the . with a $):

    app.run_server()

Dash.jl should have a run_server interface that launches the HTTP server, which initially supports the following two parameters:

• host = a character string which specifies a valid IPv4 address for the HTTP server
• port = an integer which specifies the port number on which to listen for HTTP traffic

We should remove make_handler and move this logic into the Dash.jl internals. We should also move these existing Dash.jl arguments to run_server:

• debug

Eventually we will need to support other arguments to run_server, but we can discuss that further once these tasks are completed.

[waralex]

At master:

run_server(app[, "0.0.0.0", 8080, debug=true])

make_handler still exists, but removed from the public api

[rpkyle]

At master:

run_server(app[, "0.0.0.0", 8080, debug=true])

make_handler still exists, but removed from the public api

Since we've gone ahead with providing app.layout =, is it possible to provide a similar interface here? For example:

app.run_server("0.0.0.0", 8080, debug=true)

This would arguably be more consistent with both app.layout as well as the Python and R interface.

[waralex]

Since we've gone ahead with providing app.layout =, is it possible to provide a similar interface here?

It's not similar. app.layout = .. is setting the property, app.run_server is the method call. Julia doesn't have methods encapsulated with structures, i.e. there are no classes that you are trying to see :) - this is one of the key design elements of this language. In fact, app. layout = ... is a strange solution from Julia's point of view too. It is much more logical to use ' layout!()`

app.run_server("0.0.0.0", 8080, debug=true)

It looks like "let's write Python on Julia". This, of course, is possible, because Julia is much more powerful and flexible than Python, but we have a different task, don't we?

[rpkyle]

Since we've gone ahead with providing app.layout =, is it possible to provide a similar interface here?

It's not similar. app.layout = .. is setting the property, app.run_server is the method call. Julia doesn't have methods encapsulated with structures, i.e. there are no classes that you are trying to see :) - this is one of the key design elements of this language. In fact, app. layout = ... is a strange solution from Julia's point of view too. It is much more logical to use ' layout!()`

app.run_server("0.0.0.0", 8080, debug=true)

It looks like "let's write Python on Julia". This, of course, is possible, because Julia is much more powerful and flexible than Python, but we have a different task, don't we?

A similar situation has occurred when using R as well -- the syntax for app$callback in R passes the callback function in as an argument, since base R lacks decorator methods (not counting the tinsel package), while Python supports them.

I think you're correct that we want to avoid providing Julia users an interface that will appear entirely alien to them, even if it means that the syntax is even more distinct from the original implementation than the one R currently provides.

If run_server(app[, "0.0.0.0", 8080, debug=true]) is most intuitive for Julia users, I'd be inclined to go with that, even if it looks strange to a more experienced Dash user/developer.

I'm curious if @alexcjohnson or @chriddyp have other thoughts.

[waralex]

If a Dash user starts using it in Julia, they will need to master Julia anyway. Even if the Dash api is 1 in 1 like in Python, it needs to learn the principles and ideology of Julia in order to work with the data that is used in the dashboard, for example. And if Dash is different from Julia's standards for being like in Python, it will be much more of a hindrance than a help

[rpkyle]

Thanks for adding run_server, this looks great as-is. I'm going to close this issue, since I think we're all set here. 💃