3 ms·

For backend I'd say -> Golang, PostgreSQL, Redis. I've just worked with Vue.js but I've seen some of the React codebases and don't really appreciate that comple

For backend I'd say -> Golang, PostgreSQL, Redis. I've just worked with Vue.js but I've seen some of the React codebases and don't really appreciate that complexity. Vue does a far better job and simplifying things. With Golang, you actually don't need a mega framework to get started, you can use small libraries that will do the job for you without doing any magic behind the scenes. (Like, for sure you can use echo[0] but you would probably be happy with mux[1] and it's middlewares itself). And it's not uncommon in Go codebases to repeat yourself. I'd argue that's a much better paradigm than polluting your codebase with 10k indirect dependencies, the garbage that is the Node.js ecosystem. [0]: https://echo.labstack.com/ https://echo.labstack.com/ [1]: https://github.com/gorilla/mux https://github.com/gorilla/mux

silisili 5y ago
After many years of trying all kinds of things, this is exactly where I landed. Go, Psql, Redis. Unless your data or workload is highly specific and abnormal, it really covers about anything you'd want to accomplish.
- nprateem 5y ago
  Same. Vue/capacitor in the front, go on the back with postgres and sqlite for tests. Also using laravel for the web site. I looked at fastapi but when I saw the benchmarks I thought I might as well just use go for the type safety, speed and ease of deployment. Currently running on Google cloud run. I'll probably switch to AWS though because Google dns doesn't do naked domain redirection, but AWS app run seems half baked...
midrus 5y ago
> With Golang, you actually don't need a mega framework to get started You just need to build it from scratch, document it and ensure it is well tried and tested. "mega frameworks" are there for a reason. Rails, Django, Laravel, etc have everything they have because almost any web application you build (except if it is just a minimalist micro-service) will need routing, authentication, i18n, ORM or similar, migrations, caching, e2e testing, validation, background job processing (the one that works after a deploy or restart), and a thousand more other things. Of course you don't need it to "get started", but 1 week after getting started you'll find yourself rebuilding the wheel yourself or tying together 10k dependencies (something doable if you have enough experience and know what to pick and what to not pick, but risky). > And it's not uncommon in Go codebases to repeat yourself. The fact that it is not uncommon doesn't make it any better. Rewriting the universe from scratch in every single project is the worst idea ever. I don't think that because we like a programming language which happens to have no popular web framework we need to negate all the problems of not having one, or say it is in benefit of simplicity. It is not. I'm very sorry for my rant, but I've already faced too many disasters in work environment were people thought that "just flask" would be enough, and years later we're still fighting the fire and trying to understand why this custom ORM validation integration doesn't work.

silisili 5y ago

After many years of trying all kinds of things, this is exactly where I landed. Go, Psql, Redis. Unless your data or workload is highly specific and abnormal, it really covers about anything you'd want to accomplish.

nprateem 5y ago
Same. Vue/capacitor in the front, go on the back with postgres and sqlite for tests. Also using laravel for the web site. I looked at fastapi but when I saw the benchmarks I thought I might as well just use go for the type safety, speed and ease of deployment. Currently running on Google cloud run. I'll probably switch to AWS though because Google dns doesn't do naked domain redirection, but AWS app run seems half baked...

midrus 5y ago

> With Golang, you actually don't need a mega framework to get started You just need to build it from scratch, document it and ensure it is well tried and tested. "mega frameworks" are there for a reason. Rails, Django, Laravel, etc have everything they have because almost any web application you build (except if it is just a minimalist micro-service) will need routing, authentication, i18n, ORM or similar, migrations, caching, e2e testing, validation, background job processing (the one that works after a deploy or restart), and a thousand more other things. Of course you don't need it to "get started", but 1 week after getting started you'll find yourself rebuilding the wheel yourself or tying together 10k dependencies (something doable if you have enough experience and know what to pick and what to not pick, but risky). > And it's not uncommon in Go codebases to repeat yourself. The fact that it is not uncommon doesn't make it any better. Rewriting the universe from scratch in every single project is the worst idea ever. I don't think that because we like a programming language which happens to have no popular web framework we need to negate all the problems of not having one, or say it is in benefit of simplicity. It is not. I'm very sorry for my rant, but I've already faced too many disasters in work environment were people thought that "just flask" would be enough, and years later we're still fighting the fire and trying to understand why this custom ORM validation integration doesn't work.