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.
