search

x-team / x-map

MIT License
8 stars 3 forks source link

Repository separation between front-end and back-end #177

Closed diegodurli closed 8 years ago

diegodurli commented 8 years ago

Guys,

I would like to discuss with you the possibility to have a clear separation between front-end and back-end code.

In my opinion, it would allow us to move faster, both coding, setting up environments and also running our builds. It would be great to have the front-end only relying on a few steps to run, like:

  1. Git clone the front-end repo
  2. npm install
  3. npm start
  4. You should be ready to start contributing

Almost every separation of concerns is a good deal, but I really would like to have your view on this subject. It may not be even a possibility (perhaps there's a limitation I'm not aware of).

What do you think about it?

Please, do include here any other person that may be involved with this @bernardodiasc, @jkbdbrnwsk, @jedrzej, @peterKaleta

jedrzej commented 8 years ago

@diegodurli isn't what you described already possible? If you use remote API (e.g. staging) then getting frontend to work should be possible the way you described. To be honest I also don't see how having the API code in the same repository cold slow down developing frontend features - just don't look in there :)

I can't say I'm against splitting those 2 codebases, but there are some benefits of how code is organized right now.

One is quite similar to what you mentioned already - the ease of setting up development env. I understand that your focus is mostly in the frontend layer, but there will backend development done as well. Having both frontend and backend in the same repository makes it simpler to setup a full development env locally - clone the repo, run a few commands, done, at least in theory as we had some issues trying to set it up for you. So in my opinion current setup allows for quick setup of both backend+frontend env as well as frontend only, while splitting the code would make setting backend+frontend env more complicated.

Another thing is that current setup makes it easy to build a docker image that is later deployed to stge/prod. This image needs to contain both frontend and backend code - of course it's possible to get that to work with separate repositories, it would require us to re-implement how we build the application.

So, long story short, we could split it, but it would require some additional work and I'm not sure the benefits outweight the cost.

jedrzej commented 8 years ago

One more thing :) It's likely that we'll turn the existing API into a set of separate microservices at some point, probably one service at a time. So I imagine that in a few months there might not be any backend code in x-map anyway.

diegodurli commented 8 years ago

Sure @jedrzej, got it! Make sense assuming that we need to deploy this unique docker image to have the application up and running.

Still think that our current setup is a bit "complicated" and create a dependency between front-end and back-end that is not extremely necessary (I could develop front-end tasks without concerning about back-end code, as it could point to a staging back-end service).

As you said, in a few months we may need to naturally change how we organize this codebase to accomodate these microservices.