14 ms·

A unified theory of low/no code and middleware

107 points by makaimc 5y ago

Closi 5y ago
A really good post - I think 'low/no' code generally gets a hard time on HackerNews, generally because it's place and application is misunderstood. The success of PowerApps is a huge part of the Microsoft Dynamics appeal in the ERP space for instance - and they seem to be winning this segment very quickly on the back of it with tremendous growth. The fact a relatively inexperienced user can create a new phone app that is fully integrated into the company ERP is a real point of difference.
- thrower123 5y ago
  I would rather write Spring beans or jam forks in my hand than try to glom Flow/PowerAutomate lego blocks together. When I have managed to staple together a workflow, it routinely stops working after a couple weeks. It's going to keep a lot of people employed keeping those things going as the platform shifts underneath you every six months, and/or yanking the Goldberg machines out into real code.
  - darkhorse13 5y ago
    That's what you would do because you can actually do it. But these tools are for people who don't know how to build those apps by writing actual code.
    - zozbot234 5y ago
      The point of "writing actual code" is that it's the only way we know about of managing even middling amounts of complexity. If you "don't know how to do that", you shouldn't be attempting that sort of deployment in the first place. It's just not going to be sustainable. There are ways of writing less code over time, but they're based on the sort of solid abstractions that are really not that common. (This is how "high level" coding works.) But the typical "low code" or "no code" system is not built like that.
      - Closi 5y ago
        Too much of the conversation ends up being about 'low code' vs 'writing actual code', but this is like arguing about if a hammer or a welding torch is a better tool. The reality is that some problems are fundamentally better suited to low code, and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this). Other problems will either be too complex, a poor fit, or simply not possible to implement within low-code tools. I'm not going to start developing a mobile game in PowerApps! I think the overall issue is "If all you have is a hammer, everything looks like a nail". The best thing is to recognise the relative strengths and weaknesses of the two approaches and pick the right tool for the job.
        zozbot234 5y ago
        > a new data-entry screen We used to call those data entry screens "HTML forms". And hey, they're even text based so you can commit them to a version control!
        Closi 5y ago
        In PowerApps they are called model-driven forms, and there is in-built version control! And although it's easy to write a HTML form, it tends to be slightly harder to write the code handling it on the backend to change the database, with full user/roll based authentication and validation - particularly if you are integrating it into your ERP. If the use case is a form to interact with Microsoft Dynamics, something built in PowerApps model-driven apps will be much more robust, quicker to develop and more secure than a html form with some custom handler.
        q-big 5y ago
        > and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this). Counterexample: MS Access apps are often a maintenance nightmare.
    - Closi 5y ago
      > But these tools are for people who don't know how to build those apps by writing actual code. IMO assuming low-code is just for people who don't know how to code is missing the power of low-code in the ERP/CRM space, and how that will be applicable to more spaces in the future. Besides, I can program but I can also build a simple application in a low-code solution quicker and it will usually be more reliable without lots of testing. IMO saying low-code is for people who don't know how to write actual code is like saying a typewriter is for people who don't know how to write with a pen - they are two different tools to get a job done, and sometimes a pen is better and sometimes a typewriter is better.
    - tonyedgecombe 5y ago
      I don't think that's the case, at least not completely. I worked with a low code product twenty years ago that was targeted at a narrow domain. In the right hands it was fantastic but it was useless as a crutch for people that couldn't even describe the problem they were trying to solve. The people that excelled with it were programmers and others who clearly had the ability to write software. The people that struggled were the ones that couldn't decompose a problem into its constituent parts, that didn't have sufficient attention to detail. It was a productive tool in the right hands, the only time we had problems were when it was mis-sold as a way to solve problems without needing problem solvers.
  - deleted 5y ago
    [deleted]
- void_mint 5y ago
  You'd never ask someone that fixes their own car what they find valuable in a good mechanic. You shouldn't ask a group of software developers what they find valuable in a no-code toolset.
  - convolvatron 5y ago
    no one else knows how much useless time wasting boilerplate crap goes into programming. or how fragile these systems really are. I'd be happy to lose my economic position as a possessor of arcane skills if we can stop trying to construct multistory buildings out of mud and learn to frame walls properly.
- valenterry 5y ago
  It's more like you can often hear people claim that no-code will replace code. Which to some degree is true - but not in the way it is sold. Most devs already use no-code an low-code and they know when to use what.
ignoramous 5y ago
I think the basic reason why low-code / no-code works is down to software bugs. Bugs are a function of number of engineers, features, moving parts, and significant lines of code. No-code takes out engineers, moving parts, and SLoC from the equation (as far as the enterprises buying these solutions are concerned), but leaves a lot to be desired in terms of feature set; low-code brings down number of engineers, and SLoC, whilst providing flexibility in terms of bespoke feature sets. Also, another reason is, in essence, No-code and Low-code are natural extension of the cloud computing model in which capex is traded away for opex. And economies of scale, over time ensures, Low-code / No-code is going to be cheaper yet more reliable than anything one (tech-enabled) enterprise can roll on their own.
- budibase 5y ago
  For Budibase, we often hear enterprises talk about two reasons for their interest: Cost of devs Speed of delivery (leading to faster growth and operations)
  - hughrr 5y ago
    That's kind of funny. Back in the early 00's I built a big perl "engine" for an internal LOB platform which roughly looked like your product. The business built their apps on it. But neither me or the business saw the value in the platform on its own. Big fail - perhaps I could have been the original Salesforce.com or something...
  - Artistry121 5y ago
    I’m really excited by Budibase but having some trouble getting up and running. Do y’all have any open work sessions for questions or demos? I found some on YouTube previously.
- indymike 5y ago
  You ought to have a look at the Zapier zapps our marketing team has created. Buggy, brittle, and just oh-so-better than nothing.
- gervwyk 5y ago
zozbot234 5y ago
Do we really need all the bespoke middleware stuff that OP goes on and on about, when practically all new, greenfield applications are based in some way or another on the Web and its open protocols? What middleware is still needed, other than the well-known semantic web and linked-data standards that have been developed specifically so that disparate applications from many vendors would be enabled to interoperate via a common Web platform, while allowing for user-directed extension and customization?
- Closi 5y ago
  The answer is 'yes, absolutely', particularly considering we are talking about Enterprise IT here. Take for instance a common integration point for these applications - sending a sales order to a warehouse management system (WMS). Even if both systems have RESTful API's there is no fixed standard for a sales order, so you need to at least do some mapping. Then maybe actually you find out WMS needs a reference from the transport management system that has to be merged into it, and this also has to go back to ERP (which isn't part of the standard 'send order' integration). This is why middleware programs exist. Enterprises often end up being bundles of random applications that all need to be informed about random stuff, and it's just not practical to expect the application vendors to know what applications need to be aware/informed of what.
  - zozbot234 5y ago
    This kind of mapping and data massaging is a comparatively manageable task if the applications themselves provide reasonably standard interfaces. There's no inherent reason for it to be provided out-of-the-box by a single, monolithic "middleware" platform.
    - Closi 5y ago
      If you are a large business the assumption that all applications will have reasonably standard interfaces won't hold water. Most ERP's or similar enterprise software will have some sort of mapping layer (e.g. mulesoft) otherwise they just won't be able to roll their software out into the real world.
maxrev17 5y ago
Tried a low-code plat recently. Ended up writing more js than I'd bargained for and then decided it'd be quicker and easier to write my own API to expose to the low code tool purely as a frontend. This was just simple composition of rest endpoints exposed via a 3rd party API - some looping. Maybe there's better platforms...be interested to hear which ones are working well for people.
- gervwyk 5y ago
  Check out https://lowdefy.com https://lowdefy.com - we recently open-sourced it. We’ve been building apps with Lowdefy for customers for a while now and very seldomly need to setup an API endpoint for a task. Often surprised how flexible it is, in one project we are rolling out full MRP for a food processing factory at the moment.
  - aszen 5y ago
    I had a look at your product, it seems like a good idea, using yaml to declaratively describe the ui. I'm curious though if this is actually low code, when I see the docs I still imagine it's actual developers who will be writing all the yaml or not. As more use cases pop up I actually expect the yaml to grow considerably complex, at which point you will need to reuse yaml blocks, reference other blocks and so on. Essentially it feels to me writing yaml is no different from coding using a high level library or framework.
    - kkevv 5y ago
      Especially curious what the actual distribution of users for these low code internal tools are. Theres a lot of rhetoric about how business users/operations can quickly create tools, but it really seems like developers are the main customer.
      - arey_abhishek 5y ago
        Most low code / no code products are used by developers. But a no code integration product like Zapier would have a high number of business users, while a low code product would have very few business users. Low code products tend to be aimed at developers in a hurry or ones with limited skills.
diervo 5y ago
The articulation of this theory was interesting, until the last sentence. > But, in this modern world, is Salesforce not just an expensive, $150 per employee deployment of Postgres? If that’s the author final conclusion, is hard to take any of the article seriously as it completely jeopardizes the value and complexity of any platform and therefore any layers on top , which was suppose to be part of the premise of the theory…
- mslotnick 5y ago
  this is in the context of Twilio as the new CRM — where a lot of current CRM functionality is merely one of many data inputs. ie biz logic and UI has moved to layers above. some exaggeration to make a point ;)
nexuist 5y ago
It's interesting the focus this article places on relational databases. The author insists that Salesforce must run on top of Oracle, or Postgres. The notion that any modern company wouldn't be using SQL somewhere in their daily process is outlandish. ...which is interesting, right? SQL won. There are no competitors. Everybody uses SQL. But if you ask developers how they develop their interfaces, you'll get a million answers, ranging from DOS terminals, Electron apps, PWAs, .NET forms, whatever. Maybe what we need is SQL for the view layer to complement the relational backend? SQL is famously easy to pick up because it allows the user to describe what they want, not how to get it. React and friends get us closer to this goal of universal reactive programming, but nothing/nobody has capitalized on providing an all-in-one "put words in this box and get what you want" type application. I guess the assumption is that building such a language is functionally impossible, but I really wonder if that's true. The app-building app that ultimately wins is going to be the one that lets you build any app, not just an app that serves a particular niche or business process.
- void_mint 5y ago
  > It's interesting the focus this article places on relational databases. The author insists that Salesforce must run on top of Oracle, or Postgres. The notion that any modern company wouldn't be using SQL somewhere in their daily process is outlandish. I think it's mostly that Salesforce was founded by an Oracle executive (and is just generally a bastion of enterprise software mess).
- valenterry 5y ago
  Isn't SQL more like the browser? Everyone uses SQL, everyone uses the browser. But the way they are used can be very different. You can also use SQL databases like a dump key-value store or with more sophistication like foreign-constraints etc.
  - jasfi 5y ago
    It's closer to HTML than the browser.
- bob1029 5y ago
singingfish 5y ago
Software AG's Webmethods is an oldno/low code middleware product, and I can assure you from a maintenance / transparency perspective it's a total disaster. Also it's used by lots of big organisations - supermarkets, logistics, manufacturing etc.

107 points by makaimc 5y ago

A really good post - I think 'low/no' code generally gets a hard time on HackerNews, generally because it's place and application is misunderstood. The success of PowerApps is a huge part of the Microsoft Dynamics appeal in the ERP space for instance - and they seem to be winning this segment very quickly on the back of it with tremendous growth. The fact a relatively inexperienced user can create a new phone app that is fully integrated into the company ERP is a real point of difference.

thrower123 5y ago
I would rather write Spring beans or jam forks in my hand than try to glom Flow/PowerAutomate lego blocks together. When I have managed to staple together a workflow, it routinely stops working after a couple weeks. It's going to keep a lot of people employed keeping those things going as the platform shifts underneath you every six months, and/or yanking the Goldberg machines out into real code.
- darkhorse13 5y ago
  That's what you would do because you can actually do it. But these tools are for people who don't know how to build those apps by writing actual code.
  - zozbot234 5y ago
    The point of "writing actual code" is that it's the only way we know about of managing even middling amounts of complexity. If you "don't know how to do that", you shouldn't be attempting that sort of deployment in the first place. It's just not going to be sustainable. There are ways of writing less code over time, but they're based on the sort of solid abstractions that are really not that common. (This is how "high level" coding works.) But the typical "low code" or "no code" system is not built like that.
    - Closi 5y ago
      Too much of the conversation ends up being about 'low code' vs 'writing actual code', but this is like arguing about if a hammer or a welding torch is a better tool. The reality is that some problems are fundamentally better suited to low code, and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this). Other problems will either be too complex, a poor fit, or simply not possible to implement within low-code tools. I'm not going to start developing a mobile game in PowerApps! I think the overall issue is "If all you have is a hammer, everything looks like a nail". The best thing is to recognise the relative strengths and weaknesses of the two approaches and pick the right tool for the job.
      - zozbot234 5y ago
        > a new data-entry screen We used to call those data entry screens "HTML forms". And hey, they're even text based so you can commit them to a version control!
        Closi 5y ago
        In PowerApps they are called model-driven forms, and there is in-built version control! And although it's easy to write a HTML form, it tends to be slightly harder to write the code handling it on the backend to change the database, with full user/roll based authentication and validation - particularly if you are integrating it into your ERP. If the use case is a form to interact with Microsoft Dynamics, something built in PowerApps model-driven apps will be much more robust, quicker to develop and more secure than a html form with some custom handler.
      - q-big 5y ago
        > and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this). Counterexample: MS Access apps are often a maintenance nightmare.
  - Closi 5y ago
    > But these tools are for people who don't know how to build those apps by writing actual code. IMO assuming low-code is just for people who don't know how to code is missing the power of low-code in the ERP/CRM space, and how that will be applicable to more spaces in the future. Besides, I can program but I can also build a simple application in a low-code solution quicker and it will usually be more reliable without lots of testing. IMO saying low-code is for people who don't know how to write actual code is like saying a typewriter is for people who don't know how to write with a pen - they are two different tools to get a job done, and sometimes a pen is better and sometimes a typewriter is better.
  - tonyedgecombe 5y ago
    I don't think that's the case, at least not completely. I worked with a low code product twenty years ago that was targeted at a narrow domain. In the right hands it was fantastic but it was useless as a crutch for people that couldn't even describe the problem they were trying to solve. The people that excelled with it were programmers and others who clearly had the ability to write software. The people that struggled were the ones that couldn't decompose a problem into its constituent parts, that didn't have sufficient attention to detail. It was a productive tool in the right hands, the only time we had problems were when it was mis-sold as a way to solve problems without needing problem solvers.
- deleted 5y ago
  [deleted]
void_mint 5y ago
You'd never ask someone that fixes their own car what they find valuable in a good mechanic. You shouldn't ask a group of software developers what they find valuable in a no-code toolset.
- convolvatron 5y ago
  no one else knows how much useless time wasting boilerplate crap goes into programming. or how fragile these systems really are. I'd be happy to lose my economic position as a possessor of arcane skills if we can stop trying to construct multistory buildings out of mud and learn to frame walls properly.
valenterry 5y ago
It's more like you can often hear people claim that no-code will replace code. Which to some degree is true - but not in the way it is sold. Most devs already use no-code an low-code and they know when to use what.

ignoramous 5y ago

I think the basic reason why low-code / no-code works is down to software bugs. Bugs are a function of number of engineers, features, moving parts, and significant lines of code. No-code takes out engineers, moving parts, and SLoC from the equation (as far as the enterprises buying these solutions are concerned), but leaves a lot to be desired in terms of feature set; low-code brings down number of engineers, and SLoC, whilst providing flexibility in terms of bespoke feature sets. Also, another reason is, in essence, No-code and Low-code are natural extension of the cloud computing model in which capex is traded away for opex. And economies of scale, over time ensures, Low-code / No-code is going to be cheaper yet more reliable than anything one (tech-enabled) enterprise can roll on their own.

budibase 5y ago
For Budibase, we often hear enterprises talk about two reasons for their interest: Cost of devs Speed of delivery (leading to faster growth and operations)
- hughrr 5y ago
  That's kind of funny. Back in the early 00's I built a big perl "engine" for an internal LOB platform which roughly looked like your product. The business built their apps on it. But neither me or the business saw the value in the platform on its own. Big fail - perhaps I could have been the original Salesforce.com or something...
- Artistry121 5y ago
  I’m really excited by Budibase but having some trouble getting up and running. Do y’all have any open work sessions for questions or demos? I found some on YouTube previously.
indymike 5y ago
You ought to have a look at the Zapier zapps our marketing team has created. Buggy, brittle, and just oh-so-better than nothing.
gervwyk 5y ago

zozbot234 5y ago

Do we really need all the bespoke middleware stuff that OP goes on and on about, when practically all new, greenfield applications are based in some way or another on the Web and its open protocols? What middleware is still needed, other than the well-known semantic web and linked-data standards that have been developed specifically so that disparate applications from many vendors would be enabled to interoperate via a common Web platform, while allowing for user-directed extension and customization?

Closi 5y ago
The answer is 'yes, absolutely', particularly considering we are talking about Enterprise IT here. Take for instance a common integration point for these applications - sending a sales order to a warehouse management system (WMS). Even if both systems have RESTful API's there is no fixed standard for a sales order, so you need to at least do some mapping. Then maybe actually you find out WMS needs a reference from the transport management system that has to be merged into it, and this also has to go back to ERP (which isn't part of the standard 'send order' integration). This is why middleware programs exist. Enterprises often end up being bundles of random applications that all need to be informed about random stuff, and it's just not practical to expect the application vendors to know what applications need to be aware/informed of what.
- zozbot234 5y ago
  This kind of mapping and data massaging is a comparatively manageable task if the applications themselves provide reasonably standard interfaces. There's no inherent reason for it to be provided out-of-the-box by a single, monolithic "middleware" platform.
  - Closi 5y ago
    If you are a large business the assumption that all applications will have reasonably standard interfaces won't hold water. Most ERP's or similar enterprise software will have some sort of mapping layer (e.g. mulesoft) otherwise they just won't be able to roll their software out into the real world.

maxrev17 5y ago

Tried a low-code plat recently. Ended up writing more js than I'd bargained for and then decided it'd be quicker and easier to write my own API to expose to the low code tool purely as a frontend. This was just simple composition of rest endpoints exposed via a 3rd party API - some looping. Maybe there's better platforms...be interested to hear which ones are working well for people.

gervwyk 5y ago
Check out https://lowdefy.com https://lowdefy.com - we recently open-sourced it. We’ve been building apps with Lowdefy for customers for a while now and very seldomly need to setup an API endpoint for a task. Often surprised how flexible it is, in one project we are rolling out full MRP for a food processing factory at the moment.
- aszen 5y ago
  I had a look at your product, it seems like a good idea, using yaml to declaratively describe the ui. I'm curious though if this is actually low code, when I see the docs I still imagine it's actual developers who will be writing all the yaml or not. As more use cases pop up I actually expect the yaml to grow considerably complex, at which point you will need to reuse yaml blocks, reference other blocks and so on. Essentially it feels to me writing yaml is no different from coding using a high level library or framework.
  - kkevv 5y ago
    Especially curious what the actual distribution of users for these low code internal tools are. Theres a lot of rhetoric about how business users/operations can quickly create tools, but it really seems like developers are the main customer.
    - arey_abhishek 5y ago
      Most low code / no code products are used by developers. But a no code integration product like Zapier would have a high number of business users, while a low code product would have very few business users. Low code products tend to be aimed at developers in a hurry or ones with limited skills.

diervo 5y ago

The articulation of this theory was interesting, until the last sentence. > But, in this modern world, is Salesforce not just an expensive, $150 per employee deployment of Postgres? If that’s the author final conclusion, is hard to take any of the article seriously as it completely jeopardizes the value and complexity of any platform and therefore any layers on top , which was suppose to be part of the premise of the theory…

mslotnick 5y ago
this is in the context of Twilio as the new CRM — where a lot of current CRM functionality is merely one of many data inputs. ie biz logic and UI has moved to layers above. some exaggeration to make a point ;)

nexuist 5y ago

It's interesting the focus this article places on relational databases. The author insists that Salesforce must run on top of Oracle, or Postgres. The notion that any modern company wouldn't be using SQL somewhere in their daily process is outlandish. ...which is interesting, right? SQL won. There are no competitors. Everybody uses SQL. But if you ask developers how they develop their interfaces, you'll get a million answers, ranging from DOS terminals, Electron apps, PWAs, .NET forms, whatever. Maybe what we need is SQL for the view layer to complement the relational backend? SQL is famously easy to pick up because it allows the user to describe what they want, not how to get it. React and friends get us closer to this goal of universal reactive programming, but nothing/nobody has capitalized on providing an all-in-one "put words in this box and get what you want" type application. I guess the assumption is that building such a language is functionally impossible, but I really wonder if that's true. The app-building app that ultimately wins is going to be the one that lets you build any app, not just an app that serves a particular niche or business process.

void_mint 5y ago
> It's interesting the focus this article places on relational databases. The author insists that Salesforce must run on top of Oracle, or Postgres. The notion that any modern company wouldn't be using SQL somewhere in their daily process is outlandish. I think it's mostly that Salesforce was founded by an Oracle executive (and is just generally a bastion of enterprise software mess).
valenterry 5y ago
Isn't SQL more like the browser? Everyone uses SQL, everyone uses the browser. But the way they are used can be very different. You can also use SQL databases like a dump key-value store or with more sophistication like foreign-constraints etc.
- jasfi 5y ago
  It's closer to HTML than the browser.
bob1029 5y ago

singingfish 5y ago

Software AG's Webmethods is an oldno/low code middleware product, and I can assure you from a maintenance / transparency perspective it's a total disaster. Also it's used by lots of big organisations - supermarkets, logistics, manufacturing etc.