"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.
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.
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.
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.
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. ;)
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.
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.
Stored procedures are typically used for access control, data validation and code re-use. Foxx can of course be used for the same purposes.
However while no sane person would want to expose a Postgres database to an external client, Foxx can be used to create REST APIs.
There are proposals to add an HTTP API to Postgres so I would assume that there is a lot of demand for such use-cases.
So stored procedures are just the basis and extensions like the ones Postgres plans to build on top of them are comparable to the native Foxx framework ArangoDB has already been offering for years.
It's also possible to use user-defined functions in ArangoDB's query language, which are a more obvious equivalent of traditional stored procedures in SQL. Unlike these functions Foxx allows developers to build entire data-centric microservices. Additionally Foxx provides access to a wide range of JavaScript libraries via support for Node.js-style modules.
If you just want a REST API for your database, sure, PostgREST does that for Postgres. But Foxx lets you specify your own endpoints, not just expose the DB via REST (which ArangoDB already can do out of the box). IOW: if you just want to talk to your DB over REST and manipulate documents directly, ArangoDB's native REST API is the equivalent of PostgREST.
If you want arbitrary HTTP endpoints with logic you define yourself, bundled as isolated modules with an express-like router API, Foxx is currently the only way to do that within a database. It allows you to colocate your data-centric application logic with the data it operates on (or even remove the need for exposing sensitive data altogether by handling application-level auth/auth within the database).
The only equivalent I can think of personally are CouchApps in CouchDB but they are necessarily far more limited in scope (because CouchDB isn't built to support complex or ad hoc queries).
"But Foxx lets you specify your own endpoints ... Foxx is currently the only way to do that within a database" ... so you mean like /rpc/storred_precedure_name in PostgREST :)?
(don't get me wrong, anyone capable of writing a db from scratch is a genius, good job and good luck)
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.
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.
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.
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.
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)
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.
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.
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.
30 comments
[ 3.2 ms ] story [ 67.2 ms ] threadThat's not true at all. A good place to stop reading.
But we knew that's what the author meant. /s
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.
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. ;)
[0]: https://www.arangodb.com/why-arangodb/foxx/
(Disclosure: I work on ArangoDB Foxx)
Databases like Postgres can run languages like JavaScript or Python for their stored procedures. ArangoDB does nothing new in that regard.
Stored procedures are typically used for access control, data validation and code re-use. Foxx can of course be used for the same purposes.
However while no sane person would want to expose a Postgres database to an external client, Foxx can be used to create REST APIs.
There are proposals to add an HTTP API to Postgres so I would assume that there is a lot of demand for such use-cases.
So stored procedures are just the basis and extensions like the ones Postgres plans to build on top of them are comparable to the native Foxx framework ArangoDB has already been offering for years.
It's also possible to use user-defined functions in ArangoDB's query language, which are a more obvious equivalent of traditional stored procedures in SQL. Unlike these functions Foxx allows developers to build entire data-centric microservices. Additionally Foxx provides access to a wide range of JavaScript libraries via support for Node.js-style modules.
If you want arbitrary HTTP endpoints with logic you define yourself, bundled as isolated modules with an express-like router API, Foxx is currently the only way to do that within a database. It allows you to colocate your data-centric application logic with the data it operates on (or even remove the need for exposing sensitive data altogether by handling application-level auth/auth within the database).
The only equivalent I can think of personally are CouchApps in CouchDB but they are necessarily far more limited in scope (because CouchDB isn't built to support complex or ad hoc queries).
(don't get me wrong, anyone capable of writing a db from scratch is a genius, good job and good luck)
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.
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)
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.
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.