CEO of Restspace.io, which lets you build and integrate backends with tiny services and no code. Been CTO and developed across the stack at a range of agencies and startups.
Generally no code tools ARE visual development tools. A common characteristic of these tools is a graph idiom, where nodes represent processing units and lines, data paths between them. I think what they represent is less a visual approach to coding than a graphical approach to coding. If your primitives are processing nodes, it can be very powerful and quick to compose those nodes into networks. The extra work required to leverage preprogrammed units is much less than with a programming language.
This is because of the simplicity and universality of a data pipeline as a connector compared to a call signature. We find this graph idiom again in the attraction of microservices, with the edges being HTTP connections. Reconfiguration of very loosely coupled cohesive units is a powerful way of achieving new functionality with little work. Unix pipelines leverage this too.
I'm working on a framework which lets you construct pipelines of HTTP services declaratively with scripts. This has the advantage of being open to and inclusive of any existing HTTP service on the net, but provides a core set of primitive mini services which enable building a lot of powerful and useful back end functionality. Also it (will) let you build your own mini services rather like serverless functions. Here's an article where I explore the ideas around this further: restspace.io/blog/Web%20reusabilit...
One additional space that heavily uses graph nodes/paths is Reaktor, which I was tempted to add a whole diatribe on flow based programming and its uses like in the music industry native-instruments.com/en/products...
An HTTP service composer using this structure sounds amazing
CEO of Restspace.io, which lets you build and integrate backends with tiny services and no code. Been CTO and developed across the stack at a range of agencies and startups.
Yes indeed the GUIs on synth/sequencing tools have always impressed the hell out of me. The general paradigm of the modular synthesiser is exactly what I'm describing: a graph of control/signal cables with the nodes being sound processors. Thanks for the term 'flow based programming', I'm going to read up on that!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Generally no code tools ARE visual development tools. A common characteristic of these tools is a graph idiom, where nodes represent processing units and lines, data paths between them. I think what they represent is less a visual approach to coding than a graphical approach to coding. If your primitives are processing nodes, it can be very powerful and quick to compose those nodes into networks. The extra work required to leverage preprogrammed units is much less than with a programming language.
This is because of the simplicity and universality of a data pipeline as a connector compared to a call signature. We find this graph idiom again in the attraction of microservices, with the edges being HTTP connections. Reconfiguration of very loosely coupled cohesive units is a powerful way of achieving new functionality with little work. Unix pipelines leverage this too.
I'm working on a framework which lets you construct pipelines of HTTP services declaratively with scripts. This has the advantage of being open to and inclusive of any existing HTTP service on the net, but provides a core set of primitive mini services which enable building a lot of powerful and useful back end functionality. Also it (will) let you build your own mini services rather like serverless functions. Here's an article where I explore the ideas around this further: restspace.io/blog/Web%20reusabilit...
Great points and super well put.
One additional space that heavily uses graph nodes/paths is Reaktor, which I was tempted to add a whole diatribe on flow based programming and its uses like in the music industry native-instruments.com/en/products...
An HTTP service composer using this structure sounds amazing
Yes indeed the GUIs on synth/sequencing tools have always impressed the hell out of me. The general paradigm of the modular synthesiser is exactly what I'm describing: a graph of control/signal cables with the nodes being sound processors. Thanks for the term 'flow based programming', I'm going to read up on that!