I am looking for a end to end example for Breezejs library with .NET WebAPI but without using either oData or Breeze.NET (Breeze's server side component).
I have tried looking at the sample code but it doesnt seems to give an example which does that.
http://breeze.github.io/doc-samples/
All the server side samples either have oData or breeze.NET dependency.
From what I understand it is possible to use breeze.js purely in client side (and have your own server side webapi (restful)).
"BreezeJS really is a pure JavaScript technology. You do not need any Breeze on the server. The server need not use use any Microsoft technology: not IIS, not Web API, not Entity Framework, not SQL server."
Source - http://www.getbreezenow.com/spa-template
Any help?
Update:
I dont like the fact that the server is 'coupled' with the client for the metadata information. I understand this is how the breezejs functions.However and this is my personal opinion but its lot of work just to get the client side tool working with the server. This also adds traffice between server and the client. Anyway we decided to not to use breezejs because of the same overhead. (Not saying its not good for other scenarios)
Related
I've got a web application that's running Js on client side and c# on server side - What would be the best way for them to communicate over the internet and how would I pull that off - would really appreciate some resources, I've been looking around for a bit now and couldn't find anything.
There wont only be credentials from forms that will be passed through, there will be other data coming from the server time to time as well
The best answer is WebSocket. I believe that there is good support for this in c#, and I know for myself that it's pretty easy to set up in JavaScript. You can use "ws" or a secure connection with "wss".
The one thing I would warn you about is with "credentials" and sensitive information in JavaScript. On the client side, you basically have no control over preventing sensitive information from leaking. Web pages can be altered and inspected by the client. So be careful about what your server sends to your client.
I need to create a web page that gets data from an SQL database, and can run certain executables (that have already been written from previous projects).The code to retrieve data from SQL was written in C#, as it was used previously with ASP.NET. Is it possible to reuse all of this code the way it is with my current application (using Angular)?
How to set up the server side? I know I probably have to create a web server, and then use "get" and "post" requests from the client side, am I on the right track. Can JavaScript client side communicate with a C#-written server side?
Unequivocally yes, you can have a JavaScript frontend communicate with a C# backend. There are two primary MS provided technologies that can be used:
ASP.NET WebAPI
SignalR
And lots of 3rd party ones (like Nancy).
WebAPI is a simple HTTP server typically used to build RESTful backends. Given your description its probably what you want to use.
SignalR is a protocol for "push" applications (though it can be used for server invocations). If you don't need to call client-side code its a bit overkill.
On the client side, if using WebAPI or similar on the backend, you just do HTTP requests as you would against any standard API. For AngularJS that's done with the $http service, for Angular (2+) that's Http and for 4+ HttpClient.
We have a web client built with GWT that talks to a server via gwt-rpc. One part of the app will now use html/js to replace the GWT GUI and we want that part to talk to the server but not via gwt-rpc. What ways are there to migrate a gwt-rpc call to something that will work with a none a gwt client? Today we send and receive java collections that contain object graphs like a list of order objects that have them self order detail objects and so on.
Thanks
Your best bet is using REST. Your data is sent using JSON, which is part of JavaScript so it will always be understood on the client-side. On the server side there shouldn't be any problems finding a suitable library to handle the rest (ha-ha, get it?).
If you're using GWT on the client and server side for now, resty-gwt and Jersey are a popular combo. There was a talk about it on the last GWT.create conference, it's a good starting point.
I'm working on a Parse web app and have run into some problems using the backbone.js based client side javascript sdk. I noticed the way I have things set up, the client can view all of my source code by simply using the dev tools to view source files and can also run code against the database (within the limits of the ACL's I've set). I've started working on rebuilding the app in cloud code using the Express.js module Parse provides so that all of my code is stored server side, but I was wondering how those using client side frameworks get around this obvious problem.
That's the issue with client-side code. Assume any code you send to the client is hacked, broken, and tampered with.
With JavaScript, your best bet is to use either Cloud Code and send AJAX or streaming data calls to the server, retrieve the data from the server at runtime (not super secure, but would fool some people), or accept that your code is vulnerable.
I typically work with frameworks in the MVC format, so I only expose a limited subset of the actual model via a REST API. I use both a client-side framework and a server-side framework. Any thing sensitive goes on the server.
I'm working on a school project for that I've to make a forum. So I want to make it light using javascript which is run on client side. So regarding this I want to know how can I use sqlserver with javascript on asp.net. I'm new commerce and don't know much about this. I know how to handle it with c# but as every one knows it makes heavy due to run on server side.
You'll need some kind of server-side piece. You can't use JavaScript on the client to talk directly to an SQL Server instance. Even if you could hook it up in terms of the protocol and port and such, A) You'd have problems with security policies, and B) It would be a Really, Really Bad Idea to allow clients direct access to the DB.
So the typical architecture is: Client -> mid-tier -> database
These days it's not atypical for the mid-tier to be some kind of web service exposing a REST, XML, or JSON API.
You have lots and lots of choices for the mid-tier. Certainly C# and ASP.Net is one choice, but only one. There's Ruby on Rails, there's any number of JVM-based frameworks (Java EE, Play!, ...), there's PHP, there's Node.js...
I suppose one choice for the mid-tier is SQL Server itself. SQL Server 2005 offers a built-in set of web services you can enable via SOAP/HTTP. You would probably still run into issues with the Same Origin Policy, since I assume you won't be serving your web pages from the SQL Server. :-) Or maybe you could get around that, by configuring IIS to proxy for the SQL Server's SOAP/HTTP stuff and also to serve your pages, so they'd all be on the same origin (the host and port of the IIS server).