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.
