Show HN: SlashApi – a web platform to build REST APIs without code(slashapi.com)
slashapi.com
Show HN: SlashApi – a web platform to build REST APIs without code
https://slashapi.com/
51 comments
Can I use a custom domain name?
Nice stuff, Quick question around the product.
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?
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?
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.
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.
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.
Reminds me of https://nocodeapi.com/
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.
Agreed. They need a lot of integrations but other than that it's a solid product specially for not tech savvy startups
Could you elaborate what do you mean by - "it's a solid product specially for not tech savvy startups"
If team is writing stuff to use REST, then the team is tech savvy.
If team is writing stuff to use REST, then the team is tech savvy.
Yes it quite similar.
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.
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.
Wasn't questioning the amount, only the units for a plan which could make it more appealing
I know it might sound not so logical for you, but it's not how pricing works.
Wasn't questioning the amount, only the units for a plan which could make it more appealing
I don't think this is a fair equivalence... But nonetheless I'm grateful you linked that! That's fascinating to read in hindsight.
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.
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.
This was the first time I really read BrandonM response (very polite). So thanks for posting it.
Thank you for your suggestion. We will think about it.
Yo dawg, I heard you like APIs, so I put an API in front of an API..
Unfortunately I have to register to even get a feeling of what this will do.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
What is the difference between no code api and your service?
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
That's... Not great?
https://slashapi.com/docs/pgsql#content-api-endpoints
[deleted]
I looked at the documentation... Does this actually do anything on its own, or is it just a proxy for other services?
My 2 cents: add some social login to help user to create their account (e.g. Github or Google)
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.