5 ms·
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
by 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 agoCase 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 agoYou mean 'stored procedures'?
- pluma 10y agoIf 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 agoIt's so funny that someone even downvoted you for calling him out on his bs. Databases like Postgres can run languages like JavaScript or Python for their stored procedures. ArangoDB does nothing new in that regard.
- pluma 10y agoLet's try a more detailed comparison: 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.
- mixedCase 10y agoIf what you need is a REST API there are solutions for it that use Postgres, namely http://postgrest.com/ http://postgrest.com/
- pluma 10y agoIf 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).