Love this, sorry about the hate brigade from HN. Anecdotally, it seems to be getting worse lately...
To start, at Zapier, we and our customers have a huge need for something like this for any install of open source software with no API or crazy REST APIs. You should get in contact with us. Being the REST API for standard OS packages is something you should do yesterday. :-)
The credential thing is something we fight as well, but people in pain of a solution won't freak out too much, especially since they can just modify the access control to only expose the critical bits.
Maybe the comments have changed since you wrote this but I see very little hate amongst the comments - only 1 could be deemed uncivil to my eyes.
[and I know I'm guilty of this at this precise moment but not sure if leading with a meta-comment is especially constructive in itself. If you don't like the tone, then lead by example]
Wait, tell me again why I should trust you with database credentials? Whitelist you in my infrastructure? Allow you to define an entry point to my app?
I would honestly rather pay for a product like this and get the source than what is in this offering.
We totally understand the hesitation there. We're launching with the hosted direct-connection form, but we have tons of plans to specifically address this concern.
First, we're actively working on a database agent (like chart.io using reverse-SSH tunneling) for increased security and control.
Second, we have longer term plans to offer this platform as an appliance, so everything stays within your infrastructure. That's obviously a much larger project.
In the mean time, we have the advantage of being able to make constant improvements to your API while being hosted.
1. Expose your data through an API without writing much (any ?) code.
2. Time saving.
3. Since the API itself is fed by the framework, the opportunity for bugs is limited.
4. I can think of some people / businesses that would pay for this service.
Cons
1. I cant quite get why a service like this would limit its requests / month [1]. My take on it was that you are selling the transformation of the data into a service - as a service. I guess the calls / month is to also benefit from the value that your service adds to the data ? Number of calls made might not directly translate to value.
2. You are limited to relational models.
3. There are tricky conditional requests / data munging / orchestration etc that REST services are expected to take care of sometimes. It can quickly become messy if a client wants this. Is there a translation / conversion layer that can be inserted between the API and its caller ?
Some feedback...
1. Is there some way a developer can try this out before pitching it to a product manager or a higher-up ? There seems to be no direct way to do that. All plans under pricing are tied to money so some folks might be averse to signing up. Most devs just want to download and hack something out to show someone what a product is capable of. The dev can be your marketer within a company.
2. The layout of your site is neat. The call to actions are very specific and targeted.
3. I think your product has the potential to be awesome. Good luck.
I hate seeing logos from publications apparently praising/reviewing a product (if you could call TechCrunch a publication) without a link to their article. It just seems fishy to me... It's a "Show HN" and a new product, so I'm sure it wasn't intentional - But just wanted to let you know that I personally close such tabs immediately (unless I've heard about the product from someone else, and it wasn't just a random Google search result) :)
This looks like a pretty neat web app. Nice UI and promo video, also. I think the core audience for this, is people who are somehow locked in using MySQL, though. For someone starting out, it seems like a bad idea to use this because it is sort of encouraging bad habits, right?
For example if you making a new sandwich, why would you make a device that takes the peanut butter from the jar, puts it in a bigger jar, then you use a knife to get the peanut butter from the bigger jar to put on your PB&J? It just seems like a bad middle man, if you are starting a new project.
Maybe I'm wrong, but again, it looks neat for people maybe in old companies where they have no choice but I just hope this doesn't encourage people to start with MySQL just for this app or with a purpose to only turn it into an API.
Or maybe another application of this is turning an existing blog with WordPress (MySQL) into an API? Not sure...
We definitely built the product with existing applications (without an API) in mind. We found it much more difficult to add an API after-the-fact than if you design for one in the beginning. In fact, the idea came to us after attempting to build an API for a 10 year old PHP application at Rackspace.
Nice piece of software, I used the trial for a bit and was able to get an API up faster than I could program out one myself. As a consultant I have a few clients with rather bad old websites who could use something like this for new mobile apps they are wanting to develop. This makes it a bit easier to scale out to that.
For a n00b like me this looks interesting. Wouldn't mind taking a test drive to see if it's something that could work long term. I agree with @josegonzalez. Seems like a leap of faith and you lose a bit of control. However, if in the long run it's a stable environment and everything works as promised could be a solid solution.
I'm most excited about the idea of automatic Client Bindings. I've been thinking about how cool it would be if you could dynamically generate a Ruby gem for your REST API, as well as a documentation site.
There's already grape (https://github.com/intridea/grape) and grape_doc, so it looks like 'grape_client' is the only missing piece. Imagine being able to automatically generate versioned client libraries for ruby, php, iOS, android, etc.
Would be super awesome if emergentone could get behind an open source project like that.
1. There is a real benefit to building an API into the core of your app - it forces the kind of loose coupling that will improve your entire architecture.
2. Your db schema != your business logic. The API should mirror the latter and not the former.
Having said that... Automatic language bindings? I want some of that...
This should serve as a loosely coupled, managed API server which acts as a load balancer to a larger extent, if it can intelligently cache requests and act like memcached for API requests.
Worth mentioning, this can be a big time saver to generate APIs for legacy type websites, small new frameworks and languages that don't provide native framework level support to build API's.
> This should serve as a loosely coupled, managed API server which acts as a load balancer to a larger extent, if it can intelligently cache requests and act like memcached for API requests.
Maybe you should re-title this "Generate REST APIs for Existing Databases". IMO, database != application. I opened this in anticipation of something that would generate REST APIs for legacy (ws, corba, rmi, etc) interfaces.
Another one!? How hard is it to write a few lines of Sinatra, Express, Flask ... code, then deploy with Heroku? This is getting ridicilous. Are programmers becoming so dumb they can't create an API on their own?
Enterprise applications are usually so deep and far away from the database that building an API by hand, per se, would be nearly impossible. This product is targeted at those companies, not small, agile ones.
As someone who works on a deep and far away application I would have a hard to seeing how connecting to our datasource (which has been abstracted to hell by ORM layers) would be a better option for developing a rest interface than using existing infrastructure. That being said, I like the path they are taking and think it's a valid approach... just not sure how many people actually need it.
Building an API by hand is only impossible if literally no one in the organization understands their data. If that is the case, an API is the least of their concerns.
my 2c: As a developer I wanted a one line explanation of what the technological solution is. "Generate a new API for your existing application!" is far too vague. It doesn't tell me any of the most important things I need to know about the product.
the Product page has the stuff on it that I wanted to read. IMO that should be a primary link from the front or part of that content should be on the front. at the moment its all "BUY NOW" and yet I have no idea what it is unless I watch the video. so that causes buyer suspicion.
To start, at Zapier, we and our customers have a huge need for something like this for any install of open source software with no API or crazy REST APIs. You should get in contact with us. Being the REST API for standard OS packages is something you should do yesterday. :-)
The credential thing is something we fight as well, but people in pain of a solution won't freak out too much, especially since they can just modify the access control to only expose the critical bits.
All-in-all, big fan. I like it.