alexandrialibrary / Alexandria

Alexandria is a simple little card catalogue webapp with a terribly pretentious name.
MIT License
2 stars 1 forks source link

Consider decoupling front-end and back-end #77

Open hawkw opened 9 years ago

hawkw commented 9 years ago

Since our architecture basically has the Alexandria API as the only point of contact between the front-end and the back-end, we might want to consider further decoupling them. For example, the front-end could be developed on an entirely different repo, and included in the backend as a submodule or as some kind of dependency (a WebJar? see #65).

This has a few advantages:

What does @redbassett think about this idea?

redbassett commented 9 years ago

This is now being tested with the experimental alexandrialibrary/alexandria-frontend.

hawkw commented 9 years ago

Fantastic, that looks great. How do you want to include the front-ends from your repo in the main repo? git subtree?

hawkw commented 9 years ago

(We may also want to look at moving the back-end stuff to its own repo as well and subtreeing them both into this repo so that all the development docs and stuff can live somewhere independently of the separate front-end and back-end code)

redbassett commented 9 years ago

We need to discuss the commit -> build -> include process for getting the code from the frontend repo to the template/public directories of the backend. Also how to share common files such as dotfiles and Swagger docs. If we want to share them between repos.

hawkw commented 9 years ago

We need to discuss the commit -> build -> include process for getting the code from the frontend repo to the template/public directories of the backend.

Yeah, I'm not sure how we're going to do this exactly, yet.

Also how to share common files such as dotfiles and Swagger docs. If we want to share them between repos.

I think we do. Should they go in a common repo and be subtree'd in to both backend and frontend, or something?