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.
