5 ms·

The awkward journey towards less back end

70 points by wolframhempel 10y ago

nbevans 10y ago
"In the olden days, being a backend developer meant that you wrote a long list of functions that mapped to HTTP requests. A post to /item/14 was turned into createItem( id ) — and we liked it that way." That's not true at all. A good place to stop reading.
- asimuvPR 10y ago
  That part had me read further multiple times. It was hard to understand the point behind the post. Its an obvious advertisement for a product but it could have at least provided a better explanation of why a simple data store may prove to be more effective for applications that are CRUD front ends. Instead, the post tries to sell the benefits of a data store that can be expanded with backend services. Which is funny given the title.
- manyxcxi 10y ago
  Well they just glossed over the asynchronous processes that had to be kicked off, the analytics that had to be recorded, the instrumentation that was plumbed in, the validity and safety of the request prior to doing anything, the caching layers that need updating, the websocket client updates, and the design of the object model in the first place. But we knew that's what the author meant. /s
- pjmlp 10y ago
  I agree with the sentiment. As a generalist developer I have worked at all levels of the stack on front-end and back-end, depending on the project and never had a backend stack being "a long list of functions that mapped to HTTP requests". Maybe in the SV world of SPA applications it is like that, but backend is so much richer than that, specially in distributed computing scenarios.
notacoward 10y ago
The funny thing about this is that the actual back end - i.e. the thing that provides all those high-semantic-level services to the front end - is becoming more complex than ever. What this author calls the back end (and which I would call the back-end interface) of an application previously only needed to serve that application's particular needs and usage patterns. As the front/back line moves so that the same logic becomes part of the back end, it now has to satisfy any possible need or usage pattern - including many that will never actually materialize. As data structures move from the front end to the back end, more code must be added to provide security for them. This is all great for reusability etc. but it does add complexity (including failure complexity) and overhead. As always, such decisions require deep understanding of the tradeoffs involved, and sober judgment of whether the effort is worth it. Only time will tell whether such understanding and judgment will be the norm or the exception. As a grumpy old programmer, I think you can guess where I'd place my bets. ;)
- pluma 10y ago
  Case in point: ArangoDB lets you run "backend code" directly on the database[0]. This allows the "backend interface" to become a dumb client without adding external services to the stack. [0]: https://www.arangodb.com/why-arangodb/foxx/ https://www.arangodb.com/why-arangodb/foxx/ (Disclosure: I work on ArangoDB Foxx)
  - madeofpalk 10y ago
    You mean 'stored procedures'?
    - pluma 10y ago
      If you want to define "stored procedures" as "application code running in the database", yes. But traditional stored procedures are to ArangoDB Foxx what "copying files with timestamps on a network drive" is to version control.
      - mixedCase 10y ago
tech2 10y ago
Concepts like this seem fine a lot of the time for simple apps, but eventually you're going to want to _do_ something with the data. Query its history, integrate with other systems, etc. I read an aphorism of sorts a long time ago that basically stated that your software is _relatively_ unimportant, it's the data that's you should worry about. Think about that before trusting that random system X can handle your data for you.
- Svenskunganka 10y ago
  Since Deepstream just plugs into whatever database you want to use, you still have the possibility to query history, integrate with other systems, and so on - without using Deepstream at all, but at the same time you can do that using Deepstream as well.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
falcolas 10y ago
This feels like clickbait around an advertisement. They are offering your basic CRUD DB operations via an API, and throwing in DB triggers as a bonus. This doesn't strike me as a hard problem to solve, if I'm honest; especially in a world where GAE, Lambda, Flask, and Rails exist.
- tootie 10y ago
  It's an iteration on those frameworks. Not ground breaking, but it's a new option.
deleted 10y ago
[deleted]
caub 10y ago
meteor is a non-sense (but well I'd say rails too, and php shits too)
donatj 10y ago
I have always been of the mind that the actual things of value your app does, the parts that actually make money, it does server side. That hasn't changed with single page apps and phone apps. Our back end has slimmed but the things of actual value, the things others don't offer all happen server side. For instance in our case most of the "magic" takes place by processing hundreds of gigabytes of combined users data, data we couldn't send to the front end for reasons of both volume and privacy.
- troika 10y ago
  Yup, but we've build this trading app https://vimeo.com/143728632 https://vimeo.com/143728632 using just deepstream - it does get you quite far
  - pheeney 10y ago
    The website and twitter account appear offline. Is there more information about the technology somewhere?
michaelbuckbee 10y ago
I think this is interesting, but perhaps not described the best way in this piece. I'd say it's more along the lines of a Parse like service where: - you own your data - you choose your datastore - you get an easy to develop against service for client interactions without sacrificing back-end flexibility (aka you can still run SQL queries for reporting)
StavrosK 10y ago
It's not towards "less back end", and it's not "awkward". Since the dawn of time, everyone has been trying to do more stuff with less energy. Backend, frontend, transportation, everything. That's why there are frameworks, and that's why, these days, we're fortunate enough to be able to glue a heap of libraries together and pretty much only need to write the functionality that's novel. I think that the author is doing everyone a disservice by framing it like that. I don't even know where to begin to detail where he's wrong: Backend devs are the first people who want to write less backend (they're the ones writing all the libraries!), deepstream isn't a novel idea (it looks like it makes the 90% easy and the 10% horrible), pushing all the code to the client isn't a good idea (just imagine how long it would take to update every client when you discover a critical bug, rather than the three minutes you can update the server), etc etc. It's a nice service that will allow people to prototype much faster and more easily, and I guess the controversial stance and title of the article worked very well for getting the clicks.
inestyne 10y ago
Imagine a world where your given 5 million dollars and a business model; the only real guard rail being 'don't walk us off a cliff...'. It's not fun and games anymore is it? A huge percentage of the code I write has nothing to do with the front-end. Am I going to hang my project's fate on a platform created solely with quick and cheap front-end development in mind? Probably not. I do remember the bad old days when all you really had was a thick native client, a database, and scheduled tasks. So there is precedence, i'm just not sure it's good one? :) I like Node, I like Meteor, not ready yet, but close. I like the idea of sharing logic, data, and state that way. Not happy about the sideways protocol. Leaves Node available for the crap I don't want to run on the client. Pretty sure the magical disappearing back-end (OP) idea is a dead end tho.
wired_devil 10y ago
So, what back-end deepstream uses?
erikb 10y ago
I didn't really get what it wants to do different than CouchDB. If you call your data access a database or an app or whatever doesn't change that it is what it is.
stevenwiles 10y ago
ROFL totes awks. Upvote.

70 points by wolframhempel 10y ago

"In the olden days, being a backend developer meant that you wrote a long list of functions that mapped to HTTP requests. A post to /item/14 was turned into createItem( id ) — and we liked it that way." That's not true at all. A good place to stop reading.

asimuvPR 10y ago
That part had me read further multiple times. It was hard to understand the point behind the post. Its an obvious advertisement for a product but it could have at least provided a better explanation of why a simple data store may prove to be more effective for applications that are CRUD front ends. Instead, the post tries to sell the benefits of a data store that can be expanded with backend services. Which is funny given the title.
manyxcxi 10y ago
Well they just glossed over the asynchronous processes that had to be kicked off, the analytics that had to be recorded, the instrumentation that was plumbed in, the validity and safety of the request prior to doing anything, the caching layers that need updating, the websocket client updates, and the design of the object model in the first place. But we knew that's what the author meant. /s
pjmlp 10y ago
I agree with the sentiment. As a generalist developer I have worked at all levels of the stack on front-end and back-end, depending on the project and never had a backend stack being "a long list of functions that mapped to HTTP requests". Maybe in the SV world of SPA applications it is like that, but backend is so much richer than that, specially in distributed computing scenarios.

notacoward 10y ago

The funny thing about this is that the actual back end - i.e. the thing that provides all those high-semantic-level services to the front end - is becoming more complex than ever. What this author calls the back end (and which I would call the back-end interface) of an application previously only needed to serve that application's particular needs and usage patterns. As the front/back line moves so that the same logic becomes part of the back end, it now has to satisfy any possible need or usage pattern - including many that will never actually materialize. As data structures move from the front end to the back end, more code must be added to provide security for them. This is all great for reusability etc. but it does add complexity (including failure complexity) and overhead. As always, such decisions require deep understanding of the tradeoffs involved, and sober judgment of whether the effort is worth it. Only time will tell whether such understanding and judgment will be the norm or the exception. As a grumpy old programmer, I think you can guess where I'd place my bets. ;)

pluma 10y ago
Case in point: ArangoDB lets you run "backend code" directly on the database[0]. This allows the "backend interface" to become a dumb client without adding external services to the stack. [0]: https://www.arangodb.com/why-arangodb/foxx/ https://www.arangodb.com/why-arangodb/foxx/ (Disclosure: I work on ArangoDB Foxx)
- madeofpalk 10y ago
  You mean 'stored procedures'?
  - pluma 10y ago
    If you want to define "stored procedures" as "application code running in the database", yes. But traditional stored procedures are to ArangoDB Foxx what "copying files with timestamps on a network drive" is to version control.
    - mixedCase 10y ago

tech2 10y ago

Concepts like this seem fine a lot of the time for simple apps, but eventually you're going to want to _do_ something with the data. Query its history, integrate with other systems, etc. I read an aphorism of sorts a long time ago that basically stated that your software is _relatively_ unimportant, it's the data that's you should worry about. Think about that before trusting that random system X can handle your data for you.

Svenskunganka 10y ago
Since Deepstream just plugs into whatever database you want to use, you still have the possibility to query history, integrate with other systems, and so on - without using Deepstream at all, but at the same time you can do that using Deepstream as well.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

falcolas 10y ago

This feels like clickbait around an advertisement. They are offering your basic CRUD DB operations via an API, and throwing in DB triggers as a bonus. This doesn't strike me as a hard problem to solve, if I'm honest; especially in a world where GAE, Lambda, Flask, and Rails exist.

tootie 10y ago
It's an iteration on those frameworks. Not ground breaking, but it's a new option.

deleted 10y ago

[deleted]

caub 10y ago

meteor is a non-sense (but well I'd say rails too, and php shits too)

donatj 10y ago

I have always been of the mind that the actual things of value your app does, the parts that actually make money, it does server side. That hasn't changed with single page apps and phone apps. Our back end has slimmed but the things of actual value, the things others don't offer all happen server side. For instance in our case most of the "magic" takes place by processing hundreds of gigabytes of combined users data, data we couldn't send to the front end for reasons of both volume and privacy.

troika 10y ago
Yup, but we've build this trading app https://vimeo.com/143728632 https://vimeo.com/143728632 using just deepstream - it does get you quite far
- pheeney 10y ago
  The website and twitter account appear offline. Is there more information about the technology somewhere?

michaelbuckbee 10y ago

I think this is interesting, but perhaps not described the best way in this piece. I'd say it's more along the lines of a Parse like service where: - you own your data - you choose your datastore - you get an easy to develop against service for client interactions without sacrificing back-end flexibility (aka you can still run SQL queries for reporting)

StavrosK 10y ago

It's not towards "less back end", and it's not "awkward". Since the dawn of time, everyone has been trying to do more stuff with less energy. Backend, frontend, transportation, everything. That's why there are frameworks, and that's why, these days, we're fortunate enough to be able to glue a heap of libraries together and pretty much only need to write the functionality that's novel. I think that the author is doing everyone a disservice by framing it like that. I don't even know where to begin to detail where he's wrong: Backend devs are the first people who want to write less backend (they're the ones writing all the libraries!), deepstream isn't a novel idea (it looks like it makes the 90% easy and the 10% horrible), pushing all the code to the client isn't a good idea (just imagine how long it would take to update every client when you discover a critical bug, rather than the three minutes you can update the server), etc etc. It's a nice service that will allow people to prototype much faster and more easily, and I guess the controversial stance and title of the article worked very well for getting the clicks.

inestyne 10y ago

Imagine a world where your given 5 million dollars and a business model; the only real guard rail being 'don't walk us off a cliff...'. It's not fun and games anymore is it? A huge percentage of the code I write has nothing to do with the front-end. Am I going to hang my project's fate on a platform created solely with quick and cheap front-end development in mind? Probably not. I do remember the bad old days when all you really had was a thick native client, a database, and scheduled tasks. So there is precedence, i'm just not sure it's good one? :) I like Node, I like Meteor, not ready yet, but close. I like the idea of sharing logic, data, and state that way. Not happy about the sideways protocol. Leaves Node available for the crap I don't want to run on the client. Pretty sure the magical disappearing back-end (OP) idea is a dead end tho.

wired_devil 10y ago

So, what back-end deepstream uses?

erikb 10y ago

I didn't really get what it wants to do different than CouchDB. If you call your data access a database or an app or whatever doesn't change that it is what it is.

stevenwiles 10y ago

ROFL totes awks. Upvote.