DEV Community

loading...

Discussion on: The next generation of programming is closer than you think

Collapse
jim_ej profile image
James Ellis-Jones

What's really interesting is to consider why these mundane repetitive tasks are not already abstracted away into code packages with config. What we see is that some of the work can be abstracted away e.g. Auth0 service or a React login form component. The problem is integrating these reuse elements vertically across the horizontal layers, and also how they interact with custom code and other similar components. In this example, how does the login component know where to find the Auth0 service? Does it tie you into Auth0 as a third party provider? Where are your users stored and how will your code and other components find them? Classic ASP.Net had a go at this as its components where server/client integrated but the resulting abstraction was leaky as a sieve and horrible to use. We need some innovations around code structure, reuse and interoperability to make this work. I look at some of this in this article: restspace.io/blog/Web%20reusabilit.... I'm also working on a way of having front end NPM component packages (like the React login component) express their back end API and infrastructure requirements declaratively and having a system which fulfils those requirements automatically on the back end.

Collapse
leob profile image
leob

That's very interesting ... having looked at Restspace, one thing that jumped out to me was the principle "Uniform interfaces to functionality" - that's very essential, example:

Something like Auth0 gives us a "chunk" of functionality (a service or a component, whatever you want to call it) that we can 'simply' drop into our app - this means writing less code, but we still write code, talking to the Auth0 API ... now, what if we don't want Auth0 but another service or component - we have to change our app, because that other service will have a different API - there is no standard!

In other words, because standard interfaces don't exist, we have to write "glue" code or adapters every single time. Even though we get a chunk of pre-made functionality, we still spend time because we need to fit a square peg into a round hole. This is what causes the "reinventing the wheel" syndrome, the feeling that as developers we're reimplementing the same trivial stuff time and again.

Compare that to the situation in other "industries", for instance construction or plumbing or you name it - those industries are chock full of standards, with names like DIN or ISO and so on. A plumber or an electrician buys a component (a pipe, or a faucet, or a transistor) with certain "specs" and then he/she can be sure that it will fit onto the other components he's purchased before.

Once we have these standard interfaces, then you can start inventing a very high level "specification language" which declaratively states what the components are and how they should interact. And then there would be a runtime which interprets this declarative "pseudo program" and makes the app or system come alive.

And for specific customizations or specialized parts of the system/app you could have "escapes" which allow you to hook into the program/runtime with snippets of code that you write in a conventional language (like Javascript).

Note that all of this becomes orders of magnitude easier if we reduce the degrees of freedom, so if we limit the options. So if we say, for instance, that we only support one target language (for instance, only Javascript, no PHP or Ruby or Python) then we reduce the complexity of this "platform" in a huge way. Same story if we'd say that we support only one database, and so on. So if we'd limit the number of options then we'd vastly simplify things.

(so part of the problem is that in the software world everyone and their brother (or sister) likes to invent their own programming language, database, frontend framework, CMS, and so on)

But, all of this is nice and good, but:

(a) pulling this off will require a monumental effort and a huge investment, and

(b) fragmentation won't end if a dozen alternative platforms like Restspace are popping up (in other words, there would still be no industry standard unless we make it so), and

(c) actually I'm afraid that there's not that much of an incentive to make this work, because you could very well argue that as an industry (developers) we'd be shooting ourselves in the foot!

In other words, the current situation where we're spending a lot of time eternally reinventing the wheel is of course a great job creator :-) and, in general we really like what we're doing, right now - so, in yet other words, in whose interest would this be ... at the same time I'm convinced that at some point in the future this status quo WILL change, whether we like it or not.

Thread Thread
jim_ej profile image
James Ellis-Jones

Great response! Yes this is pretty much what I'm trying to do with Restspace. One way of standardising the connection between components is that even small components running on the same server all use the data structure of an HTTP message to communicate. Within the same server, code level routing sends these HTTP data structures without using the wire, but the runtime determines if the URL is external and goes across the net if necessary. This creates internal interoperability, allows the components to be distributed across servers however you like, and potentially pulls in every API available on the internet. Then the structure of the API is standardised across services providing the same functionality by adapting internal and third party services. For instance, the basic data API is simply to do a GET to read data or a PUT/POST to write data to a url. Data structures are defined by JSON Schemas. The service providing this API can have an adapter plugged into it which talks to the file system, MongoDb, S3, a SQL database or whatever.

This then enables a module/package to know where and how it needs to store data. For instance the 'full stack' auth package can be told a url in the data store API for storing user records, and it immediately knows how to do this, without restricting what underlying technology you want to use. An email package then also knows how to get user data and can just be wired up to the url in order to get the user data to customise an email template.

To your points, having been working on this for a while, the effort is actually not that massive, at least to get a set of core functions together. There would likely be some fragmentation initially but like most of these things, there are network effects at work and the winner of an initial battle would become a de facto standard. Dev has constantly been pushing effort up the stack and away from the generic into the more distinctive aspects of applications. I recently saw a Twitter threads where devs listed the things they hated doing repeatedly, and those are the things a system like this would be ideal for.

Thread Thread
leob profile image
leob

Right, I see what your getting at, very interesting ... looks very well thought out with these services, pipelines, data transforms and so on:

restspace.io/

Very cool project and a great effort, I've saved this to my notes, looks worth trying out. By the way is it open source? I saw a couple of Github repos (github.com/restspace) but looks like that covers only a small part of it. Ah I see the answer here in the docs:

"We are also considering open-sourcing the runtime so you can run it wherever you wish"

So that would be "not yet but maybe in the future".

Thread Thread
jim_ej profile image
James Ellis-Jones

Many thanks for the kind words! Yes, basically I'd love to open source this but it will never fulfil its promise unless there is some cashflow to support development. Quite likely it will work as an open source project with a paid for hosting like the model Wordpress has, however it needs some thought how to do that without losing the chance to make some revenue. I'll definitely open source components which it makes sense to do.

Thread Thread
leob profile image
leob

Yes I definitely see what you mean, I get your point, totally.