Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What is the future of back-end development?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 164 posts

Re: Ask HN: What is the future of back-end development?

#91

Post by falcolas »

I picture the easy (CRUD, blogs, etc) backend development somewhat continuing as it has for years, frankly. The easy use cases are going to continue to rely on PAAS offerings; those offerings will simply go from "colocated web hosting" to Heroku, Lambda, and GAE. As easy edge caching from CDNs continues to proliferate, we'll see more and more use of those as well.

Backends which are expected to do more, however, are going to be different. With the loss of growth in computing speed due to faster silicon, I think the growing complexity of our software programs is going to force the pendulum swing back away from "fast enough" and towards "optimize everything". We simply won't be able to rely on faster silicon to handle the greater complexity without further thought on our part.

Pushing the additional complexity to the client will cease to become enough, since the capability to do heavy client side processing is becoming less reliable. The reason is simple: personal computation devices are smaller, lighter, and with more and more unpredictable levels of computation power (as they are throttling to conserve the battery and minimize heat). This leads me to speculate that more and more work is going to be pushed back towards the server, which has fewer restrictions. I do think that communication between the server and client will grow in complexity as well, which will make us look at the days of long-polling HTTP and websockets as "the good old days".

All that to say, the future of backend development is much like the past. Supporting thin clients with unpredictable computing environments by making everything run as quickly as possible in a large, distributed datacenter.

Re: Ask HN: What is the future of back-end development?

#92

Post by tim333 »

sotojuan wrote: post #27
tonyedgecombe wrote: post #13

My hope is it will get a lot simpler, even trivial work seems far more complex that it needs to be. I'm pretty sure I was more productive writing VB apps twenty years ago than I am with current web development.

Yep, I hope for the same but I don't think it'll happen :-(

You'd think there would be a way and there might be some money in it for the work it would save. Perhaps something like a boilerplate app that does the usual stuff you need like https://github.com/sahat/hackathon-starter

But perhaps less hackathon orientated?

Re: Ask HN: What is the future of back-end development?

#93

Post by heartbreak »

caseymarquis wrote: post #73
grosbisou wrote: post #45

Earlier quoted context omitted.

> cause it's just adding a column This kind of mentality is why most applications are shit and broken. And why most hires are worthless. And everyone is not working on a cookie cutter over-bloated rails website. Sorry but this kind of remark simplifying our job always pisses me off.

At my company, we have one software package it costs on average a quarter million USD to install per enterprise customer. It gets about 100,000 records added per day in some deployments. We test our migrations on those systems and have a dedicated data service which is the only thing which can touch any given customer database. We are paranoid about those systems. We also have throwaway apps like an internal time clo…

> which monitors when people show up based on their cell MAC

That sounds miserable.

Re: Ask HN: What is the future of back-end development?

#94

Post by aptwebapps »

collyw wrote: post #71
mabbo wrote: post #61

Earlier quoted context omitted.

Consider the problems that both Lambda and Containers/PaaS solve for you: ignoring infrastructure. It's there, sure, but I don't care much about it. Now take that idea to the absolute extreme. I write code, I push it into the cloudy-cloud machine, and it's serving clients immediately.

As someone that knows how to set up a server, I found Heroku a lot more difficult to get a Django app running than on a "normal" server. And a lot more of a PITA to debug.

What about the second time you ran a Django app on Heroku? But Heroku is not even in `mabbo's first course (maybe the appetizer?) so that's slightly a straw man.

Re: Ask HN: What is the future of back-end development?

#95

Post by vonmoltke »

rimantas wrote: post #34
digitalarborist wrote: post #24

Earlier quoted context omitted.

I don't think custom backends are going away either, I do think it will become way less prevalent then it is today though, similarly how all programs used to do manual memory management, this hasn't gone away but most programmers now rely on garbage collection. So much of backend work is redundant, login, user info management, allowing the creation of groups of users, user following, user data uploading or sharing. N…

With react native and electron web stack is running in circles. How many times should this be repeated: web stack is easier to write only if you don't know shit of the native SDKs. Otherwise it does not even compare.

> How many times should this be repeated: web stack is easier to write only if you don't know shit of the native SDKs. Otherwise it does not even compare.

It's a hell of a lot easier than native SDKs when you need to support multiple different client platforms. This is coming from someone who would rather not have to deal with GUIs at all.

Re: Ask HN: What is the future of back-end development?

#96

Post by LukeB42 »

Hardware: Better "development boards". Fanless, slimmer server hardware. TPUs in the typical datacenter within fifteen years.

Frontend: Webassembly for augemented reality: Hololens or whichever Linux-compatible equivalent comes out on top.

Backend: Evolution as we know it appears to be an optimization function that balances between diversity and fitness, so with that in mind I'll hypothesize a healthy mix of RESTful HTTP/2 with optional streaming. Static resources should live in decentralised overlay networks guarded by frequent trust computation. See https://github.com/Psybernetics/Synchrony and https://github.com/Psybernetics/Trust-Toolkit for PoCs of this last part.

Re: Ask HN: What is the future of back-end development?

#97

Post by GrumpyYoungMan »

paulftw wrote: post #60
caleblloyd wrote: post #49

Earlier quoted context omitted.

"Serverless" such as AWS lambda removes the ability to take advantage of so many Computer Science principles that are integral to writing a fast backend. From one request to the next there is no CPU cache optimization, in-memory caching, and no IPC to other useful programs. Serverless has it's niche for some tasks such as responding to events, but to do any heavy lifting I'd take a handful of beefy VMs over unlimited…

This is based on the assumption that server without those optimizations is not fast enough. That used to be definitely true in the nineties, but hardware is getting faster while human reaction time stays relatively flat. Hardware is also getting cheaper, so throwing a beefier server is a much easier and better solution than investing months of error prone and non-scalable human labor. Everyone is ditching those beaut…

>hardware is getting faster

Considering that the end of Moore's Law is more or less here already, as pointed out in many HN articles, that's really no longer something we can take for granted.

Re: Ask HN: What is the future of back-end development?

#98

Post by sontek »

caseymarquis wrote: post #87
sontek wrote: post #64

Earlier quoted context omitted.

This is definitely a common use case and very valid for smaller applications. If I were you though I would avoid applying your experience on smaller scale applications as a way to say that everyone who can't do that are using bad frameworks. Once your application reaches a certain scale there is a huge chance that generated migration could lock a table for minutes to hours which isn't acceptable. We allow developers…

I think you're correct. I was out of line by being too general. For our large scale applications we back up the database and have required down time from our customers while doing a major migration. Everything isn't always simple. But adding a check box in 90% of cases usually is.

Adding a check box in a relational database most likely involves running ALTER TABLE to introduce a new column which in most relational databases locks the table.

Now lets say you are doing 15,000 requests per second on that table.... is preventing those from executing acceptable in your system? Its not in mine which is why we don't run ORM generated migrations.

Re: Ask HN: What is the future of back-end development?

#100

Post by mattm »

douche wrote: post #19
british_india wrote: post #6

Given the complex services we already have, services that access complex, multi-source databases of the relational and NoSQL kind, I find it amusing that UI developers are so unaware of the complexities of the back end--complexities that are normally hidden from them--that they think they can be reduced to so many calls. WebSockets don't magically assemble complex back-end data. Amusing in the extreme.

It's the classic "Can't you just add another checkbox here?" situation. Yes, I can add a checkbox there. But I have to add the code to include that setting in the API that the front-end calls, to give you a way to retrieve it and change it. Then I have to add code to the data access layer for this new setting. Then I have to write the SQL scripts to add columns/tables for this new setting, as well as change scripts t…

This reminds of I conversation I had with a mobile developer. He came up with a prototype to show to a client. The prototype was just interactive screenshots with nothing going on in the backend. After showing it to the client, the client was excited that the app was pretty much done. The developer explained that this was just a prototype and all the coding still needed to be done. The client couldn't understand and kept saying that it was basically done.
Post reply on HN