Deployd: Create RESTful JSON APIs using a GUI interface(deployd.com)
deployd.com
Deployd: Create RESTful JSON APIs using a GUI interface
http://deployd.com/
15 comments
When I see products like this I always feel like I need a "hacker summary" of them. After some digging around it looks like Deployd is a Node.js/JavaScript application server - you download it and run it, it has a self-contained web server with a default interface, a set of command line tools for managing it and ships with a NoSQL-style data store (in bundles MongoDB). Have I missed anything?
I had a similar problem before putting it in JavaScript Weekly (which led to this HN submission). Being rather busy, I asked them to resummarize it for me before I realized they had a screencast I could watch instead.. which did a much better job for me than the text on site :-)
Absolutely. They have obscured this simple fact in unnecessary details. Also the phrases like "You dont need boilerplate code anymore" are highly misleading.
The title here is wrong, I believe. The APIs produced by this tool are not REST APIs. It doesn't seem possible to be able to satisfy the HATEOAS constraint, and a few other REST conditions are not satisfied. See: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
I would love to look at the docs and tutorials but I keep getting:
An error has occurred: {"code":"ENOTFOUND","errno":"ENOTFOUND","syscall":"getaddrinfo"}
Either way, this looks like an awesome product and I can't wait to learn more.
An error has occurred: {"code":"ENOTFOUND","errno":"ENOTFOUND","syscall":"getaddrinfo"}
Either way, this looks like an awesome product and I can't wait to learn more.
Hit f5 when that happens. I get it to come up eventually.
This looks pretty interesting.
A small thing: For cancelled DELETE requests like shown in the video, it would be better to return 403 Forbidden [1] instead of 400 Bad Request [2]:
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10...
A small thing: For cancelled DELETE requests like shown in the video, it would be better to return 403 Forbidden [1] instead of 400 Bad Request [2]:
10.4.1 400 Bad Request
The request could not be understood by the server due to malformed syntax.
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10...
That's actually possible, 400 is just the default code:
cancel("You're not allowed to do that", 403);
I'm not sure why we didn't show that in the video.
Edit: Unless you're saying that 403 should be the default code?
Edit: Unless you're saying that 403 should be the default code?
Sounds like 400 is the right code for cancelling a request in general.
The way you have it setup is fine in my opinion. Maybe add some sugar like: `needsAuth()` which would check for a user and would return `cancel("You're not allowed to do that", 403)` given the user does not exist.
I don't think that's necessary though. I like how it is right now.
Great work.
The way you have it setup is fine in my opinion. Maybe add some sugar like: `needsAuth()` which would check for a user and would return `cancel("You're not allowed to do that", 403)` given the user does not exist.
I don't think that's necessary though. I like how it is right now.
Great work.
An error has occurred: {"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"}
mine is:
An error has occurred: {"code":"ENOTFOUND","errno":"ENOTFOUND","syscall":"getaddrinfo"}
Try Google cache for now: http://webcache.googleusercontent.com/search?q=cache:http://...
The site's up now.
Are you running your website with deployd? Because it's down :)
An error has occurred: {"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"}
An error has occurred: {"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"}
I'm getting -
An error has occurred: {"code":"ENOTFOUND","errno":"ENOTFOUND","syscall":"getaddrinfo"}
An error has occurred: {"code":"ENOTFOUND","errno":"ENOTFOUND","syscall":"getaddrinfo"}
Having played around with Parse and StackMob, I agree with fellows HNers that the great importance of Deployd is that it is an open source BaaS. I loved the interface and the custom server side code validation, just like the feature that Parse recently launched. Keep it up!
It looks like their server is melting. Their demo video is here: http://www.youtube.com/watch?v=I_Jq1BVj6D0&feature=playe....
I feel like you played techphrase roulette to come up with this idea.
Where's the hypermedia?
I like it. But it would be nice to have the option to deploy on my own server.
We made it open source so anyone can run it anywhere. We and others have deployed it to EC2, Heroku, Joyent, Azure, Koding, and I'm sure some others.
When you guys have time do you think you could have install instructions for my own env. Or are the instructions for installing from source at the bottom all I need?
If you're on Mac or Windows, it's easiest to use the installer. Otherwise (or if you just want to do it yourself), the "install from source" instructions are enough; you'll need both node.js and MongoDB in your PATH.
yeah, me too :)
You can, it's open source. The environment just needs to support Node and Mongo.
> The environment just needs to support Node and Mongo.
Shouldn't this be displayed on the homepage somewhere?
Shouldn't this be displayed on the homepage somewhere?
We're working on updated content for the site, and details about the underlying stack and requirements for self-hosting will be more prominent.
This is one of my biggest issues with a lot of the projects being posted lately - they look great but I don't know the tech stack until I finally look at the code. Would be great if people at least mention if their project requires node.js, ruby or what not on their homepage.
(I work at Deployd) From our perspective, one of our ultimate goals is to create a platform where the tech stack doesn't matter to the user. We've partially solved this with the Mac/Windows installer - it installs Node.js and MongoDB dependencies itself. That way, you don't need to know the stack unless you're developing extensions (which are node modules).
However, I do agree that we need to document the stack better for those that want to install from source, or host it themselves.
However, I do agree that we need to document the stack better for those that want to install from source, or host it themselves.
GUI Interface. You're kidding right?
http://www.youtube.com/watch?v=hkDD03yeLnU
http://www.youtube.com/watch?v=hkDD03yeLnU
hahah classic
"By removing the complexity of backend development, Deployd lets you focus on the part of your app that really matters: the front-end"
/sigh.
/sigh.
Why the /sigh?
Is it because you don't agree that backend development is complex? Or do you feel differently about the front-end being the part that really matters?
Personally, I'm impressed by this. It seems to me a compromise between MeteorJS/FireDB and "traditional" stacks. It also comes with its own environment to organize my code? Something about that is a little appealing. Maybe limiting too, but appealing.
Is it because you don't agree that backend development is complex? Or do you feel differently about the front-end being the part that really matters?
Personally, I'm impressed by this. It seems to me a compromise between MeteorJS/FireDB and "traditional" stacks. It also comes with its own environment to organize my code? Something about that is a little appealing. Maybe limiting too, but appealing.
Probably the /sigh because it looks like a great framework if the problem you're trying to solve is to build the simplest possible TODO-list app.
What do you have against TODO-lists? IMHO the world needs more varieties of task management tools.
Actually, the example apps don't really do the platform justice. We (at deployd) use it in consulting projects for building big APIs with complex roles and business requirements. The design of deployd is driven more from lessons learned designing those APIs than from our experiments in TODO-lists.
Actually, the example apps don't really do the platform justice. We (at deployd) use it in consulting projects for building big APIs with complex roles and business requirements. The design of deployd is driven more from lessons learned designing those APIs than from our experiments in TODO-lists.
This looks like it could be pretty good for prototyping, or maybe a small, low-risk project. It gives the user JS event handlers for server-side events, and there's a simple API for behavior ("protect('model_attr')", "error('the message')"). Not bad.
(I work at deployd) Yes, it's perfect for prototyping. We use it extensively for prototyping on projects where the ultimate API has to be supported in another stack. Saves tons of time compared to developing the API as you go in Java or the like.
Great Work.
suggestion: I would frame it differently - the coolness of what you are doing has nothing to do with the GUI part, but rather, the fact that it is a BaaS (backend as a service) open source. It's a simplified meteor, or an open source parse.
BTW - it is funny how things circle back - we are coming back to a client-server era. Much like the VB6 days :)
suggestion: I would frame it differently - the coolness of what you are doing has nothing to do with the GUI part, but rather, the fact that it is a BaaS (backend as a service) open source. It's a simplified meteor, or an open source parse.
BTW - it is funny how things circle back - we are coming back to a client-server era. Much like the VB6 days :)
(I work at deployd) Yes, the cycle is funny. We don't usually focus on the GUI when talking about deployd; someone outside the company posted with this headline.
Open source was a no-brainer for us. There are some other key concepts that make it a compelling tool, particularly how easily extensible the platform is.
Open source was a no-brainer for us. There are some other key concepts that make it a compelling tool, particularly how easily extensible the platform is.
Jeff, has deployd considered adopting a JSON-based media type like Collection+JSON or HAL or JSON-LD (and there are others, or you could roll your own) so that the JSON APIs are properly RESTful?
(I work at Deployd) Our goal is first and foremost to generate useful APIs that you can use in your front-end, not necessarily to strictly adhere to the REST pattern. We do tend to use REST terminology when describing Deployd, and maybe that's a mistake that's causing more distraction than necessary.
Funny you mentioned VB6 days, that was the first thing that came up at work when we saw it.
I haven't downloaded it yet, so perhaps I'm missing something. But our thought was that it mimicked the VB6 "Place Code Here" mentality.
I haven't downloaded it yet, so perhaps I'm missing something. But our thought was that it mimicked the VB6 "Place Code Here" mentality.
I am saying VB6 days, because in essence deployd (or meteor, or parse) are the same as an old-school DBMS database with stored procedures, and HTML+JS is in essence the same as a Win VB6 app.