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.
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.
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.
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.
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.
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.
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...
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.
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.
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?
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.
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.
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!
/sigh.