Aye, this is some ways down the road now - quite a few projects on this base template. Only real complaint is:
- Submodules get out of date where data is concerned - Some submodules contain a lot of data and so bloat deployment (e.g. maxmind) - cgo dependency leading to: can't use a blank docker container, slower to compile and local installation dependencies - something like site indexing for search does not share data so every concurrent instance builds at runtime after a deploy - upgraded submodules may take a while to get to all the projects, leaving project feature inconsistent I'm inclined to move out anything which has changing/largish data sets and centralize search (though during a rolling deploy this could be an interesting disaster). On Saturday, March 11, 2017 at 10:05:49 PM UTC-8, Matt Ho wrote: > > If you're just starting out the project, by all means start with the > monolith where everything is together. If you decide it's necessary, over > time you can split out the project into what you've discovered you need. > > Trying to abstract the components you think you'll need too early is a > good recipe for heartache. > > M > > > On Saturday, March 11, 2017 at 9:00:43 PM UTC-8, James Pettyjohn wrote: >> >> I'm looking at the pros and cons of how to architect a web project. >> >> 1) One is a single go project for a site. No service dependencies for the >> backend at all. Certain aspects of this means a cgo dependency which is not >> ideal as it complicates containerization and slows build time. One plus to >> this is the simplicity in development - the entire project is self >> sufficient and tests are easily checking everything - thought compilation >> and startup suffer. >> >> 2) Another means would be to split out portions of the project. This adds >> dev complexity as it requires more services to enable parts of the server, >> or run at all. Coordination of service versions becomes an issue. But the >> services, now being centrally located, can be deployed and result in >> updates to all services using it. I think from the ops perspective this >> could be more efficient as you don't inherit the overhead in all projects. >> >> >> Opinions on the above? Another approach entirely? >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
