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.
Related
I have been developing an asp.net core web application and published on the production mode (online server), the users can access it with the specific domain name and will log in and do data entry from three different countries.
But, the problem is sometimes, in one specific country there is no internet access, my client wants that this application should work online and offline, If there is no internet access the local branch must be able to do data entry, then when the internet gets connected data should send to the online server database,
What is the best way to achieve this goal?
Please write your view or add some good forum link below.
Rationally, it is not possible for you to access a Web App without internet. Web Apps are meant for network usage. However, I believe there is a workaround for such requirements. What you can do is that you can create a clone of your database for the third user, who has no internet access and perform all transactions within the local machine and when the connection comes back on line, you can replicate the data from the local SQL Server into the online server database.
And then there is something called Progressive Web Apps , which will allow you below privileges :
Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
Fast - Respond quickly to user interactions with silky smooth animations and no janky
Engaging - Feel like a natural app on the device, with an immersive user experience.
What are Progressive Web Applications, Google has something more to discuss here
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'm working on a web application and I'm having problem accessing the database on server side because there is no user for the DB proxy to map. In other word, I have a method which will start as soon as the application comes online and will call itself every 5 seconds to check for new messages. If it receives a specified message, it then goes to the database and finds whatever it needs. However, accessing database on server side wouldn't be possible because there is no user for the DB proxy to map. So what is a good design pattern for this type of application? Should I need an application account for these type of automation process?
Btw, I'm using Weblogic JPA 2.1 for database stuff.
Thanks in advance.
First of all, what exactly do you mean by "no user for the DB proxy to map"?
I assume, you meant that you don't have a user known by a session who connects to the database?
If yes, you usually wouldn't do that anyway and instead nearly always have a database user for your application. Then, no matter a user triggers a database call by an action or the backend triggers it by some scheduling, it will always be the same user who does it. In your Java EE application, you'd have a datasource containing this user in its configuration and all your application parts use the related entity manager when doing persistent actions or queries.
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