There's several showstoppers for me. If you figure out how to fix them, you'll have my business:
1). Server side validation. If I can't prevent a CSRF attack, it can't be the basis of my app/website.
2). SEO. Figure out a way to serve deep links using the root index.html transparently in a way that is undetectable to the client side (search engines)
3). Build in require.js or leverage some other technology to make backbone app codebases manageable yet compressed and performant in the production environment.
If you can solve 2 and 3, you solve one of the biggest issues I have when writing backbone apps -- I'm often writing my code twice, often in two separate languages, which isn't DRY and feels like a waste of the efficiencies gained by backbone.
If you figure this out, Backbone isn't just for web apps anymore -- it's for any website.
Nice initiative. I am not a big fan of writing in Javascript but it certainly is a big plus to have such a nice library like backbone.js.
Just a tiny point ... About the drawing of the triceratops, he has very mmmmm.... "developed" crotch area. Once you've seen it it's hard to not think about it every time. It's just a little detail but it's a little bit weird!
I think I've eaten some stupid soup today. Could someone explain to me what the backend is all about? As far as I see it, the command line creates a backbone template and syncs it with the server. Which is dandy, but as it's client code anyway, that's mostly static web hosting.
So now I'm ready to create a hyper-nifty Web 2.71 interface to WHOIS. So normally I'd create a simple web app that serves me my data. Where does backlift come in here, as I'm not doing CRUD all from within the app itself?
Whenever you persist data to a backend, say by calling save() on a model, it seems Backlift will handle the backend for you, that is, it gives you a server to process the PUT request and a place to store the data. Then to retrieve the data on the front end, you just do a fetch().
So now you just do save() and fetch() and you never worry about what happens in between.
1) By default, Backlift generates the index.html file based on a few configurable parameters. We think this will work in many cases since the index file for a backbone.js site can simply provide a container for your html templates.
2) Not currently.
3) If you're starting a new app and you need a starting point you can do so by downloading a template. You can alternatively run "backlift init" with an existing project.
4) Not yet. We're thinking of creating a github project where devs can upload their own templates or tweak ours. Pulled templates will become available from the CLI. We don't have a specific timeline for this yet.
I'm really happy to see more tools coming out to take some of the effort out of setting up / deploying your development environment. It's refreshing to get more time to actually code rather than administrate systems.
This looks pretty useful today, and I assume will continue to evolve and add more functionality in time. I have very little clue about frontend apps, so I will use something like this to offload a lot of the tool selection process so I can focus on the app itself. I imagine a lot of developers (especially those not on hn) are the same way.
Using bare PyMongo, asyncmongo, or some ORM-like solution?
Coincidentally, I'm also working on my own app using Tornado and Backbone and considering the switch to Mongo (currently using the base MySQLdb wrapper included with Tornado) - curious as to how you've found working with whatever Mongo solution you're using.
Edit: Initially forgot to include asyncmongo in that list.
This seems like a show stopper to me. The inability to have server side validation means there's no way to control access to things, meaning you have to fall back to security through obscurity.
What would be really cool is if instead of a python backend, this had a node backend that used the client side validation mechanism server side to allow server-side validation without needing to duplicate the code. This could theoretically be done transparently if all the classes were named by convention.
Dependent on the language I would think you could add annotation style based validations to the client side code that would be automatically picked up by the deployment system and hence applied to the server side logic. That said I don't (at least to my knowledge) believe that is possible with javascript without modifying the actual client code to fit an api.
Seems pretty awesome if you have actually taken care of all of the backbone sync backend, so you can just use all of the collection create, update, findAll and everything and it just reads from or updates the database?
How do you handle a situation with relationships where you need to specify "give me all of the objects from collection X where parentId is YYYYY"?
Also how do you handle sort of arbitrary queries?
I was thinking about making a service like this because everyone wants to use Backbone.js.
Just wondering how data validation works for this type of model? If you can't rely on the front end how can you reliably tell the back end what to expect?
seems like this is definitely something that's most useful as an app prototyping tool rather than a deployment environment. and if its a prototyping tool, i'd want it to run locally so i wouldn't have to deal with remote admin / debug
so it should probably just be open on github.
just throw express or restify in front of mongodb with some minimal scaffolding and generators. if i get a minute i'll try to get something like that up
I think it's supposed to be a shift from backend/frontend to frontend only, in the same way that Heroku was a shift from building your own infrastructure to just building a backend/frontend. By reducing the surface area, you can reduce the required tools and platform knowledge and reduce the development friction, in theory.
There are plenty of unanswered questions, but I can totally foresee this sort of thing as a viable development platform for some projects in the future.
we have / do it when it makes sense (heavy client). Either way we require much more infrastructure for "real" apps than some black-box backend, zmq clusters for computation etc.. I guess this might be an ok playground for some trivial apps
There's several showstoppers for me. If you figure out how to fix them, you'll have my business:
1). Server side validation. If I can't prevent a CSRF attack, it can't be the basis of my app/website.
2). SEO. Figure out a way to serve deep links using the root index.html transparently in a way that is undetectable to the client side (search engines)
3). Build in require.js or leverage some other technology to make backbone app codebases manageable yet compressed and performant in the production environment.
If you can solve 2 and 3, you solve one of the biggest issues I have when writing backbone apps -- I'm often writing my code twice, often in two separate languages, which isn't DRY and feels like a waste of the efficiencies gained by backbone.
If you figure this out, Backbone isn't just for web apps anymore -- it's for any website.