41–50 of 52 posts
Suggestion, /mon -> /mo or /month or per month Number of API calls per month of 100K for $15 is just too low, you can have decent dedicated servers running per month for $5 & that could very well handle 86400*30 at 1 request per second.
I know it might sound not so logical for you, but it's not how pricing works.
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…
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.
Stuff like this is where a lot of no-code stuff falls down.
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…
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.
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...
Am I reading this right? There's no security or granular access control? If you connect a resource, like a postgresql db - anyone with access to the front-end client (anyone with the api key; that is everyone) - can read and write to all tables? That's... Not great? https://slashapi.com/docs/pgsql#content-api-endpoints
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 lear…
Could we please stop using this "no code required" bullshit? You have to configure it somehow and once you get to the edge of "we guess what our customer needs", which is quite soon, you quickly get to the docs for advanced users where you have to use code in the end again...