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.
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.
I have silverlight web app. This web app run in 4 servers with a NLB in front of them. I need to use SignalR in my web app.
Lets think about this scenario.
Client#1 is connected to Server#1 and everything is okay. They are communicating each other through a hub perfectly. Then suddenly NLB assigned Client#1 to Server#2.
Now, what will happen to Connection and Hub? How they will communicate?
How is the connection between Client#1 and Server#1 set?
PS: I don't know much about NLB. Maybe it is stupid question, but I could not find a good explanation.
My second question is, which way among scaling out (Azure, SQL, Redis) is the best for .NET Silverlight app with possibly not many clients (Less than 10K)?
Not: I use MS SQL, SQL Server highly in my app.
After I watch this very informative video, I found answers to my questions.
Basically, the new connection will be established automatically when the client is assigned to other server node. The old connection is lost, however in any case, all the clients can be notified if you are using Back-plane. Thus, this is not a problem.
The hub object is also not a problem since it is transient object, i.e, in every new single operation a new hub object is created. Thus, this is also not a problem. There is no persistent hub object between server and client. Even if there is one server and one client, the hub will be destroyed and created in every operation.
The only problem is that if you are using groups, then the group information is lost for the client when it connects to the other server. The server does not maintain lists of groups or group memberships. So in that case you need to use a database and you can update manually from your db. When the new connection is establishes between client and new server, you can search this client in the db, and if you find a group information of that client, then you can manually re-register to that group again.
For choosing the Backplane, there is no fastest or best way. Nobody can say this way is faster or better among Azure Service Bus, Redis, SQL. It really depends on your application. If you are already using MS Azure Services, then pick Azure implementation for your web app. If you are using Redis in you app, go woth Redis. Otherwise you can select SQL. As I said, all of them are more or less same. Pick one that is most suitable for your web app.
These are all what get from video and the official site of the SignalR page.
This site is one of the best SignalR tutorial and api guide site. It is highly recommended that go through all sections.
I have a MySql database set up and a mobile app that should be able to write/read to and from the database.
The data being stored will be posts, comments, votes, etc.
Eventually, I might create a website that uses the same database.
My question is, do I need some sort of middleman (restful) service running or can I just connect straight to the MySql db from the client code (either the mobile app or website)?
Introducing a REST api into the middle would be much beneficial in a lot of ways.
Improve generalization and reuse. (REST api can be used by both mobile client and web client, no need to do the same work twice)
Can maintain business logic centrally. (If there's a logic to change or a bug fix, no need to correct in 2 places)
Can be easily exposed to any other app/client which would need the set of operations provided by the api.
Extending and maintenance of the app would be much simplified and would take minimum effort.
Especially with the mobile application, where you have much less control of updates, it seems better to use some middle-ware to connect to your database.
Say for instance your website needs a little change in the database that would break an active version of the mobile application. A web service could catch that for you.
What about a new version of your mobile app that needs a change. Again a web service can handle that for you.
This is all about cutting dependencies and keep the complete ecosystem adaptable.
Whether this is a rest or any other type of web service is a completely different discussion.
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
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.