I should pull fighweel in on the backend, not the other way round

[Martin-S-Weber]

figwheel is great, when you're on the front end. But sometimes you're developing something that needs frontend and backend simultaneously. For these cases figwheel offers serving my handler(s) as well.

That's the wrong order. I should be adding the figwheel routes to mine instead of adding mine to figwheel's. It should be me who decides what, where and how to serve these routes instead of figwheel deciding what, where and how to serve the rest of my application.

Figwheel doesn't comprehend my application - how could it? Figwheel itself though has clear boundaries, and is itself a well-defined module. So it should be treatable like a module - i.e., optionally pull it in, decide what you want to do with it - and not a framework.

[bhauman]

There is literally nothing that prevents you from doing this.

https://github.com/bhauman/lein-figwheel#scripting-figwheel

[bhauman]

Oh I see what you are saying you want to embed figwheel reloading routes into your server.

I only recommend that folks use figwheel to side-load your source code. Use your own server for your app. figwheel has no problem running as a separate communication channel (just like the repl).

[bhauman]

The quick start details this by having you start from the file system.

In short I agree with you completely and figwheel is designed to work this way.

[Martin-S-Weber]

Indeed, "scripting figwheel" and the recipe for using a "component figwheel", were what I was missing in the documentation when I looked. That should do, thanks for the pointers.

[Martin-S-Weber]

Alright, this was premature. Scripting figwheel does not seem to do what I want it to do.

It starts its own server. I explicitly do not want it to start its own server. I want to embed the figwheel-server into my dev application. Assume I'm deploying to wildfly, what business does lein-sidecar have to bring in http-kit, and launch a new backend?

It's my business to start the server, and wire up exposed routes with handlers (behaviour). Figwheel needs to be able to play along with the environment I'm giving it -- and not try to usurp it, or live next to it.

[bhauman]

Martin, Figwheel is a development tool that runs independently of your application like a REPL or a compiler. Do you wire up the endpoints for your Clojure REPL into your http server? The fact that figwheel uses a http websocket connection is incidental. I repeat that you are not required to use the :ring-handler to embed your application in Figwheel and I highly recommend that you don't. You should serve your application assets including your cljs from your own application server. Think of figwheel as a repl not a http service.

You application can run absolutely independently of figwheel and it will still work.

I'm not inclined to spend anymore time on this conversation.

[jplaza]

@bhauman do you have a sample application that shows how to accomplish this? I have my backend running on port 8000 (a legacy django application we hope to replace soon) but for the time being I want to start updating the UI incrementally. I'm going to use om.next, so I would like to be able to serve the compiled JS files from my backend and trigger the reload for localhost:8000 instead of localhost:3449 Does this make sense?