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.
