Fork me on GitHub
#fulcro
<
2018-09-13
>
pvillegas1211:09:26

How can I configure the port for the api fulcro communicates with when using localhost?

pvillegas1211:09:17

having trouble with defining a new remote and pointing the url to

tony.kay12:09:22

@pvillegas12 figure it out? You mean on the client or server?

tony.kay12:09:18

The client talks to whatever host/port you loaded it from

tony.kay12:09:43

The server port is configured via whatever http server lib you started it with (via config if using the built-in easy server)

tony.kay12:09:09

You can configure one of the pre-built http remotes for a client with a :url option (defaults to /api), and that is sent directly to (.send xhrio url ...) (from goog XhrIO)...restrictions for cross site security apply.

pvillegas1214:09:59

yeah @tony.kay, I did redefine the server endpoint in the client using config variables

claudiu19:09:23

@tony.kay Is there any support for fulcro ssr on nodejs. Seems to work but was wondering since it's js like in the client if it's possible to have an app (without mounting it) run df/load and transact! on the reconciler, then just get the state and render it ?

tony.kay21:09:31

Hey @claudiu. It’s an interesting approach: run the client in a headless environment in order to build state, then use that to run an initial render. The first big downside from my perspective is you then need to use node for your real servers in production 😜 I don’t have the funding or time to make such a thing work, but it probably would not be that hard. I don’t use node, so I don’t know what API differences there’d be in order to get the client running properly. If things like XhrIO already work, then I’d say there’s a good chance it would be possible to make it work with not too much effort.

tony.kay21:09:07

That said, you already have shared code from server/client, and building initial client state as a result is pretty trivial, AND results in you being able to run your production server on the JVM…so IMO you’d be gaining one kind of convenience for a ton of other pain. But like I said: not a node user, so I may be full of shit

tony.kay21:09:55

The more I think about it, the worse the idea sounds: - So, you run the headless client…how do you interface with it to render “other” pages??? - If your answer to (1) is “I just want it for the home page”, then build your initial state for the home page by hand…it’s one page. It can’t be that much code (and you’ve already written the functions that your loading is using to get the data…it’s really quite simple already) - If your answer to (2) is “I’ll just hook in x, y, z” to get other pages…then I don’t see how that is better, simple, or easier than building initial state by applying functions you’ve already written for normal operation.

tony.kay21:09:00

And if your answer is “I just want the home page” I’d not that you’re requirements are likely to change, and then you’ll need other pages…and then you’re back to my recommendation of “just build the state using shared functions”. The fulcro-template (not the lein one) shows the setup (with html5 routing, and support for ssr on any page). The initial state computation is not much more code than the apollo example, and it supports any number of routes trivially.

pvillegas1222:09:24

@tony.kay have you thought about how to expose an ion from the fulcro template using datomic cloud? Right now I’m having to split between the frontend assets and serving those separate from the API portion

tony.kay22:09:51

You have multiple remote support…isn’t that sufficient?

tony.kay22:09:25

you load the app and assets from one place, and point a remote at the other

tony.kay22:09:42

do you also plan to talk (via API) to both?

tony.kay22:09:01

if not, it’s just the :url config isn’t it?