I'm trying to build a web app that lets a user create a session which generates a unique session ID through which other users can join the session and post messages on a board. However, I am stuck at real-time updates for the specific sessions as I am unaware of technologies that allow me to accomplish this task. I've read about .NET's SignalR as a real-time web app API but so far have not found a way to handle each session separately. I am looking for recommendations and preferably tutorials on how to implement this feature.
The Web API is built in Spring Boot and .NET, so I would prefer APIs/tutorials for these frameworks. Thank you.
Just thinking of the easiest way to do this with minimal strain on the server. I think I would go down the road of storing the session IDs in the db and then use ajax to handle the realtime updates. Ajax can run on a js timing loop that can check a serverside flag which is set once updates are made to the db. Upon finding a set flag the ajax can then pull in the updates or do a page refresh.
Related
I am building an extremely simple VB.net web application that uses Visual Studio's forms authentication. As part of this- I am trying to capture the userID upon login and use it while the user is in the app (to dynamically display information via dataset/gridview that is associated with that userID) so I don't have to give them their userID and prompt them for it constantly.
The app is very simple and uses a local DB to do all the authentication (Users, User_Activation, Roles)
This app will have 9-10 users that will be consistent over the years(logging in 10-15 times a year), and 40-50 rotating users that log in once or twice and do not return past that year.
The profiles and authentication/sessions do not need to handle tons of users and authentication requests.
I also want to avoid cookies because I want to keep everything as simple, and centralized to the application as possible.
I have explored building a GetUserID function that queries the database based on the userName every time a user takes an action (button click, page load) that requires the userID. But I am having trouble with the SQL and it seems bulky.
I have also looked into sessions- but they seem unreliable and difficult to manage.(How do i keep each session separate as users login?)
I am now looking at Profiles
https://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
https://msdn.microsoft.com/en-us/library/system.web.profile.sqlprofileprovider.aspx
I think I can just use the default instance of the SqlProfileProvider and point it to my database I already have built?
I am very new to programming and am not sure how complex the configuration would be for the Profiles, so any guidance or advice would be greatly appreciated!
I can post any code snippets needed, or upload the app to github or something if that helps at all.
Thanks!
I'm building an app which uses user contributed content.
The contribution by each user should be available to all others in real time.
I was looking into firebase Realtime database for this.
However, when a user contributes content, there are quite heavy validations and calculations (read server side) to be done on the data before making it available to others.
Is it possible to have a server side validation in firebase ? Or should I look for alternatives ?
Initially, Firebase did not have a feature to implement server-side processing/calculations. All your processing had to be done on the client side.
Now, they've recently introduced a new feature called Cloud Functions For Firebase. Its a really useful new addition where you can write server-side code without the hassles of managing servers or instances. Read up more about it from the above link.
Also, this Youtube playlist by Jen Person is a great start. And, you can find examples similar to your use case here.
My question is how to best handle temporary data for an session. The scenario is similar to a shopping cart or like a bet slip. While the user is navigating the site and adding items with unique ID's. I'm only interested in the data collected this way if the user wants to commit it.
I'm developing in ASP .Net 3.5 with jQuery,JSON and a MS SQL DB.
As I see it there are a few possible ways to do this.
Perform a full post back to the server. Store every selections, update page controls accordingly.
Send selections via a Ajax request back to the server and update displaying control.
Build all functionality in JavaScript and store all values in a session cookie. Nothing being sent to server until user choose to commit.
I really want to consider performance here but I don't want to end up with 1000's of lines of JavaScript code..
Any suggestions of the best implementation with pro's and con's?
Cheers,
Stefan
Storing things in a session cookie is not a good idea, because that will be sent back to the server with every request. If you could find a way to store the state on the client without using a cookie, then you might have a viable client-centric option, but i can't think of anything portable off the top of my head. There are things in HTML5 and Flash that can do it, but you don't want to go there - yet, in the case of the former, and at all, in the case of the latter.
I'd use AJAX to post back to the server (with graceful degradation to a full post for browsers that can't handle that), then store the information in volatile memory there - ie not in the database. Write it to the database only when you need to. This is very easy to do in Java (you can associate information with the session), so i assume ASP.net has some way to do it too.
All three possibilities look good to me. The question, however, is: how much traffic do you expect?
Each of the options you presented suits better to a given scenario. Let's say you will have A LOT (thousand of thousands) users and not a lot of hardware available then you should probably try to minimize the number of requests to your app and store data in the client as much as possible before sending it to the server.
If it is smaller application then using Session or some other central database storage would be fine.
It all depends on your requirements.
I'm building UI logging into a long-existing ASP.NET enterprise application. I have my own ideas of how to progress from here and am continuing to research & design. But I'd love to hear some details from the SO community.
Here are the details, assumptions and questions as of right now, subject to evolve within the enterprise as well as whatever input comes in here on SO:
Would prefer to have a consistent DB connection since there will be a lot of activity
Will probably use the ThreadPool, but will this conflict too much with ASP.NET vying for threads?
Possibly use in-memory queue (Queue) for logging batches of inputs periodically? (one per domain)
Will need to be configurable. IE: Could log all page events during their normal postback calls, or hook individual control actions or events to being logged whether there's a postback or not. IE: User collapses a panel.
All "high-visibility" UI events that'll already be posting back as well as other events that won't necessarilly post back right away. Have a client batch of events and send occasionally?
How do we minimize the impact on existing code?
Have "fly on the wall" AJAX functionality that posts back accordingly? It'll basically be watching all that's been configured to be logged.
Logging must be ordered for reporting a user's step-by-step progress from point A to B in a workflow.
How about a WCF service that does the actual logging, paired with a PostSharp attribute. In your PostSharp attribute you can call asynchronously to you WCF service while your application hums along. I've implemented something like this in past projects and it works great with little if no slowing down.
http://www.postsharp.org/
Why not use log4net? You could capture a userid, sessionid, and any additional information you need to track step-by-step progress. You could configure the levels so that you could reduce the logging if it impacted performance. I wouldn't consider re-inventing the wheel by writing your own framework when there are several viable existing logging frameworks.
I want to enable an user to be able to communicate with other users through a site. I know that ASP.net is stateless, but what can I use for this synced communication? Java servlets?
I don't think you need to set up Java just to use a servlet for this. I would use AJAX and the database. I don't know ASP.NET but I PHP is similar in this case, being also basically "stateless". If you want to display some kind of asynchronous communication between two different users, say, from two different sessions, without a lot of refreshing (like chat), you can have the AJAX page constantly poll the database for new messages, and display them when they come in. You can also use AJAX to insert the new messages, giving the user read/write access to this messages data structure. Since the "other" user is doing the same thing, user A should see new messages pop up when user B types them in.
Is that what you mean?
You probably don't want to use sessions for things like chat messages but you probably could use some type of implementation of queueing using MSMQ.
The approach to chat could be done in many different ways, this is just a suggesting off the top of my head.
Could do a messaging solution in Java Servlets using the application context. Objects stored as attributes in the application context are visible from anywhere in your webapp.
Update: Chat like functionality... I guess that would be AJAX polling your message structure stored in the app context unless you want to use something like applets.
Don't know if it's any good, but there's a chat servlet here that might be useful to use or learn from if you decide to go the Java route...
ASP.NET is "stateless" but it maintains state using Sessions. You can use them by default just using the Session[] keyword.
Look at ASP.NET Session State for some details from Microsoft.