Fork me on GitHub
#untangled
<
2016-08-15
>
cjmurphy03:08:56

Regarding deploying webapps where apache2 is the front end to the Internet. Once a webapp server process is up and running there's an extra step that a file in /etc/apache2/sites-enabled needs to be altered to do the final routing to the outside world. For Scala.js and Sente server processes the following approach has worked fine:

ProxyPass /app-name 
 ProxyPassReverse /app-name 
However this approach doesn't work with Untangled. I can deploy one Untangled webapp. But I can't seem to be able to deploy more than one. I always get stuck at the point where messages to the Chrome dev console say that /api can't be found. I don't want /api to be looked for, but rather /app-name/api.

grzm13:08:26

@cjmurphy: It looks like you can supply a different networking object to the untangled client which allows you to specify the server endpoint it talks to: https://github.com/untangled-web/untangled-client/blob/master/src/untangled/client/core.cljs#L20

grzm13:08:10

On the untangled-server side, it looks like the route is hard-coded in the handler, though there may be a way to fake it with supplying extra routes. Or fork untangled-server. Or just use the Om Next library directly in your own backend.

tony.kay18:08:51

@cjmurphy: You could use mod_rewrite. You're generally correct that we could provide more customization of the URL supported by the webapp itself. You could do as @grzm suggests. Not difficult, either. I'd be glad to entertain a PR on untangled-server to configure the API endpoint via the configuration file. It is a relatively simple change, since the config is injected. My basic approach at the moment would be to suggest offloading this as an operation concern (e.g. mod_rewrite).

tony.kay18:08:34

ah, but you'd need at least virtual hosting. In other words route to the apps by vhost name instead of path in URL

grzm19:08:25

I'm updating initial state, passing in a current-user id in a method similar to that laid out by the open-id client (https://github.com/untangled-web/untangled-client/blob/master/src/untangled/openid_client.cljs)

grzm19:08:13

I then get a warning when I also add an initial state to my root element. Is there a better way for me to get the current-user id into the app state?

grzm19:08:19

I guess I could just take the all the initial app state that I would put in the initial element and also inject that at the same time I'm adding the current-user, though that seems kinda hacky.

grzm19:08:37

@tony.kay: any reason you use clz instead of this when referring to the component in initial-state function definitions?

tony.kay20:08:44

@grzm to stress the fact that it is created initially, which means you're passing in the component class, not a component instance (from a factory).

grzm20:08:22

@tony.kay: What's the mnemonic? Class?

tony.kay20:08:29

ah, yes...class

tony.kay20:08:48

I'm allergic to using the word class, since it is reserved in so many languages 😉

grzm20:08:54

Understood 🙂

grzm20:08:10

It's a departure from the use of this for all of the the other static functions like IQuery/query, which confused me at first.

tony.kay20:08:25

@jasonjckn: not sure why that would be.

tony.kay20:08:19

@grzm My thinking was that ident, for example, is used with component instances...e.g. with data plugged in.

jasonjckn20:08:52

it's interesting how it does it just for the first key in the vector

tony.kay20:08:15

@grzm you need that extra arg because it is a protocol, but since it is "static", it is a little odd with respect to the OOP ideas.

tony.kay20:08:32

you could be passing the class as the "instance", or an actual instance

tony.kay20:08:46

@jasonjckn: It was a pretty simple change, so I'm not sure why it would not work right. Feel free to submit an issue. I've been crazy busy, so if you see the problem feel free to send a PR

grzm20:08:02

yeah, ident is a little strange

jasonjckn20:08:10

yah I tried to see if it was a quick fix, but on first inspection the source code looked right

jasonjckn20:08:23

i'll maybe take another look

jasonjckn20:08:35

not a huge deal eitherway

tony.kay20:08:21

perhaps your diff alg is off?

tony.kay20:08:11

Remember that the global marker (at the root) is still set

tony.kay20:08:55

@jasonjckn: I'm not familiar with your app or output...

jasonjckn20:08:24

my diff algo is your diff algo from untangled-spec

jasonjckn20:08:35

i think the marker is definitely there

tony.kay20:08:37

ah...well, isn't it just showing the global marker?

jasonjckn20:08:53

what's the global marker? ui/loading-data?

jasonjckn20:08:19

yah that show sup in the diff algo too, but i don't care about that, I care about how :env-vars is getting a marker

tony.kay20:08:19

marker false means you don't want loading markers placed where the data is targeted

tony.kay20:08:30

The global marker is for showing a global "loading/network" indicator

tony.kay20:08:37

the latter is always updated

tony.kay20:08:01

e.g. load-field would put a loading marker on some deep spot in your app state

jasonjckn20:08:12

there's the marker that shows up, even with :marker false

jasonjckn20:08:49

here's the code

(df/load-data reconciler [:env-vars :login-profile :entitlements] :marker false)

tony.kay20:08:55

yeah, that does look like a marker inside of your data

jasonjckn20:08:57

as I said it only shows up for :env-vars interestingly

jasonjckn20:08:12

the other keys are loaded without markers

tony.kay20:08:04

Yeah, submit an issue on it. I think the code may be only touching the first thing queried...which might be a separate issue.

tony.kay20:08:38

I don't remember...I assume you've checked that :marker is the correct option name 🙂

jasonjckn20:08:54

i'll create an issue, yah I checked that