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

[johnnydoebk]

Apparently, WebAssembly will revolutionize the client-side development. The web apps will be very much like desktop ones: high performing, can be written in any language. At the same time they are cross platform, can be easily distributed, and do not require installation.

Meanwhile, every "builder of web3.0" who's trying to "fix the Internet", or "make the web faster, safer, and more open" is doing it in such a way that back-end development is not required. I.e. they are working on decentralized (either p2p or federated) universal back-ends that they assume should be used by everyone.

Do you believe that in future the back-end development as we know it today will be obsolete as everybody will use some p2p BaaS platform and the web-development will be all about implementing client-side apps?

[mabbo]

Some people don't like the word much, but "serverless" is going to become a bigger deal.

You'll write your code, complex or simple; you'll hand it off to some cloud system; you'll write a bit of configuration; you're done. Likely the configuration part will become less and less required.

You won't think about hardware, scaling, load balancing, etc, it will just happen for you. The data store being used will be abstracted away so that you don't know/care much about who provides it. Configuration problem.

Containers, AWS Lambda, these are just the first course of this meal.

Why? Because developers are expensive. Time spent doing anything other than the critical piece of writing business logic code is time wasted, and longer time to market.

That's how I see the future of the server side.

[scrollaway]

This model isn't "serverless", it's PAAS. It's not much of a future. Heroku is useful for prototyping, not scale. (Edit: Doesn't mean it can't be more popular though - the web is full of prototypes)

"Serverless" as in AWS Lambda has very specific use cases. The people who are serving websites on Lambda or something are not only doing it wrong, they are wasting money while locking themselves in to an architecture that doesn't fit their app.

I say this as a heavy Lambda user (https://hearthsim.info/blog/how-we-process-replays/). Lambda is super useful if you have to scale CPU-heavy tasks. I do think that model will play a big role in the future, but I definitely do not think it'll be the go-to model for backend. It's a complete paradigm change.

[tachion]

What does the fact that developers are expensive has in common with infrastructure/ops? You mean that developers shouldn't be working on it? I couldn't agree more, just like I wouldn't like my dentist being my heart surgeon! Developers should write the code, but they should not be doing infrastructure nor operations, and they should not enforce some 'serverless' utopia on projects/situations where pure infrastructure competence would do its job.

[blowski]

I agree in part. However, it reminds me of the prediction that front end development would be replaced by point and click build environments. While that suffices for a section of the market, it has very far from killed it off.

[caleblloyd]

"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 lamda functions any day.

[obihill]

I agree in principle with most of what you've said here. The server-side is going to be a lot more intelligent in the near future though. My prediction is that every cloud provider is going to have some sort of AWS Lambda service that will eventually become like a server-less toolkit in the cloud. And these platforms could eventually have some augmented intelligence built-in.

Essentially, we can't keep teaching each and every developer database connections, SQL, et al. The cognitive load associated with these sort of programs actually slows down advancement, and the quicker you can setup cloud-powered services that get the job done, the better it will be. Although, I can't say what that will do the livelihood of developers. We'll have to wait and see.

[mrweasel]

Aren't you mixing infrastructure and backend-development?

Hardware scaling and load balancing is infrastructure. Abstracting the data for the client, that's backend development, that's where your business logic lives.

[_RPM]

Yes. You won't even have to know to code. You'll just press a button that generates the code for you. In the future, all programming jobs will turn into data entry jobs where the programmer will be entering commands into a GUI to generate a button here and there.

[british_india]

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.

[douche]

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 to change the schema. Then I have to test all the pieces involved, test that upgrading the database from N-3 recent releases to the new schema works correctly.

And this is for a dead simple little setting.

[leecarraher]

i often get the, can we make this a websocket instead of an api call. that way it can just get updated instead of you having to run a query... 1. not neccessarily faster (push vs pull depends entirely on the data creation consumption model) 2. the push scenario is not how most database access patterns work. Instead it's likely just polling the db on the backend instead of the front end. So same db load. and now lots of open connections to simultaneously maintain and garbage collect.

[mrweasel]

The ability to build a solid backend platform and infrastructure is going to be increasingly important in the future. The "backend" is becoming increasingly anonymous (as in not seen, not as in privacy), but it has never been more important.

If nothing else the increasing focus on data collection and processing will push the need for custom backend forward for many years. Any every application that needs to store or share data via an API, needs an backend that understand the data it receives so that it can validate, process and distribute that data correctly.

Backends (custom backends) aren't going away any time soon.

Your question reads as if you believe that "backends" equals desktop applications. Even in that case it's still hard for web application to compete with desktop applications. It's a matter of personal preference of cause, but something like Google Docs feels weirdly restricted, confined and cramped somehow, simply because it lives in the browser.

[digitalarborist]

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. Not to mention all the DevOps, managing CloudFormation scripts, VPCs, proxies, load balancing, dns, ssl, cdn, database schema, the list goes on, and that's before there has been any original development at all.

With react native and electron (I haven't found the atom browser or vs code weirdly restricted) the web stack is moving into desktop territory and with serverless frameworks becoming more prevelent hopefully this will make writing original software easier with less redundant work.

As to your point about data processing needing a custom backend, I see the exact opposite. Generally all this data is just funneled into a generic hadoop cluster and can be manipulated any which way from there using spark or any number of data analysis tools.

[jalfresi]

Personally I don't see any of that happening - client-side app development on the web is a chaotic mess with no "official" (whatever that means) way of doing things. Throw into that mix the constant reinvention thats going on (yeah can't wait to see everything get re-invented AGAIN when web-assembly comes along), for what constitute incredibly marginal gains in the UI space (the web UI was already way fast enough 5 years ago without introducing mind-bending paradigms like react).

On top of all that, the very concept of web apps (in my opinion) is fundamentally flawed in that they break the web (fundamentally flawed in a similar way that Flash as a interactive platform was flawed e.g user interaction along a timeline is an inherent conflict).

So personally I expect all the client-side web app stuff to collapse under its own weight at some point. As a example, I've been a web developer for 20 years, and for my own projects at home I don't even bother with web front ends; I use QML and QT and bang out a great UI in a fraction of the time it takes to produce a web UI. It's not worth the hassle anymore, but then I have the luxury of my own projects not having many (any?) users beside myself.

As for back-end, I've actually seen a shift more towards "systems" e.g a set of isolated sub-systems interacting via event busses or queues over HTTP/JSON either as micro-services or something close to that. Then a separate "web front-end" app pull data for output/display, almost as a client to that system. So a cleaner separation of The Real System from Web Application Back-end. And in this space, things seem to becoming much more standardised means of communication between parts, whilst at the same time there is a Cambrian explosion of new tools, languages etc which can be exploited. There is very much an idea that separate sub-systems can be written in languages which can best take advantage of for the problem space.

It's very interesting to see the differences in the way the front-end and back-end communities are approaching progress/innovation.

Anyway, thats my opinion/view of it all. Sorry for the wall of text

[rimantas]

Agreed. As I once put it web stack for the apps is like trying to invent, version after version, a kind of fork which is most suitable to eat soup. Folks, the spoon exists for the reason.

[lj3]

What do you think about a browser plugin that runs arbitrary .exe code via a plugin? It would have to be sandboxed, of course, but it would give you all of the benefits of a browser distribution model without having to deal with the DOM.

[sktrdie]

I think backend will move more towards streaming endpoints (WebSockets). Already with concepts such as Observables we're building apps entirely around streams of events. So to me the connection between frontend and backend will just be what you already use to communicate between your app components (streams). With regards to "where the backend is", it doesn't really matter. It can be on N different servers. What's important is that we'll be able to generalize lots of logic and automate most of the things (things like auth, database writes/reads, etc). Other more specific things we'll always have to write ourselves, but the management of an "actual server" will be more and more abstracted, and we'll eventually deal with it entirely on the app-code side of things.

[DoubleGlazing]

The more people try to build simple and "elegant" front ends, the more us backend developers have to do to support them.

I seem to be doing a lot more "mashup" work than ever before, joining up disparate back end systems in order to hide it all behind a simple modern front end. In the past if I was developing an order processing system I would work on the view/UI side of things as well, now I expose the functionality via an API and let the front end guys develop a nice interface for it all.

Also lets not forget you don't actually want any mission critical, confidential or security stuff happening on the front end no matter how WebAssembly gets.

There will always be a backend.

[jbb555]

WebAssembly will not revolutionize anything. It's like java where people claim it's as fast as native code, and yet every single program runs like a dog and takes 100 times the resources. Only worse because it runs in a browser.

[sontek]

I'm not a java developer but I find this generalization pretty ignorant (sorry... I don't mean this in an insulting way... maybe misinformed is a better word?).

The JVM is an extremely fast system and if you run java on top of it that is fine. There is a reason so many of the world changing distributed systems (Cassandra, Kafka, ZooKeeper, etc) are built on top of it.

I believe what you are thinking of our java business systems which are usually bloated/slow and developed by similar developers who think backends can be automated.

There is trade-offs on both cases, if you can optimize for developer speed and sacrifice app performance that might be fine for your use-case. Software applies to pretty much every industry and not everyone needs scale but not everyone can live with poor performance either.

[brianwawok]

The financial exchanges running in Java would like to disagree with your gross generalization.

[Zekio]

Well hopefully WebAssembly will fix the 20% CPU util to scroll on some websites because of the insane amount of JS

[shadowmint]

:)

You're wrong.

(See, I can just drop off one line unjustified comments too, but I wont~)

WPF native applications are failing against electron applications; slack, atom, vscode. If you think that because it runs in a browser it'll be slow, try writing a native windows 10 application sometime. You'll be both astonished and disappointed by how terribly slow the 'GPU accelerated' application is.

All web assembly does is cement this desktop dominance from 'native' applications and allow people to start pushing realistically into the mobile space with react native, etc.

You don't think it'll revolutionize anything? Haaaa~

[John23832]

That Java comment is horribly misinformed. Sure, the JVM requires more resources at a minimum that implementations in other languages, but a competent programer using the JVM will run circles around your favorite Python/JS/(insert language here) implementation.

[lucian1900]

That has more to do with the libraries than the runtime. The JVM is very fast, but the classlib is very big and inefficient to load.

Dalvik's major advancement was faster class loading.

[mrits]

The JVM is very fast.

[emilsedgh]

I don't think WebAssembly is going to revolutionize front end development.

What you can do with WebAssembly regarding front-end development is running your Qt/GTK+ type of programs on web.

But noone is interested in that. As a matter of fact, current trend seems to be ditching that sort of program on desktops and using HTML/JS/CSS stack for desktops as well (atom, slack, etc) because its much easier to create a top-notch UX using HTML stack.

HTML stack is very resilient. It evolves at a fast pace. Don't underestimate it.

WebAssembly will definitely have its own use case in the future (games, apps with specific performance requirements) but its not replacing frontend development.

Regarding backend, its not going away. Serverless doesn't mean backend-less. It means backend deployed in a very distributed fashion.

I personally think backends will be thinner and thinner as databases gain more responsibility an functionality.

[otobrglez]

- More "reactive" frameworks / languages / tools.

- More functional principles and more resilient implementations.

- Complete decoupling from lower levels. Meaning that you don't care about servers anymore. Apps are Dockerized and resources are dedicated automatically.

- No more human designed APIs. Why write APIs if modern machine learning principles can replace the whole concept?

- More lambda / serverless concepts.

- APIs and integrations will be automated and auto discovered.

- More (micro)services, mixing of different languages and stacks.

- More streams, more events,...

[rimantas]

It's funny how future is described by many with what's hot that day. If you were to ask similar question ten years ago, the future would looks so wildly different (iPhone was announced in 2007).

[pauljaworski]

When I started building out the back-end of my latest project, I realized its only purpose was to persist data to a NoSQL database. I had a small epiphany and decided I didn't need to build a server at all - I could just use something like Firebase to accomplish that task.

Now that I'm getting deeper into the project, I need to add in features like PDF generation. No problem! I'll use microservices for that. Well, that means I need to build a Docker container, deploy it to AWS ECS, and configure AWS API Gateway to talk to it. None of these things are what I would consider "front-end" dev work.

Back-end is surely changing, and many of the needs can be shifted to the front-end/BaaS platforms, but there's still plenty of work left! I think we'll see the back-end role transition more toward building and maintaining these microservices and possibly the business logic portions of the front-end.

[fermuch]

An easier approach IMO would be to create an amazon lambda script to process the pdf and make it run when you upload a file to a bucket in amazon s3.

It's easy to do and you don't need to mess with anything more than two simple API.

[nol13]

That's what jsPDF is for.

[donatj]

Simple Client/server isn't going anywhere anytime soon. It's too simple to implement and understand and use to die. Good enough almost always wins.

[tinganho]

I think the future of back-end development is heavily decided by the future programming language. I think we are still missing a programming language that is safe, fast and productive. Safe meaning type safe and memory safe(Also memory leak safe), Fast meaning near zero abstraction costs, and productive meaning productive syntax and good tooling support. And it has to be built on modern compiler architecture, which means a compiler exposes an API for tooling(symbol lookup, refactoring, etc.), so people around the world don't need to reinvent the wheel.

I personally don't think any programming language fits the above description. And we have yet to invent it.

[tonyedgecombe]

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.

[sotojuan]

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

[mempko]

I would love the future to be P2P. However, I don't see it happening unless we have an economic revolution. There is just too much money to be made from collecting data. Data is king.

My guess is that future of back-end is using tighter languages like C++ and rust. Why? Because energy will become more expensive and we will require fewer machines to operate the application. These apps will run on single purpose kernels like exokernels and unikernels where the OS and app are married like in the "good old days"

[samblr]

I tend to agree with development as we largely see will become obsolete or in other words development will/should become really easy. It is primarily because designing backend is very similar to designing a deterministic state machine albeit a large one. And strangely enough, there is much re-invention of that state machine that happens in different projects by different set of people using different frameworks.

And going a step futher - relationship between tables in database should reflect on how an operational/working UI will look like. eg: say blog and comments are two tables and related by foreign key. So in operational front end - it makes sense to see them linked together in say blog page.

Now sprinkle machine learning concepts to it - a relationship between two interlinked tables where 'p' columns are in blog table and 'q' columns in comment table can be represented in 'n' different ways in say 'm' different type of clients(like web mobile etc).

Now is it not possible to link design of whole web app to our voice commands and let some deep learning algorithm figure best schemas, front end, frameworks and even show a demo MVP.

[weddpros]

Many/most backends are stateless... In a way, they push the complexity of distributed systems to the db. They don't deal with sharding, load balancing, request routing... so they leave some performance on the table.

They are still built as if it's normal to split the backend in two: app server + db.

Maybe backends will learn from databases, and become sharded, redondant, and stateful. The border between app server and db could become fuzzy...

[SFJulie]

It depends of the QE and next central banks announcement.

If liquidity is cheap on the market, innovations will tends towards KPEX=0 thus more SaaS and stuff will be produced backed with heavy marketing disguised as technical conf/blogs, and corps will have the money to kill competition by buying it. Hence it will not be a truly competitive market.

If there is a contraction of liquidity however only the fittest will survive (low OPEX) and then SaaS, p2p, BaaS will die for more «old school» kind of development based on costing/pricing. Clearly this would mean the return of GUI and all kind of transactional databases and small meaningful data.

The problem with financial markets is they are like weather : hard to forecast.

And for the same reason we know there is a global warming, there is clearly a tech bubble. The more we wait for solving the problem, the more it will hurt.

An industry future is always related to the confidence and money investors have in investing into it to expect ROI.

With the paranoia going on all around the world, expect security to be the next money maker.

[p4wnc6]

There are many software jobs in which the ultimate output of your work is not something that interacts directly with a user or client. In my line of work, machine learning and statistical modeling, the true output of the work is most often "answers to questions." You still need to write systematic code to be able to handle common questions, adjust for new questions, add new capabilities, etc.

The only way that such a thing could be commoditized into a front-end interface is if you could devise an interface that allowed for all the different kinds of questions that will be asked, the ways they will change, the new features that will be wanted -- because most of the work is taking some backend pipeline that is already optimized for being able to answer questions of type X, and then figuring out how to generalize it without losing any performance in order to also answer questions of type Y.

It's almost always highly specialized to the specific company and line of business involved, so consulting companies can pop up to take away some of the in-house work, but in general there is no conceivable "as-a-service" thing that could.

Thus, you're left with needing to manage your own backend, probably for quite a long time to come.

Finance, ML for search interfaces, small-data statistics consulting (like political statistics, ecology, and other fields), education analytics, and many other fields offer work that falls into these categories.

Basically, anywhere that there is a business or domain science researcher that needs ad hoc computer programs whose lives as programs will generally only serve to answer scientific questions for that researcher. The ad hoc nature of how the questions change most often mean that no service that pretends to put a front-end API over top of the science questions can adequately capture the variety of things that are needed, especially once the further need to heavily optimize them is added in.

[brad0]

I think as standards become more adopted it will become easier to use tooling for the majority of backend development.

What is it that keeps backend developers in a job? We write code to give access to data in a way a consumer can use.

ie: we have input, we process the input and give the output (CS 101)

Every time we write something new one or more of those three elements has changed. Input, Processing or Output.

eg:

Input: The DB has a new table with data you need to expose on the website

Processing: The list of comments need to be ordered by upvotes rather than chronologically

Output: The existing JSON output also needs to be output as protobuf

Whenever any one of these elements is standardised it reduces our workload. Usually as a result of standardisation tools and frameworks are developed to take advantage of this.

If you want to know the future of any technology keep on top of their standards.

EDIT:

As well as keeping track of standards you should extrapolate what would happen if everybody adopted that standard. Who knows, maybe you could build a tool everyone uses and start a business around it.

[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.