We built this initially only to turn the database into API, after ask to users, we found that some people need more than just accessing the database. For example, they want to send notifications to Slack/Telegram when an event happens in the database, or they need to upload a file to the cloud storage, then put the information to their database. That's why we put another service, although they also have an API.
Our goal is to make their needs covered in a single platform. Currently, we are working on the "API Workflow" to simplify the process above, so they don't need to write multiple API request in their app.
what happens when we hit rate limit on the upstream service?
We will just return the response from the upstream service? And user will get rate limit error. We plan to cache the API calls (can be configured by user) to avoid making repetitive API calls to the upstream.
Anyway, Thank you. We value and respect your opinion. It means a lot for us to make the project even more valuable to people.
API workflow is a solved problem. Have you looked at zapier?
The thing is if you return the response of upstream service, it is jargon for me because I did not use the upstream's service directly.
Caching API calls might be a bad idea as it might create inconsistent data. Just saying, it is a hard problem in general. Abstractions are hard problem in general.
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?
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...
"No Code" is the new Fad word. It sounds a lot cooler than "you still need some config but may not need to write full code". VCs are funding No code like crazy.
Yes, I've seen them, We try to be different, keep improving and adding more features to make the product even more valuable to people. Thanks, I appreciate your taking the time to write.
Sorry, We didn't make it clear on the website. In short, We build and generate REST APIfor you, so you can focus on building on the frontend side. Thanks, I appreciate your taking the time to write.
I think the moat is to create huge amount of integrations. But, I am still missing the point. Why would you not access the rest interface of the services directly and create a security loophole by adding your access tokens to 3rd party service.
The real question is ... how robust is this with handling perms and custom business logic ... just being able to CRUD is not a starting point anymore. That can be done through scaffolding.
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.
Pricing is done based on value added. You can't directly compare it to a bare VPS server because by itself that server isn't providing value because you have to actually set it up, maintain it, etc.
Got any more of these? I love historical comments like this, from HN especially. It is really interesting (and entertaining) to see an idea being dismissed as trivial, knowing that it ends up becoming the core of a multibillion dollar company.
I suppose in the case of HN, I could probably use hn.algolia.com to find submissions of startups we now know to be highly successful.
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.
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...
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.
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.
Sorry, We didn't make it clear on the website. In short, We build and generate REST API for you, so you can focus on building on the frontend side. Thanks, I appreciate your taking the time to write.
Sorry, we didn't make it clear on the website. We only build and generate the REST API, so you can only focus on the frontend side. Anyway, Thanks, I appreciate your taking the time to write.
All the services listed already has rest api. Why would I need your product. What is the value add? May be I am missing something.
For Rest api for databases - https://postgrest.org
Too expensive for things that is available for free. Also, what happens when we hit rate limit on the upstream service. Who is responsible for that?