Ask HN: What is a “boring” web stack?
There have been threads recently lamenting how many in the web community often chase new and shiny. Many advocate choosing "boring," tried-and-true technologies for the web. What are the "boring" stacks that you see successfully used for the web? If you were starting a new web project today, what would your "boring" stack look like?
49 comments
[ 3.0 ms ] story [ 91.7 ms ] threadPostgres has lots of shiny features on the SQL side, but MySQL's storage and especially replication has always been more reliable for me. I've seen a couple failed MySQL -> Postgres migrations because it's the shiny thing people chase, but the operational reality is that MySQL is still better.
That's why I listed both. I'd use and recommend Postgres as a default in a heartbeat based off personal experience, but I wouldn't have personal experience with MySQL's strengths and people use and recommend it as well.
Postgres certainly wins in terms of features, though most of those features aren't required by the vast majority of web apps, so "more features" isn't necessarily a reason for most people to favor Postgres by default. Which features of postgres which aren't present in MySQL would you not want to live without?
You also called MySQL a toy in terms of stability compared to Postgres. What experiences shaped this opinion?
For an anecdote, I work at a relatively large SaaS company which runs over 300 MySQL servers in production, over 600 if you include QA. We specifically run percona-server because it's basically the enterprise version of MySQL, and percona makes some great tools. (We use the free version of percona and do not pay for percona support). We have a single DBA who manages all of those servers full time. I work in ops/SRE and touch MySQL here occasionally, but mostly just to touch the OS, monitoring systems, automation systems, etc on those machines. So overall, our ratio of admins to MySQL servers is basically 2:600, which makes me consider it not a toy (especially in comparison to the number of people it take to manage the other data services we run). As far as stability goes, we were rock solid on MySQL 5.6, but hit a few serious bugs on MySQL 5.7 (two memory leak bugs in plugins, and one in the core that caused a crash), all of which have been resolved as of 5.7.12. 5.7 is an extremely major release in terms of features and performance, so I'm willing to let a few bugs slide here.
We run many different types of data services, mysql/hadoop/hbase/kafka/redis/zookeeper/elasticsearch/etc, adding postgres to the mix has always been of interest to some devs who want a postgres feature here and there. I personally like both MySQL and postgres, but it seems that MySQL may be more mature in terms of operations (tooling and replication/HA) and performance. I love ops work, so to me, more services means more fun and I've advocated to add postgres in the past, but it's tough to find reasons to push for it.
Unfortunately, now I've gotten away from the topic of "boring" stack to use, but in general, I think the choice for a "boring" database would be MySQL, while postgres is shinier and more advanced. There are a lot more people using MySQL in the wild and virtually every language and framework supports it. I typically view postgres as a more hip open source database, due to its interesting features and niche of developers who really really love it, whereas MySQL is the popular option, that gets the job done, and mostly lacks enthusiastic supporters. People just use it because it's easy and works. That said, it's easy to see how people could have different opinions on which of these is the "boring" choice because both are perfectly reasonable choices. When not operating at a big scale, mostly default installations of both MySQL and postgres will get you quite far and are pretty comparable to manage.
Here's a few:
1. Check constraints.
2. INTERSECT and EXCEPT operators.
3. Common table expressions.
4. Sort-merge join.
5. Serializable snapshot isolation.
Postgres has gotten better and friendlier over time, but its still much easier to ramp up with MySQL.
I recently did a project where I wrote the same API in Ruby/Sinatra, Node/Express and PHP/Slim; Connected it to S3, GCloud and Azure for assets and MongoDb for data; and then deployed each permutation to Heroku, Azure, App Engine and EB.
For "under the api barrier", Heroku was the only one that ran everything smoothly; S3 is the easiest to interact with, and as I worked through the project, I switched from Ruby to Node as the prefered platform.
For "over the api barrier", where users actually use the project, it depends on the project requirements. In this case no dependancies was a hard requirement, hence Vanilla JS. But if you have a lot of UI, you'd need a lib for both JS and CSS and it depends on teammates pref, organization pref and legacy.
My 2 cents.
[0] - https://github.com/feulf/raintpl
Nobody's idea of excitement.
I miss well tested and 'best practice' pattern derived systems...
Actually language doesn't matter so much as choice of frameworks. Basically choose what you know works and avoid hype.
Also minimalism is a better indicator than age. A brand new simple framework is better than something old but over engineered.
For PHP it depends on what you want to do, but Laravel (or Lumen) may help you A LOT!
It is super boring by these standard:
- You can find setup tutorials everywhere
- Almost every question you might think of has been already answered
- It will do what it says it will do
(Also don't forget to install phpMyAdmin, because who wants to write SQL in a terminal)
None of these are really great technologies, but they work, have infinite documentation, and it's easy to find people who know them.
For a small REST api, I really like Dropwizard on top of something with a solid raw driver, like Redis or Cassandra. If you want to go relational, I like the MyBatis model of persistence over the Hibernate style ORM, it gives you so much more flexibility and power over modeling, while still giving you an easy out for swapping out datasources.
I don't really know of a good drop-in replacement for what Spring does, unfortunately, because Spring is really a conglomeration of so much different stuff. My big issue with it isn't so much what it does, as the fact that it encourages really bad mindsets in developers who start their career with it. I can't count the number of times I've asked someone to describe what annotations are, and the only answer they can give is about Spring (the worst part is when they attribute things from Jersey or JPA to Spring), or how they reduce the need for XML configuration (in Spring, yeah, that is true).
Testing + deploying to either Azure/IIS is also one-click simple and very easy to teach Jr. Devs to step into a solution and become productive with very little guidance.
Javascript - either no Javascript, or very simple vanilla Javascript. No transpiling, no Typescript, no JSX, no ES2015.
CSS - Regular ol' CSS. Set a limit on number of lines of CSS you're willing to introduce per controller action and try and keep your project honest to that number. Avoid frameworks if possible, pick a simple framework for grid layout if you really need it.
You can do a lot with just that. Here's an example of what I've done with just that:
http://www.planimeter.org/grid-sdk/
http://www.andrewmcwatters.com
http://motherfuckingwebsite.com/
Using absolutely no CSS at all probably isn't what you want, unless you have a fetish for serif fonts. But a little can go a long way.
Django templating and bootstrap to make things look OK.
The only caveat to this is on the front-end JS side of things. jQuery is still solid, but the language and ecosystem has been so not great over the last decade that something a bit newer might be worth looking at (maybe look at 3-5 year old libs/frameworks instead).
I recommend just using SQLite for the MVP. Launch then iterate.