I'm currently working on web development side project. I have been trying to figure out all the pieces for the last couple of months and have made good progress.
I'm using bootstrap and Backbone on the front end and this is what I have been focusing on lately. This part works well with all the Backbone views being rendered fine.
For the backend I will use Nodejs along with express. I have started looking into it this past week. Currently, I'm trying to serve requests sent to the server with through express.
How can I handle the request and send back a Backbone view that already has a defined HTML page and everything.
I came across Jade which is used with express a lot but I can't get it to work with my backbone views. Also, how does underscore come into the picture. Do I have to choose between underscore and Jade?
I will of course further down the line have data pulled from a database and sent to the backbone views.
Thank you for any input.
Underscore (_.template method) and Jade both can, from a template file, render html code which will be sent by express to the client. Since underscore is not express friendly my guess is that you are confusing the client libraries (Used by backbone on the browser) and the server libraries user by nodeJS to answer request calls, if you are rendering templates using underscore with backbone that is done client side and has nothing to do with express.
This article should help you set everything up: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ and it has source code for you to look at.
Since my guess is you want something functional fast, I would suggest something like sails.js which can save you a lot of time configuring express and making it work. Plus sails.js its built on top of express. https://github.com/balderdashy/sails/
Related
I've built a REST API backend using Django and am now at the stage of designing a client facing frontend. Though, I can't seem to understand how this client frontend should be structured and which languages it should use.
PHP is server-side, and is usually used as the language for building backends. When coupled with a framework such as Codeigniter, it can also be used to play around with sessions, route URLs, and decide which templates to use. Though, I don't believe it can be used to call my REST API to fetch resources (might be wrong here, correct me please if I am).
Javascript is client facing but is used only once the webpage has been fetched from the server. AngularJS is great, but from what I've read, it seems it only helps add very dynamic functionality into already rendered static pages.
I am really open to any ideas, suggestions, and advice based on your experiences creating client frontends. So, back to my original question, how does one structure a REST client frontend, which language is best for this goal, and if which frameworks should one consider to use?
Update 1
Someone asked whether this client frontend will be run in a browser -- the answer is yes, it will. I am trying to build a Twitter-like web client frontend that interacts with a Twitter-like REST API backend. Basically, everything you see there when you go on Twitter's website.
Since it is a browser frontend I would go with HTML/JavaScript only. No need to use PHP or any server side language IMHO. This has the advantage of being extremely portable.
I would also use a JS framework for that purpose ( the trend nowadays seems to be angular).
REST really, really isn't new. It's been a part of HTTP at least as far back as HTTP 1.1
Have a look at this question: Backbone.js frontend with RESTful Rails backend? the top answer lists 20 possible frameworks for building a front end.
Thanks for your help, everyone. Found exactly what I was looking for here:
http://docs.python-requests.org/en/latest/
A nice little library for Python that allows me to basically make calls to a REST backend from within a Django application, which serves as my frontend.
AngularJS will also be used for to make the static pages that Django returns more dynamic. Why? Because AngularJS by itself can be the complete solution only if your whole site consists of one page. If you have multiple pages where each one has it's own set of dynamic elements, you need a combination of Django and AngularJS.
Apparently REST is still quite new and it seems there aren't many people that have stumbled upon this very fundamental question like I have.
Once again, thanks!
I need to build a single-page JavaScript web app that, on regular intervals, pulls data from a couple of public and maybe a few private APIs, and present & refresh the data in different tables. I could build it purely as front-end code with jQuery and just use AJAX calls, but to keep the keys and everything for the APIs private, I need the logic that retrieves the API data to live in backend code (on the same server).
I'm new to building this kind of application, and wondering how to achieve this with NodeJS. After searching and looking at some tutorials, the only way I can wrap my head around it so far is to have an index.html that displays the view with the empty tables, then on a setInterval, have a local JavaScript function do an AJAX call to a NodeJS (Express) route that handles all the API stuff and returns a JSON object in the response. On success, the local JavaScript can write the results to the html for the various tables/divs.
That sounds OK to me, but since all of this will have to live on the same server, it seems really weird to have a front-end script do manual calls to that same server via a URL/route.
What am I conceptually missing? Do I need to employ a master Express layout and use partials for the divs/tables and have the Node backend process the front-end that way? Or should I stick to building .html and .js outside of Express and maybe use something like Angular to create a more intuitive front-end piece? I'm not sure how either of these scenarios would be put together, I'm just feeling around for a better approach.
Posting as Community Wiki answer, as this got answered in comments:
The way I would approach this is with an Angular app. Exactly as you state you would have an API that is built on nodeJS (a bunch of defined routes that grab data and return JSON), and then your front-end angular app. Correct, every set interval your app would call the endpoints you defined in your API, and then update $scope variables based on the JSON response. Your HTML would actually be updated in real time automatically (since that's how angular works with binding models and templates/partials). I would look into angular - sounds like a perfect solution!
Also, once you understand how the binding of angular works, you will never want to write jQuery html() append() or any of those DOM manipulation functions again.
Ive been using MVC frameworks for a while now, and have been through Cake, Codeignitor and have now settled on Laravel (thanks to Jeffrey Way over at nettuts). I heard great things about Backbone so I did some of the tutorials and really liked it.
I have a few questions, I hope someone can answer
In quite a few bb tutorials the controllers are always restful, can bb only work with restful controllers?
I'm really stuck in the paradigm of controller -> view. Now with backbone from what I've gathered doesn't use views at all but templates. Is it possible to still serve a view as normal and then client side create a collection from the rendered view? That way I'm still using a mvc backend as normal but also integrating backbone to keep track of my data on the frontend. if this is possible, is is bad form?
In quite a few bb tutorials the controllers are always restful, can bb only work with restful controllers?
Backbone includes default code to work easily with restful servers. However, that functionality is easily overridable to work with various servers or back ends. There are adapters for localStorage, for example. So if your server is non-rest, you can still work with it, but you'll have to write some code to adapt accordingly.
Backbone Views are sort of hybrid views/controllers and templates handle the actual HTML. Generally, if you want to bootstrap a collection in the browser, you need to make the data available as JSON. Rendering HTML on the server and then trying to extract data from that and hydrate a collection is jumping through extra, awkward hoops that people usually try to avoid. What you can do is include your JSON data inside a <script> tag and have it parsed into javascript objects and used with backbone in the browser.
AngularJS uses two-way client side data binding (from AngularJS Developers guide):
Has anyone consider using mix of server side templating engine with AngularJS two-way client side data binding. Something like this:
I am thinking about using AngularJS just for parts(components) of the page? Would it be good idea?
I would like to hear if you already had experiences with similar approach and what were drawbacks and advantages...
Angular is a complete UI rendering client framework. You can feed data into it, and it will render the proper html. On it's own Angular is a templating solution completely de-coupled from any server.
What you're attempting to do, is re-couple your Angular application to your server. It will be more work, there will be very few benefits, and you'll lose your ability to switch server technologies but keep your angular application untouched.
In essence, you don't want to do this for the same reason you wouldn't want to have your server rendering JavaScript for you... it's just less obvious because of all of the years we've been rendering all of our HTML at the server.
The end result is what's important. That the UI works properly and the application is easy to maintain. If you find your solution to be easier to maintain, then you should do it. I have a hard time imagining much being easier to maintain than straight HTML and JavaScript with a server that does nothing but host JSON.
I had the same dilemma as you have, I come from a background of using SMARTY as a server side template engine and we recently started using AngularJS.
I think mixing both solution would be appropriate in the the essence of total separation. i.e don't mix part of your page with both technologies but use both technologies separately.
For instance if you have a listing page where users will not interact with it at all, you may use server side template perfectly.
But if a page involve lots of manipulation and user side interaction in this case Angular is what you should use.
If you are using SPA (single page application) don't use server side template at all.
In a cordova app we recently made, we used a kind of a mix. Fix content like forms, lists, headers and menues we did in the angular way, some parts like content from an RTE or often changing templates we added with the directive ngBindHtml. The idea behind is to be flexible in the content pages of the app if the client want to change layout or want to put currently unknown content to it.
But i would suggest: if you can easy maintain the app (no long deployment/approval process) you should do it the angular way (but with no SEO in mind;).
I want to develop a relatively simple application that calculates some value based on several inputs. I dont want a backend, all the calculation can be done in the browser.
Im a little new to JavaScript and WebApps and I came across Backbone.js.
I really like the MVC design, however, they mention a backend a lot. My question:
Is a backend server absolutely required?
Is a backend server optional but without one there isn't much point in backbone.
Or will backbone will really help me out?
Backend is not required.
Backbone can fully work without any backend if your application doesn't require one.
That depends on your application. If you want to retrieve value of some inputs and calculate a result then Backbone won't do that for you - it will help you structure your code. If you app is simple and don't need support for models, views and collections or routing, then there is no point in using Backbone. Hard to answer this question.
For example: Classic todo example application doesn't use any backend.
Backbone.js implements fetch(), save(), destroy() etc. methods on models automatically performing appropriate AJAX requests and parsing response. So it has a strong support for backend via REST services, but it is optional.
You can still use models, views, routers and events without any server-side code. Just don't call REST methods (or override them at your wish).
You can use localStorage for persistence (you'd have to implement this yourself or find it on the web, like here) but if you don't even need that then you don't need to use any of the persistence methods in backbone.
Backbone is meant to help you structure a medium-large sized application (js-wise), so it doesn't become unmaintainable jQuery spaghetti. With short applications (js-wise) it's really an overkill unless you are trying to learn how backbone works.
Note with js-wise I mean the client side code, if you had a huge backend but the only js would be something that focuses some form, it would not even count as a short application (js-wise).
You can use backbone.js without a backend. However you obviously won't be able to store or retrieve data. Backbone may still be useful for keeping your code organized, however it really shines when you want to separate presentation logic from logic that manipulates your data, which is a goal of the MVC pattern. Generally your data will be stored on and retrieved from a backend.
If you want to play around with data persistence, try out backlift.com. [disclosure, I work on backlift.com] We've tried to make it easy to get a backbone app up-and-running without having to setup a server or deal with compiling templates.