When do we use client side reporting and when do we use server side reporting?
Which reporting is best practice (client/server)?
This pertains to SSRS reporting.
Well... client side reporting you'd use if you've got something like a winforms client that you can't guarantee will have constant access to the data source. It might have a set of data cached on the client side which you need to report on even if the connection to the server is unavailable.
Server side reporting you'd use in the scenario where you either need to simplify the report distribution and deployment as you just deploy the reports to one place and everyone can access them. This has the downfall of always requiring a connection be available to the server
Client side reporting is also handy when you have a client gathering data from very different sources. We have an in-house corporate application that calls internal services to get data from financials as well as our separate production database, and it combines them into a single dataset which it passes to a ReportViewer control.
From an aesthetic point of view, it's nice to integrate reporting into an application so that the user doesn't feel that they're leaving the app to print or export the app's data.
Client site reporting
If one of the following is true then you should use client site reporting:
If you have the data only on the client and not in the network or on the server. This is mostly true for desktop applications.
There is no server (Home systems).
Server site reporting
If one of the following is true then you should use server site reporting:
The data is on the server or on a static place in the network.
You only have thin clients.
The reporting should be scheduled.
The license cost for a single server is smaller than for many desktop installations.
Report templates are shared and can change frequently.
It depends what you call "server" in this case. As you mention SSRS I am assuming you consider the database (SQL Server) as the server.
It all depends on the application/project structure and requirements. If you have a database that contains also the business logic (store procedures) and you simply want to query data and display/export it, then SSRS is handy.
However if you have a web application with your persistence layer (database) that simply stores information and ensures the information is consistent, but then your business logic is for example in a Web API (i.e: a RESTful API project) that queries/maintains the database data (CRUD) and adds some logic and then responses to HTTP requests with the results/information requested (i.e: with JSON) to a rich front-end, then I would add reporting functionality at client-side (front end) with for example a Javascript library executed in the browser that is able to display the retrieved data in whichever way, it is able to export it to a DOC, Excel, Email it, etc.
Separation of concerns for a typical Web Application:
persistence layer (Database) to store information and guarantee consistency
business layer (Back end RESTful API) to do all the smart things on the resources, calculations, authentication, authorization for each HTTP request.
Rich front-end (Javascript + HTML + CSS) to interact with the user and request/display information to the back-end. As part of the concern of displaying information, this front-end would also generate reports.
Related
I am new to web development, and have seen posts such as these . If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
You're probably going to get a bunch of conflicting opinions on this. My personal opinion is a web service in front of your database makes sense in some scenarios. Multiple applications connecting to the web service instead of directly to the db gives several advantages, security, caching, etc.
That being said, if this is just a single app then most of those advantages disappear and in fact just make things more complex for you. You're going to have to setup your web service for the db as well as your actual code.
If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
No, if Node.js is running on a server or in "serverless" containers (e.g. AWS Lambda) that is not a direct connection. That is a web service, and that's what you want.
A direct connection means the app connects to the database itself... but that requires embedding credentials in the app.
You do not want to embed anything in your app that you would not willingly hand over to an arbitrary user -- such as database credentials and API keys -- because you cannot trust that the app won't be reverse-engineered.
You should design the app in such a way that you would have no security concerns if the entire source code of the app were exposed, because knowing everything about the app's internals would give a malicious actor no valuable information. How? The code on the server side (e.g. in Node.js) should treat every request from the app as potentially suspicious, untrustworthy, etc., and validates every request to do anything.
This layer of separation is one of the strongest reasons why you never give the app direct access to the database. Code running in a trusted place -- your web server/API layer -- needs to vet every database interaction. This topology also decouples the app user from tying up resources on the database server when not actually interacting with the database, which is far less practical with a direct connection.
Consider that you have a WAMS service (.net backend in my case) and client mobile apps out there in the wild, and you want to release v2, which contains breaking schema changes (splitting a single table into two tables for instance).
I understand staging on the server side, but this question is about client versioning. How does one handle the period during which your updated mobile app is gradually rolling out among the user community and you have a mix of old and new clients in the wild?
Approaches I have thought of:
Deploy the v2 mobile app with a new URL pointing to a new service. PRO:simple client code CON: Expense of two WAMS instances and complexity of synchronization across two db instances (a single user might have different client versions on different devices and their cloud data in the different WAMS instances needs to stay in sync until they update everywhere).
Add version awareness into the mobile app with two or more sets of data model classes - one set for the current version and one set for v.next. You roll out the version-aware client before upgrading the server. PRO: simpler and cheaper server-side management CON: larger and more complex client code and users that don't update are locked out after the server update. Also, gates the server rollout date upon the client app approval timeline in multiple app stores.
Use a single database and single server instance, but support a hybridization of the old and new server versions through some clever use of DTO's that presents the old wire protocol on top of the new schema alongside the new objects. Presumably, I could add a version element to the routing paths on the server. PRO: simple client, no server-side cross-db sync CON: more complex server code; keeping offline sync working gets difficult if tables split or merge (possible solution: parallel tables kept in sync with code/scripting)
Option 3 is my current favorite, but is there a better/preferred way of flighting breaking changes in a WAMS deployment with a .net backend server and offline-sync-enabled, multi-platform client app?
You could also consider using the Azure API Management service (http://azure.microsoft.com/en-us/services/api-management/) in order to handle the versioning. That would probably be most useful for option 1.
There really isn't a simple solution, and if #3 is the best for your scenario, I would recommend you go with that.
Im just in the process of putting together the base framework for a multi-tenant enterprise system.
The client-side will be a asp.net mvc webpage talking to the database through the asp.net web api through ajax.
My question really resides around scalability. Should I seperate the client from the server? i.e. Client-side/frontend code/view in one project and webapi in another seperate project server.
Therefore if one server begins (server A) to peak out with load/size than all need to do is create another server instance (server B) and all new customers will point to the webapi's on server B.
Or should it be all integrated as one project and scale out the sql server side of things as load increase (dynamic cloud scaling)?
Need some advice before throwing our hats into the ring.
Thanks in advance
We've gone with the route of separating out the API and the single page application. The reason here is that it forces you to treat the single page application as just another client, which in turn results in an API that provides all the functionality you need for a full client...
In terms of deployment we stick the single page application as the website root with a /api application containing the API deployment. In premise we can then use application request routing or some content-aware routing mechanism to throw things out to different servers if necessary. In Azure we use the multiple websites per role mechanism (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) and scale this role depending upon load.
Appearing to live in the same domain makes things easier because you don't have to bother with the ugliness that is JSONP or CORS!
Cheers,
Dean
Could someone please explain to me in a simple way, what is a web service?
Please correct me if I'm wrong. I have a DB hosted somewhere in the web, and I want to perform DB transactions from a desktop application as well as a mobile application. Can this be done through a web service ? Someone mentioned it to me and I wanted to make sure this could happen.
Here's a good explanation on Wikipedia.
A middle dynamic content processing and generation level application server, for example Ruby on Rails, Java EE, ASP.NET, PHP, ColdFusion platform
The middle tier of a 3-tier application is often the web service
i want to perform DB transactions from a desktop application and a mobile application, can this be done through a web service ?
This is Exactly what a web service is for.
A web service allow you to create multiple front ends if needed, and serve your database data to all of those front ends. You can also open up the API and allow third party developers to access the web service and thereby access the data of your application in a controlled environment.
It's considered a better practice for larger applications to access a web service or a middle tier rather than directly access the database.
In your case, a web service would involve setting up your DB behind a web server that listens for incoming requests, performs the appropriate DB operations, and returns whatever data is appropriate. Then, your desktop and mobile applications could send a http request and the DB would respond appropriately. This would let all your applications access the same DB.
Does anyone know what the difference is between the two web service endpoints ReportService2005.asmx and ReportExecution2005.asmx in SQL Server Reporting Services? is there an article that I can go through? Thanks.
The ReportExecution2005 endpoint allows developers to programmatically process and render reports in a report server. The WSDL for this endpoint is accessed through ReportExecution2005.asmx?wsdl.
The ReportService2005 Web service (reportservice2005.asmx) allows developers to programmatically manage objects in a report server.
As Mitch says, ReportExecution2005 is for executing reports, handling drilldown, rendering, etc. and ReportService2005 is used for creating things (data sources, subscriptions, even reports), as well as updating, deleting, querying, etc.
Two handy references are the MSDN method listings for ReportExecutionService (ReportExecution2005 web service endpoint) and ReportingService2005 (ReportService2005 web service endpoint).
Don't confuse these with the ReportService2006 endpoint, which is used if you have SSRS configured for Sharepoint integrated mode.
Hope that helps!
ReportService2005
Enables you to manage a report server and its contents including server settings, security, reports, subscriptions, and data sources.
Can be accessed by: http://servername:port/ReportServer/ReportService2005.asmx?wsdl
ReportExecution2005
Enables report execution
Can be accessed by: http://servername:port/ReportServer/ReportExecution2005.asmx?wsdl