I am developing a application that is using backbone.js for most of the front end logic and was thinking of using sqlite for storage, but i have run into a few complications with it and need to switch to another NoSQL database.
I see on ravendb's site that it was created in C# and you need a .net compiler. Most of the docs are for ASP MVC type application. I can not go this root because we are developing this as a tablet application with no microsoft based technologies on the client side ( because we want it to work with android and apple )
The server however will be .NET and so i figured this might be do able. Just wondering if this is worth pursuing and if anyone has had any experience using ravendb? Or should i go for mongodb?
It is possible to expose RavenDB directly to a JavaScript application, sure. But it's usually not recommended. The main reason is security, but there are many other reasons to have a middle-layer.
For example, you often need a server-side location to perform application logic. Not everything can be done in the database itself, and if you do it all in the application then you will probably send a lot more data to the app than it really needs. Over the internet, that could mean a slow app.
The route many people take, is to use ASP.Net WebAPI, or ServiceStack, or another similar framework. This gives you a way to expose REST endpoints that your JavaScript app can call. You can connect to RavenDB from there.
Also, you seem to have the misconception that if you used ASP.Net MVC on the server that you couldn't target Apple or Android. That's just false. Whether you use a SPA approach or a traditional approach, you are delivering standards-based content, such as HTML, CSS, JSON and JavaScript.
Yes, You can use it. Actually RavenDB's server is a RESTful web service, which means you can work with it with any kinds of HTTP clients. These clients should be able to issue standard HTTP verbs like GET, PUT, DELETE etc.
ASP MVC is server side. I still at a loss as to why you would want to expose your db to a clientside piece. It is completely worth doing in a server side piece, but do not expose something like a db directly to your client.
Related
I am building a service-oriented system for personal use (plus few friends may have limited access as well) - the aim is to have a dashboard for controlling my apps running on various machines such as Raspberry Pis (and potentially to be expanded to a VPS or few in future).
The architecture itself is pretty simple. For authentication I want to use AWS Cognito. Services would communicate with WebAPI (and potentially with eachother) using gRPC within a VPN, and dashboard would be served by Blazor server-side (may move to Blazor WASM Hosted model if I find a need for it). Each of the processes may or may not be on the same machine as any other (depending on the purpose). Blazor server may or may not run within VPN (I might want to move it to a separate web hosting later).
I created a simple diagram to visualize it:
The problem comes with authentication. I want to have Blazor server-side and API as a separate processes (for now they're going to run on the same machine, but I may want to move it elsewhere eventually). Ideally authentication should be handled by API, so authentication is client-agnostic, and the API can use it to verify if the logged in user can perform an action - which by itself is simple.
However, I want Blazor server to use and validate that token as well in order to determine what to display to the user. I want to do with the least amount of calls possible - ideally avoiding querying API for every 'should I display it or not?' choice.
I could easily do it by sacrificing possibility to move API elsewhere, and just merge Blazor Server and API Gateway into one project. For my current purpose it would be enough, but it's not an ideal solution, so first I want to look into how could I achieve my original vision.
How could I achieve this (with minimal amount of Blazor server to API queries)?
I was googling for solution a lot, but so far only found either examples of using Blazor server and API as one project, or using client-side calls to API directly.
Thank you good folks in advance.
First off, I need to mention that I'm not sure if what I'm trying to achieve is even supported by Piranha CMS (that's partly what I'm trying to determine here). They mention the ability to create a standalone content hub on their website, but my assumptions of what is possible with that model might be incorrect. What I've already done is created an ASP.NET MVC application that is hosting Piranha CMS and I've published it to Azure websites for testing purposes--that part works as expected. The content management interface is the only user facing piece here--it is meant only to serve as the content hub for the client application (just the one for now as this is just proof of concept work).
I am now trying to build a client ASP.NET MVC application that pulls content from the hub. This is where I'm thinking that my assumptions may have been wrong. I was thinking that I'd be able to install the Piranha CMS nuget package(s) on the client as well, and I'd be able to configure the framework to get content from the hub in the same way that it would if the content were hosted on the client site. I realize that I could get the content from the hub using Piranha's REST api, but what I want to do is to be able to use the more friendly entity model based api for this.
So my question is whether it is possible (within reason) to setup Piranha CMS in the way that I've described. If it is, how exactly do I configure the client such that it is aware of the location of the content hub?
There are currently no .net client api consuming the rest services as the simplest scenario would be to deploy .net applications together with the server. In the setups I've done native apps & html5 knockout/angular applications have used the rest api's for getting json data. You should however be able to white such a module, performing the HTTP calls and the deserializing the json without any problems.
Regards
Håkan
I've programmed a lot in asp.net mvc web applications. Now I want to write cross-platform mobile applications with cordova for the frontend and azure for the backend.
I am in doubt whether to use azure mobile services or WebAPI, because I want the power and freedom of WebAPI, but the convenience of azure mobile services. I do not understand concepts such as authentication, push notifications, etc.
My main goal is to focus on the application logic, frontend and backend with a significant weight of that logic in the backend. For this I have great doubts.
1st. I see both good mechanisms in AMS and WebAPI for external authentication, but not to manage your own authentication. What is the best way to manage your own authentication? Is Azure Active Directory solution?
2nd My intention is to create a well-defined API methods that return the exact data (json), rather than a rest api queryable (odata).
Wich is te best for this, WebAPI or AMS?
3rd I have experience with SQL Server, its relationships and Entity framework, but I do not care to learn and use NoSQL technologies, which is better? (However, I'm not comfortable with I can not use many to many relationships in NoSql).
Thank you very much.
there is not a real general answer for that, so take these as advices.
At first, keep in mind that AMS and WebApi are not so far. An AMS project IS a WebApi project with some helpers inside to make you comfortable working with related services (push notification, table entities), but you will lose a bit of control on your application.
The choice depends on your needs
Azure Active Directory IS a solution, but there are a lot more. You can use your preferred framework. AMS has got a pretty integrated login with most known social network and azure active directory as well, and is very easy to set up.
I'd suggest AMS. It will be easier to setup and mantain.
AMS is just WebApi castrated. To get all these services easier for you, you cannot for example
Customize startup of your application
Use a dependency injection framework
Run background tasks
And other stuff like that.
Hope it helps!
I have created a silver-light website.
Silver-light has part for the client side and part for the server side.
Now, I want to crate another site in .net MVC 4.
I can't really understand two things.
The first is, where the site will be executed?? Client side or server side??
for example if i have a LINQ function in the controller, where it will be executed??
The second is, may i use WCF like in silver-light?? Or i can just add .edmx file(ado.entity file) in the project??
Yes you can able to use WCF service in silver-light application. You must need to add the reference of the WCF application
The answer to your first question is that MVC is a server-side technology. You can utilize JavaScript and other methods to utilize the technology for client-side functionality, but it requires the controllers, views and models to execute on the server.
The answer to the second question is that WCF can be used just like Silverlight in MVC, although depending on how you utilize it, depends on if it is consumed on the client-side or not. If you access WCF through the Controller, its done on the server side. If you consume it through AJAX/jQuery then you are handling it through the client-side.
I have a web site that needs data to be pushed to it. Unfortunately, I'm not aware of any other methods besides using HTML 5 WebSockets (I can't garauntee my clients will have HTML5 browers) and Comet (I'm not using java/tomcat).
I am not a big fan of using server-side ASP.NET for this particular project, and would prefer to use ASP.NET MVC or something like it. Is it possible to tie JavaScript in with a duplex service?
Well actually you can leverage the pollingduplex binding used for silverlight clients in javascript. There is an interesting blog post on this by tomek over here: http://tomasz.janczuk.org/2009/07/pubsub-sample-using-http-polling-duplex.html