Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sure, I'd say this applies to the vast majority of websites, and technologies like docker, kubernetes or multi-region deploys simply are not required for most projects. There is no need for massive scale and multiple nodes for most services/websites and if you find there is, well you'll be rewriting a bunch of things anyway unless you've done a lot of work on very large websites before.

I do think there's something to be said for habitually separating the database though - if you store data elsewhere, you can have 1 instance or 2 or 3 pretty easily, and sometimes having more than one is nice for redundancy, handling big spikes or seasonal traffic etc. It is pretty easy to scale horizontally nowadays on cloud services where they take care of load balancing and sometimes the data store too. You also don't have to worry about wiping a server and starting again, as your data is elsewhere.

Embedding a db like sqlite introduces other problems (cgo requirement for one). It is really handy for things like mobile development though as then you don't depend on a separate api or db for data. It's also handy if you don't want potential users to have to worry about setting up a db when trying out your project, so an embedded db is really nice for that - I wish golang had a clone of sqlite that was pure go code as it would make this even more attractive for a broader range of options.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: