Show HN: SlashApi – a web platform to build REST APIs without code
slashapi.com
slashapi.com
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?
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.
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.
That's... Not great?
If team is writing stuff to use REST, then the team is tech savvy.
You got yourself a microservice architecture.
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 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.
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.
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...
Stuff like this is where a lot of no-code stuff falls down.
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.
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.
Also a bit ironic to see curl commands in the first 10 pages I clicked in the documentation whilst the whole product is claiming no code is required.