recently i had a chance to watch beautiful course from john papa on building single page application. i' d love it. it touches every aspect of application both server and client side.
i was more into client side. during his implementation mr.papa had similar structure in clientside. such as data services, mocking, data caching and offline features it was impressive. one of libraries that frequently was mentioned is amplify.js
since in his work mr.papa has referred to knockout, as someone who has started digging and working in backbone.js. want to find out does similar structure would be applicable for backbone. or more precisely could backbone also benefited from amplify.js or it s already built in underhood of backbone.async method?
ref:jonhpapa.net
could backbone also benefited from amplify.js
Yes, but you'd have to override Backbone.Sync in order to use the client-side persistence provided by the Amplify.js Store API.
Backbone.amplify looks promising, but I haven't tested it yet.
Related
I was a little startled to learn that Nancy has its own razor implementation, that may or may not behave like razor. In practice, does this cause issues? What are "most people" using for a Nancy view engine? Why was the real razor not used?
First the easy answer. The Razor engine is, by far, the most downloaded view engine available for Nancy https://www.nuget.org/packages?q=nancy.viewengines
Now for the more complicated questions
Why was the real razor not used?
Because the "real" (and by real I'm going to assume that you mean the one used by the ASP.NET stack) Razor engine is tied to the HTTP abstractions that are built into the ASP.NET stack (HttpContext and all its friends) so there is no straight forward way to use it with Nancy.
The slightly longer answer for this is that you have to understand that Razor is really a parser and a Razor view engine is what sits in the middle of the consumer and the parser.
Nancy uses the Razor parser but we have to have our own view engine because that's what enabled Nancy to parse and execute Razor templates.
Now, it does get even more complicated. Many of the features you see in the ASP.NET Razor view engines, such as master pages, partials, various helpers, _ViewStart and so on, are not Razor (the parser) features, but they are an additional feature set that have been built into the view engine (you can almost think of it as middleware).
This means that for our engine we've had to re-implement much of these features because that's what's come to be expected from a Razor view engine.
I would like to point out that, if it was possible, then we would love to ditch our own implementation and use the one built by Microsoft (less code for us to maintain and it would mean we'd support 100% the same feature set), but unfortunately that's not our decision to make.. we can't take a dependency on their abstractions I am afraid
Hope this clears things up
/A
We have been using the Razor implementation from Nancy for a while now. We have run into a couple of issues that are making us either switch to SSVE or abandon Nancy (we do really love Nancy).
The first issue with Razor is you cannot precompile views like you can in MVC which leads to much longer startup times. We have had many complaints about this.
The second issue is there seems to be a long-standing bug in the Razor implementation with Nancy which causes a situation that is only resolved by recycling the application pool. I'm not an expert but it seems when the project is loaded there is a temporary DLL being compiled and generated at that time (this explains the slower load times) but sometimes there a problem which leaves to the instance not being able to be created. It seems to be at this location: https://github.com/NancyFx/Nancy/blob/master/src/Nancy.ViewEngines.Razor/RazorViewEngine.cs#L238. Basically "viewAssembly.GetType("RazorOutput.RazorView")" is NULL at various times which causes only an error message to be displayed on every page, for every user, at all times and the only way to fix it is to reload the application (recycle the application pool)
Just my two cents and I know this post is older but maybe others will see some of the problems we have run into. I've opened a GitHub issue but the bug is hard to reproduce for us and it hasn't gone anywhere.
Background
I am building an Angularjs app and have added express and mongodb to the app already but when looking for some other back-end tools I came across firebase.
I'm just a little confused as to how it all fits together and would appreciate some experienced users input on it.
Question
Does firebase replace the need for mongodb and parts of express or does it work in tandem with them?
If they don't work together why should I use one over the other?
MEAN stands for Mongo, Express, Angular, & Node.
If you use Firebase, you would basically be replacing the MongoDB part of the MEAN stack with Firebase. You would still rely on Node / Express to be your server framework, and Angular to be your client framework. Firebase would then serve as your data source as opposed to MongoDB.
The initial configuration would be different. So if you started with some sort of generator ( such as Yeoman or a MEAN boilerplate ), you would probably need to go in and remove any references to MongoDB & Mongoose.
To answer the question, "Why use one over the other", it is really up to you. They are both good solutions.
Firebase seems to be better for real-time data, and in my experience is easier / faster to prototype with than Mongo. If you get into some heavy usage with Firebase, you will have to start paying for it.
MongoDB may have more documentation when it comes to using it with the MEAN stack.
We are developing a WCF REST service which will be consumed by a desktop WPF application and will also be a source of data for the ASP MVC4 website.
So far I've run into countless technical issues and most importantly I am worried about the future of the Microsoft.OData.EntityFrameworkProvider. (Please check blog comments here).
The issues include:
There is no easy way (without using DTO) to add properties on the service entities which will be passed through OData but won't be stored in the database Actually there is an easy way:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.ComplexType<CustomType>();
}
There is no easy way (without parsing XML or using DTO) to store properties on client entities without them being sent to the service (v5.6.0). The "hard" way is to hook into RequestPipeline and ResponsePipeline:
Configurations.ResponsePipeline.OnEntryEnded(OnReadingEntry);
Configurations.RequestPipeline.OnEntryEnding(OnWritingEntry);
using DTO is cumbersome to say at least, automapper helps with retrieving of IQueryable results but updating entities requires full implementation of IUpdateable, which actually works on DTO but is required to update entities so implementation of it is very tricky if even possible (I searched for existing solutions and these mostly cover in memory data source so I implemented a working solution but without links, I can dig it from source control if anybody is interested). Tested on v5.6.0.
Client entity containing dynamic field will crash when retrieved from a service (checked on 5.6.1)
accessing DbContext from EntityFrameworkDataServiceProvider requires a hack
This package has not been updated for almost half a year and this fact itself is very worrying.
My question is what Microsoft or open source alternatives to Microsoft.OData.EntityFrameworkProvider link between EF context and a client are suitable to replace this supposedly dead library? The critical requirement for such a link would be to have a tracking client-side context and entity framework 5 or 6 compatible service.
Is Microsoft.AspNet.WebApi.OData a good solution also for desktop applications?
Are there any other Microsoft or open source projects have similar capabilities?
For WCFDS update, you can refer to Future Direction of WCF DS service.
In the issues you listed, I am sure that issue 1 can be easily resolved in web api by tag [IgnoreDataMember], here.
For Issue 2 and 4, one suggestion is you can add a data layer in client, which can handle extra data model and dynamic field
Just a couple of thoughts...REST is not the same as OData...so your question is confusing. If you meant WCF Data Services, then definitely go with the new WebApi. As Maya's link shows, The WCF DS team announced they are basically done.
However, your client is usually agnostic of what technology you are using for odata and its data layer...its a disconnected architecture. So if you have a mapping impedence on the server side, that is one issue, but which client is consuming the odata ought to be irrelevant. But likely I did not understand your stated problem correctly...Do you mean that you own both the client and server and want to share the entity class definitions? If you are that tightly coupled, you can add service resources customized for the client, and others customized for your MVC app.
For some practical workaround, WCF DS offers query interceptors, that let you manipulate outgoing data. The new WebApi is basically works from controllers and gives you full control over intercepting the requests and manipulating what needs to be done with the data.
Finally, just a suggestion for your desktop client...Lightswitch works wonders with oData...point and click...it generates your proxy and client model on the fly and gives you huge control over the client and what it does with the responses from the server.
I'm evaluating Backbone.js for keeping data and UI synchronized in my web app. However, much of Backbone's value seems to lie in its use of RESTful interfaces. Though I may add server-side backup in the future, my primary use case involves storing all data offline using HTML5 local storage.
Is Backbone overkill for such a use case? If so, is there a better solution, focused solely on updating UI when data changes, and vice versa? (I'm also looking into Knockout and Javascript MVC.)
EDIT: I'm also now looking into Angular.js and jQuery Data Link.
Backbone.js works just as well with local storage as it does with RESTful queries.
I'm a learn-by-example kind of guy so here are some links to get you started:
Todos, a todo application
that uses local storage and
backbone.js, check out the annotated
source to see how it works.
The localStorage adapter is
all you need to get started, take a
look at the annotated source of
that too.
In the past weeks I have evaluated different solution for a scenario close to yours; being a project done in my personal free time and not being a good Javascript programmer, all I needed was something easy to learn to avoid starting from scratch.
Not surprisingly, I had the same candidate: Backbone.js, Javascript MVC and Knockout.js.
Backbone.js won:
I wasn't be required to follow conventions or replace what was already in place
I've easly hacked in its codebase to understand what wasn't clear from the documentation
I've successfully ignored a large amount of its features that was not interesting for me
It gave acceptable performance on busy pages
It works
Backbone.js is lightweight and relatively magic-free; you will probably use a small subset of its feature but it provieds a solid base to develop your solution.
I know it's been a while but you may want to check out backbone-offline project on github: https://github.com/Ask11/backbone.offline
You can also take a look at AFrameJS. I have created a bare-bones proof of concept note-taking app that works offline using HTML5 WebSQL spec, but also want to create an adapter that uses localStorage as well. My personal opinion (and I am biased) is that using an MVC library of any sorts is going to help you in the long run - the value of libraries such as Backbone, Knockout, and AFrame lie in their ability to reduce the cognitive load of the developer by enforcing a good separation of concerns. Data related functionality reside in models, displaying that data resides in Views, and the glue is kept in Controllers. Separating these three concepts might seem pedantic at first, but the end result is code that is easier to develop, easier to test, easier to maintain, and easier to reuse. A basic tutorial on using AFrameJS can be found on my site at: http://www.shanetomlinson.com/2011/aframejs-tutorial-for-noobs/
I am interested in knowing if there are any server-side web application frameworks which integrate nicely with CouchDB? Does anyone have any experience in doing this? It seems like a dynamic language would be well-suited for playing with the JSON, but I am more interested in hearing about how it would fit in with the framework and the application's design.
Two frameworks that I would suggest for CouchDB are Ruby on Rails and Django. Both have a small file you can include that allows for easy interaction with CouchDB. For Ruby/Rails, this gives you the ability to write code that looks like this (code snippets yanked from here):
# Create the database
server = Couch::Server.new("localhost", "5984")
server.put("/foo/", "")
# Insert a new document into the database
doc = <<-JSON
{"type":"comment","body":"First Post!"}
JSON
server.put("/foo/document_id", doc)
# Get the document back later
res = server.get("/foo/document_id")
json = res.body
puts json
Python/Django lets you do the same with a relatively minimal amount of work (see here). Both of these aren't at the web framework level but they require a minimal amount of work to set up and are pretty easy to get going in Rails and Django. The Django approach still requires some packages to be installed so if you just can't do that for some reason the Rails approach is the way to go.
Another good how-to on Python on Django can be found here (also lifted from the CouchDB FAQ).
The only web framework that dedicates itself to CouchDB is currently CouchDBKit for Python.
Check out the official wiki page that lists how to get started in your language:
http://wiki.apache.org/couchdb/Basics
Pick the language and framework that suits you best and then use one of the light CouchDB libraries with it.
It seems that things are move quite quickly at the moment for CouchDB. I'm sure there will be more frameworks out there soon with CouchDB support. I'm currently looking into building one for PHP.
I have had good success with jcouchdb for Java and CouchApp for JavaScript and CouchDBKit with Python. All of these are actively developed, open source and well designed and easy to enhance if they are missing something you really need. I have submitted patches and feature enhancements for jcouchdb and couchapp both.
Actually, you don't really need such a framework. Instead, you can just write the whole web application in CouchDB. It allows you to generate HTML files, or any other XML derived format, and you can even use HTML-templates. I consider this a good choice, because JavaScript is a rich and flexible language. On the other hand you don't have the overkill of a connection between the database and your web application.
For more details, check out: http://books.couchdb.org/relax/design-documents/shows
There's also a related question: Using CouchDB to serve HTML
Depending on what you want to build CouchApp may be something to look at: It's specially designed for writing apps with CouchDB:
https://github.com/jchris/couchapp/wiki/manual