Hi! We try to answer that question in the https://polylith.gitbook.io/polylith/conclusion/faq at the top.

so would you say that for a monorepo with both sides of an SPA (client and server) you would not recommend using poly at all? or would you go with using poly for the whole thing and it will just not understand the client as well or would you still use poly for the server side and leave the client side outside of poly management?

I did read the faq, it just left me a tad unhappy and wondering if I could still use poly somehow

Some companies put their frontend code in a base, while others may put frontend code outside the workspace, either in the same monorepo as a subdirectory (the workspace itself can then also live in a subdirectory), or in a separate repo. I have personally only tried the latter.

Thank you for the clarifications. Would you say that poly still (in your split repo case) provided enough benefits for it to be a good fit or are you at that point working so much against the grain that you might be better off sticking to the normal deps and shadow-cljs tooling?

I would say it will depend on how much backend (and shared) code you have -- since that's the only part where you'll have tool support.

Any frontend work I do would be with figwheel-main so I wouldn't want anything shadow-specific in Polylith but I haven't integrated that into a monorepo yet. I may have thoughts on this when I do so -- but my intuition says the build stuff would be integrated in two places: at the workspace level for a single REPL experience with all code available and in the specific project for the SPA, set up for production builds.

@U04V70XH6 hmm...trying to grok what that would actually mean. How would you see the spa code fitting into the poly base, component, project structure?

and thank you both of you for taking the time. I'm feeling somewhat out of my depth here and any help much appreciated.

The "app" part would be a base, yes. Shared code (`.cljc`) might be in components. The build stuff would be in projects (`development` and the named, production projects for the base).

I expect I'll get to try this for real some time "soon" (maybe by year end) and then I'll write some more of my monorepo blog series about it.

ok, will have to meditate on the implications there. We will probably try to structure a fulcro spa like this and see where things land

thanks @U04V70XH6 - that was most useful

This is exactly what I have done, I have code in components and the app in a base, I have tried both shadow and figwheel the part that lets it down / I have not figured out is the hot reloading

it hot reloads when I change the base but components do not trigger the hot reload, this is likely a lack of my own knowledge to make it work though

you can set shadow to use :deps true though so the deps are not in the shadow config

@UU67HFS2X - any chance you have a repo you can share to take a look at the setup? And if not - thanks a ton anyway, this is all very helpful

I don't have a public repo but there is not much to show, dump your app in a base with the figwheel or shadow config split out the code you want to share into components

I can probably copy the shadow / figwheel configs if that's helpful, you kind of needd to build your project from the base rather than the project or have 2 shadow / figwheel files as when you jack in it will look in relation to the file you have loaded, project having to src means jack in will not find the config unless you put it in the base

What if shadow/figwheel goes in root, next to deps.edn, for development repl? This way (with paths properly pointed to the development, base, component and docroot directories) it might work and perhaps you might even get working hot reload?

that may well work I did try this I think but had issues which may have been other things at the time

Then of course a second shadow/figwheel in the actual project, just like with deps.edn...

worth a try for sure

This is interesting stuff 🙂

try a few things I am sure it can work with the right knowledge, if you get a perrfect setup create a demo repo we can point people at 🙂

Yea we should definitely investigate. It's an interesting development case - it would seem like a good idea to put a "system" into one repository, meaning a front-end app together with whatever services it consumes, assuming they together form a cohesive system unit. If polylith can be leveraged for both clj and cljs code bases (part of which would be shared, meaning cljs bricks could depend on / consume clj components) then this would make for a powerful code reuse setup.

yeah especially with things like reitit as you can use the same specs on frontend and backend so you can validate your form data but also use the same validation on the server when data is posted and have it all in one repository

Thanks for the thread. I'm also figuring this stuff out. I have react-native front-end in $ws/projects, which shares a websocket core-async network component with the test code of the lambda back-end. More validation code will no-doubt be component shared in due course, and a planned addition of a desktop client target (if it works out). I'm not using the poly tool yet only the directory structure. I'm delaying moving project code to bases until I have a need. I want a mono-repo and may as well align it with polylinth. Sorry I can't share code publicly.