Hacker News new | ask | show | jobs
by hans0l074 2051 days ago
When I read about such abstractions and "simplifications" (which usually end up with a 10 box diagram simplified to a 2-3 box diagram), I often hesitate to start building something new, always wondering "Am I doing this in the most "<tech_forum> upvoted" way of implementing such a thing? Some of this tech feels like if you switch on, and stare at your monitor long enough, a "Hello World" API will be deployed on the cloud for you, voilĂ !
3 comments

I think it's a good point and something I find myself worrying about as well. The hype around GraphQL and Apollo, for example, made me feel that I was losing serious time developing a REST APIs until I finally committed and decided to use it on a project. Obviously there ended up being a lot of trade-offs but in the end it was hard to tell if I saved any time at all. More generally, after falling for this a couple times of I realized that often you're just pushing problems around to different parts of the stack, or hiding complexity in places you'll eventually need to uncover. My experience says that the time consuming parts of building a product are rarely solved by adding flashy new services and libraries, and so I try to worry about these things less. On the other hand, trying out new stuff even just for an hour or two can give you a lot of insight into how much time it's actually going to save you - so worse case you just take it for a test run and see what it's actually all about.
I like to call this the: Law of Conservation of Complexity.

It does not matter how slice and dice things, the real world is a complex environment and as a result your application will be complex in some way too. You just can't sweep complexity under the carpet and pretend it's not there. It will always come back and bite you, in some way or the other.

That law is very obviously broken.

It is evident that complexity can be increased at will. So any such law statement just assumes that any software you have didn't needlessly add some of it.

A very real problem of framing complexity this way is that the article is very likely adding a lot of complexity to the software. That's what most "let me simplify it for you" solutions do. And if you just state that complexity is constant, you won't even think about checking this.

ok but taming complexity is what we do for a living. The Q is where to put the dirt. And under the carpet is better than on my bed.

I don't know this tool but for example if I switch my "webapp" to use redis, I push some complexity to "antirez". It does not disappear, but it's now being fed by developers better than I, and tested by x1000 users.

Exactly the same experience with GraphQL - indeed I think in the end it cost more time than REST. The thing is, GraphQL is a tool that really shines when you have... graph data (like Facebook). The problem is every company under the sun is now rushing to use it as if it's some kind of silver bullet because of all the hype.
Maybe microservices might seem buzzwordy on the surface, and this might be an anecdote, but I have seen it working first hand at Hailo (Uber competitor back in 2013). Relatively inexperienced people not knowing anything about Go or deeper architectural issues deploying Go services in no time, without even asking for permission.

I don't think that would have been doable with a monolith. It enabled innovation I have never seen before. My 2c

Absolutely. I wasn't criticizing the architecture at all, just musing out loud. I had meetings this week at Big Co (read: cash cow) where external vendors were pushing microservices as manna from heaven for problems that are yet to be discovered. I am sure the technology described in the article is very clever and has strong merits.
Netifly at least was as painless as a deploy process as I've ever had; I had a local jekyll instance i was using to build my blog, and all i had to do was setup Netifly so it was pointing at the remote Github repo for that instance, then simply push to master and everything deployed instantly. There certainly are some tools in the area that feel very over-engineered but so far this one has been quite the opposite (other than weird SSL woes, but that was still more or less painless) Can't speak to the backend product being sold here, but the frontend really was painless and performant.