I have an application that will connect to a Sql Server database that is installed in a server. The application will run in many client computers.
This application has a repository that uses EF to access to the database and has the logic bussiness related with the data of the database, check the information is correct, add, delete, modify and so on.
I am thinking that I have two main options.
First one, the client application, the application that will run in the client computers, can use this respository, so the application would can connect directly to the Sql Server database.
The second option, to have a server application that use this repository to connect to the databse. The clients will not use the repository, instead, will use WCF to connect with the server application to request actions and data to the database. The server would do all the work and send the result to the client through WCF.
If I am not wrong, WCF it is good when two applications has to communicate between them, for notify something between different applications or work together to do some work and so on. But in my case, it would be use just to access to the database, but the clients could do it directly if the use the repository. So I guess that use WCF to do that it would add a new layer that will make to have more work and I guess that comsume more resources.
However, this first option has a problem, if the repository has a bug and would make that the information of the databse it is incorrect or inconsistent, if I fix the problem, I would have to update all the clients to avoid they update the database incorrectly. But in some cases it would be very hard to ensure all the clients update the application to avoid the problem. At least, I don't know the way to force to a client can't run the application if it is detected a new version of the application. Are there any way to force this update?
The second option solve this problem, because I just to update the server application and all it is done. However, it makes the server to work more and need more resources. Also, I would add a new layer to the application, more work too.
So my question is, in this kind of applications, what is the best solution, first one, second one or another one that I don't know?
Is it possible to avoid that a client application runs if it is detected a new mandatory update? If it is possible, the first option would be a good solution, letting to the client applications access directly to the database?
Thanks so much.
From my point of view I would use ASP.NET WebApi 2 rather than WCF as with the first one you will be able to create a resource-oriented services over HTTP (RESTful) that can use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
The idea would be to call your WebApi endpoints from the client application. In this way, all the code related to retrieve the information from your database would be defined in the API and it will be only accessible through the API.
Getting started with ASP.NET WebAPi 2: https://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
Related
In a "computer system" there are two web servers that manage independent applications, both using JSP technology. There is a necessity to have access from server A to information stored in server B. In case of interconnection with:
Invocation of a data access service with GET/POST of an URL.
Definition and use of Web services.
Direct integration in Java, with Java RMI.
Which would be the best solution? Why? What are the advantages and disadvantages of each of them?
A solution would be to use REST API on the server from where you need to invoke the information. You might want to use an ajax call or just include contact via iframe.
Get call will be simple and quick to develop and maintain however if it is low latency and high throughput application then you might want to go with Java RMI.
I developed a REST API with go (golang), and now I want to design my web frontend. I don't know how can I separate frontend from backend.
I think that I have three choices:
1- Run REST API on one server and the frontend website on another server.
2- Run REST API and frontend website on the same server, but on different ports. For example run REST on port 8080 and frontend website on port 80.
3- Run Both on the same server and the same port, but use different URL paths (or subdomains) for each one.
As I don't know about this stuff, please tell me which one is true or best solution. Or is there any other solution? Does it matter how big my website is?
Either the first or second options will be mostly the same for you to set up and develop with. So you don't lose or gain anything from that perspective, the only deciding factor is your resources and how you expect your backend to be used in the future.
Currently, if you only have one application/frontend calling on the API, having them be on the same server will be the better option since it will have a marginally increased performance compared to the second option.
But, since you chose a RESTful design for your backend, you might want to reuse it for more applications in the future, and if you expect that the increase in calls to the API will start to use up the server resources, then your frontend might suffer from it and then you should consider relocating the backend to a different server.
The whole microservices, RESTful backend design "pattern" was created to decouple the front and back for better scaling, but that might not be necessary for everyone, you have to estimate the amount of use your application will realistically have and think if you might actually reuse the API elsewhere (or if you want to offer the API for others or not).
In the end, if the first and second option present a similar amount of investment for you at the moment, go for the first one, if not, just keep both front and back on the same server and if in the future you realize you need to scale out, you can just relocate the API to a different server/servers.
I am thinking in using MongoDB as my main database. However, my app is
fully in JavaScript and I wanted to use the REST API, client side.
I still can't understand what security mechanisms can I use in order to
make a JS call to the database without revealing all the data to all the
users.
Please advice on this matter.
Regards,
Donald
First of all, you can enable database auth which will make the REST interface require authentication if connected to from a remote machine.
That said, it's a very bad idea to expose your database like you suggest. Build a persistence abstraction layer in a server technology you're comfortable with (node.js for example) and put all security constraints and authentication there. The advantages are numerous :
You can keep your API stable even if the MongoDB one changes. You can even replace it with another persistence solution if the need arises in most cases.
You can limit the load a single client can put on your database. If you expose the database directly there's very little you can do to avoid people doing expensive queries or even potentially corrupting writes.
You can often do smart app-side caching and optimization that is not possible if every client directly accesses the database (this depends a bit on the app in question though).
Check out Sleepy.Mongoose, it's a REST API interface for MongoDB. I haven't tried it, but it appears to support standard MongoDB authentication.
MongoLab has MongoDB database hosting with a REST API that can be accessed client side, they even through in some jQuery based examples in their support documentation. That said, Remon is right that you sacrifice any security by doing so because you're making your API key public.
RESTHeart is a Web API for MongoDB.
It provides application level authorization and authentication.
Check the security documentation section.
Also some example applications are available on github:
blog example (using AngularJs via $htpp service)
notes example (using AngularJs via Restangular service)
I am working on a experimental website (which is accessible through web browser) that will act as a front-end to a restful interface (a sub-system). The website will serve as an interface between a user and the restful interface, as it will make http requests to the restful interface for almost all database operations. Authentication will probably be done using openid and authorization for the database operations will be done via oAuth.
Just out of curiousity, is this a feasible solution or I should develop two systems that accesses the database in parallel (i.e. the website has its own data access logic, and the restful interface has another data access logic)? And what are the pros/cons if I insist on doing it this way (it is just an experiment project for me to learn things like how OpenID and oAuth work in real life anyway) besides there will be more database queries and http requests generated for each transaction?
Your concept sounds quite feasible. I'd say that you'll get some fairly good wins out of this approach. For starters you'll get a large degree of code reuse since you'll be able to put other front ends on top of the RESTful service. Additionally, you'll be able to unit test this architecture with relative ease. Finally, you'll be able to give 3rd party developers access to the same API that you use (subject possibly to some restrictions) which will be a huge win when it comes to attracting customers and developers to your platform.
On the down side, depending on how you structure your back end you could run into the standard problem of granularity. Too much granularity and you'll end up making lots of connections for very little amounts of data. Too little and you'll get more data than you need in some cases. As for security, you should be able to lock down the back end so that requests can only be made under certain conditions: requests contain an authorization token, api key, etc.
Sounds good, but I'd recommend that you do this only if you plan to open up the restful API for other UI's to use, or simply to learn something cool. Support HTML XML and JSON for the interface.
Otherwise, use a great MVC framework instead (asp.net MVC, rails, cakephp). You'll end up with the same basic result but you'll be "strongerly" typed to the database.
with a modern javascript library your approach is quite straightforward.
ExtJS now has always had Ajax support, but it is now able to do this via a REST interface.
So, your ExtJS user interface components populate receive a URL. They populate themselves via a GET to the URL, and store update via POST to the URL.
This has worked really well on a project I'm currently working on. By applying RESTful principles there's an almost clinical separation between the front & backends - meaning it would be trivial undertaking to replace other. Plus, the API barely needs documenting, since it's an implementation of an existing mature standard.
Good luck,
Ian
woow! A question from 2009! And it's funny to read the answers. Many people seem to disagree with the web services approach and JS front end - which has nowadays become kind of standard, known as Single Page Applications..
I think the general approach you outline is quite feasible -- the main pro is flexibility, the main con is that it won't protect clueless users against their own ((expletive deleted)) abuses. As most users are likely to be clueless, this isn't feasible for mass consumption... but, it's fine for really leet users!-)
So to clarify, you want to have your web UI call into your web service, which in turn calls into the database?
This is exactly the path I took for a recent project and I think it was a mistake because you end up creating a lot of extra work. Here's why:
When you are coding your web service, you will create a library to wrap database calls, which is typical. No problem there.
But then when you code your web UI, you will end up creating another library to wrap calls into the REST interface... because otherwise it will get cumbersome making all the raw HTTP calls.
So you essentially created 2 data access libraries, one to wrap DB and the other to wrap the Web service calls. This basically doubles the amount of work you do, because for every operation on a resource, you will end up implementing in both libraries. This gets tiring real fast.
The simpler alternative is to create a single library that wraps access to the database, as before, then use that library from BOTH the web UI and web service.
This is assuming that your web UI and web service reside on the same network and both have direct access to the backend database server (which was the case for me). In this setup having both go directly to the database is also a lot more efficient then having the UI go through the web service.
I’m just working on this interesting thing with ADO.net entities and need your opinion. Often a solution would be created to provide a service (WCF or web service) to allow access to the DB via the entity framework, but I working on an application that runs internally and has domain access pretty much all the time. The question is if it’s good practice to create a data service for the application to interface from or could I go from the WPF application directly to the entity framework. What’s the best practice in this case and what are some of the pros’ and cons’ to the two different approach.
By using entity framework directly, do you mean that the WPF application would connect to the database, or that it would still use services but re-use the entities?
If it's the first approach, I tend to be against this because it means multiple clients connecting to the database, which a) is an additional security concern, b) could make it more expensive from a licensing perspective, and c) means you don't get the benefits of connection pooling. Databases are the most expensive things to scale so I'd try to design the solution to use services and reduce the pressure on the database. But there are times when it's appropriate. One thing I've noticed is that applications which do start out connecting directly tend to get refactored to go via a service later; it seldom happens the other way around. But it might also be a case of YAGNI.
If it's the second approach, I think that's fine. It's common for people looking at WCF to think "service oriented" - that is, there should be a strict contract between services and things shouldn't be shared. But a "multi-tier" application, which is only designed to have one client, is also a perfectly valid architecture and doesn't need to be so decoupled. In that case, reusing the entities on both sides of the service boundary should be fine. However, I'm not sure how easy this is to do with EF specifically, since I haven't used it except in experiments.
It really depends on the level of complexity and the required level of coupling/modularity. I think a good compromise would be to create a EF model in it's own library or the like with a simple level of abstraction. In that scenario if you chose to change the model to use an exposed service instead of direct access it shouldn't be a big deal to refactor existing code and the new service could utilize the existing library.