Hacker News new | ask | show | jobs
by jawns 1761 days ago
Not to dump on this service in particular, but there are a lot of "No Code / Low Code" platforms out there, and many of them miss the mark on their intended audience.

If the intended audience is non-technical users who don't know how to code, then it makes sense to allow them to do things without code. Essentially, you're acting as a declarative interface, where the user tells you what they want done, and they don't have to worry about how you do it at the code level.

But if the intended audience is technical, and users do know how to code, then in general what they really want is to write code more efficiently -- that is, write less boilerplate code -- not to have all the code abstracted away. Because they know that abstractions leak.

In the case of a service to build REST APIs, where the intended audience is more technical, my guess is that what most devs desire is not to introduce another service layer into their application, but to be able to easily generate all the boilerplate and then easily modify it to fit their use cases.

3 comments

I find the no-low-code trend really interesting, because it shines a light on the difference in perspective between programmers and non-programmers. It's generally assumed that "code is complex", and therefore that's where the complexity lies in producing software. It's a reasonable assumption if you're looking at it from the outside, but anyone who codes knows that complexity is, well, complex.
Here's my thinking:

1. There is a lot of complexity in building, deploying and maintaining software

2. There is a lot of complexity in understanding a domain and figuring out precise business logic

Often, (1) and (2) are known by different people, from technology and business functions. There is a communication overhead.

We can eliminate the communication overhead if (1) and (2) are known by the same person. But learning to code is hard... so if we make the programming easier (or even "no code") then people who know (2) can easily pick up (1)!

Ultimately though, I'm not convinced that (1) will ever be easy...

In all seriousness, in the real world the business types don't actually know the precise business logic, and the people who know number 1 are the ones that have to figure it out.
I've always found the complexity was implementing business requirements. for example if field x is "y" then fields g is required, and field f can only be these three choices. and if field g is filled in, then field x can not be y

Stuff like this is where a lot of no-code stuff falls down.

I find it difficult to agree with this statement. But perhaps I am biased towards no-code.

I have always been able to find a way around when implementing complex business logic.

A very peculiar use case I had to solve was for a parking slot booking app - limited spots available, one spot can hold either one large vehicle (car) or six 2-wheelers.

So essentially it became like how you mentioned-> if x=car then parking spots available can only be N choices. If x = bike, then spots is 6N or 6(N-1) if someone booked a spot for a car. If spots remaining = 3 then x can not be Car.

Took me a couple of days to get it working but i was in the end able to get a working app built purely with no-code on DronaHQ.

Disclaimer - I work with DronaHQ.

Yep exactly. I've found that to be the case as well.
Absolutely, agree with you. Creating value out of abstraction is generally driven by domain/use cases. For eg. in this case if I get an email from a customer with pictures on my gmail account, post it on instagram. Now, this is an use case that this abstracted but creates value.

Simple API abstracted leads to leaky abstract you are at the developer's discretion to implement it. With a concrete use case, abstraction is bounded.

We will think about this for sure. Anyway, Thank you, I appreciate your taking the time to write. We value and respect your opinion.