My web app needs a private messaging system just like Facebook Messages or Twitter DM.
I found a bunch of stuff that does real-time instant messaging, but they don't store the messages like a typical PM system does.
Plenty of sites/apps has a PM feature, and StackOverflow itself has plenty of questions about designing such a system, so implementing this myself seems like reinventing a huge wheel.
So is there such a service/platform that can be plugged into my web app? Ideally, it should be a hosted platform so I wouldn't have to deal with storing stuff myself.
Here are some ideas:
1) Build a table that stores messages as text/blobs, with additional fields for "from," "to," "status," and "date." Build UI to write to/read from this table. Success!
2) Integrate an existing forums system that already has private messages. Cut out the forums part, retaining the private message part. Success!
3) Create an email address per user on the system. Make sure SMTP/POP/IMAP traffic on public interfaces is blocked, so it doesn't escape into the wild. Integrate a webmail frontend. Success!
If you already have a user database, and a GUI framework, and application server, and your community isn't way too big, then 1) is probably actually going to be easiest. If you want something that works right away without having to change much at all, 3) is probably easiest.
Related
Over the years I have written many apps for myself and for customers using VB.NET, most of these were standalone apps which worked on workstations and servers and didn't involve much if anything to do with networking, client/server or a backend.
I want to evolve and learn more, and specifically am interested in creating a "backend" for some of my apps so that the data from the client app, whether it be error information or custom data for a client can be sent from the "client" to whatever is the best option for the "backend". I would then store the received data in a database I assume and then have ability to view it, and parse the data to show specific results etc
This is a new area to me but one I want to learn more about, so I am hoping that others who have this knowledge / experience can give me some pointers as to the best route to take etc, especially covering the points below and anything else you think I need to know but have missed
What to use for the "backend"? I prefer to have it in the cloud rather than having my own server, so do I use something like Azure? if so what? or do I sign up for hosting with a company which provided ASP and .NET Core hosting and create something there? if so what would I use?
What are the best methods for sending data from a to b - I notice most services I currently use for my apps e.g. for sending mail or error reports etc often use JSON? is that best option?
How do I send the data, any built in or suggested frameworks or API's to use to "post / send" information from my client to my backend / remote endpoint?
Hope this all make sense, please ask if not, all comments appreciated, as I say I want to use this both as a way to create / modernize some of my existing apps, but also as a learning exercise to learn areas I don't know and hopefully also make user of newer / evolving technologies and solutions.
Thanks
I am building a RESTful api for a project at the moment, the API will used for a web application, a mobile application and maybe eventually a desktop application.
There are a few instances where emails need to be sent to notify the user of an event that has happened within the application. What I am not sure of is where to does a an APIs job finish, should the API be responsible for sending the emails, or should the application send the emails based on what response comes from the API?
Basically what I am asking is where does an APIs job start and finish, is an APIs job just getting date from point A to point B? Or can it deeper capabilities?
It's a common mistake that many developers are still making. An API is just an interface through which you expose your underlying system to be accessed by other systems. How you expose your system depends on what functionalities you want to be visible to the external world. Moreover, your business logic should be entirely on your backend rather than spread over your mobile/web applications.
Having said that, my answer is yes! Don't think of it as "my API is sending emails". Think of it as "my MAIN SYSTEM is sending emails". Whether you want to expose this email functionality through your API or not is another completely different thing.
Like most people, we're pretty impressed with BigQuery. We're willing to put up with it being based on proprietary "Dremel" in exchange for not having to configure a ton of servers in our LAN, on EC2, or anywhere else.
The REST API is excellent, and we're incorporating that into our apps, but we still find ourselves using the BQ Browser interface as well. We'd like to incorporate something like a 'generic SQL window' into our app, without divulging that the backend is BQ or that data is stored in Google at all, for that matter. Does Google provide a way to use their BQ browser tool in a white-label manner?
Note also, that even extending access to the existing browser tool is problematic. It relies on user-accounts existing in one's own domain - something that can't be done, in our case, with a customer's email address. The REST interface solves this with service-level accounts, but that doesn't get you to the SQL window/browser tool.
If the folks at Google are listening (and I know that you are), consider the benefits of white-labeling the browser tool: I think you'd find a lot of software companies integrating it into their suites of products and, then, running circles around any Hadoop/CDH/EMR/Impala/Hive combination.
So, to summarize: How does a software developer import or emulate the BQ browser tool (with all it's autocompletes, query histories, etc..) in their own web-based app?
The initial version of the BigQuery web interface was considered just an 'example' UI that anyone could create themselves. It uses only the public BigQuery API to talk to BigQuery.
There are a couple of Google-internal things we've added since then, such as the current design of 'saved queries', and an auth shortcut so that users don't have to explicitly grant permission to the UI to access BigQuery data. But it is still mostly plain-ol-javascript talking to BigQuery via the REST API the same way anybody else does.
The javascript is obfuscated, however, but my understanding is that this is just for compression purposes so that it downloads more quickly.
The SQL highlighting is done by CodeMirror with special configuration for the BigQuery SQL variant.
I'll talk to the other members of the BigQuery team about open-sourcing the javascript code in the Web UI. It may be difficult to do at this point, but it doesn't hurt to have a conversation about it. I'll bring this up with the team and update this thread. The most likely answer will be "We'll think about it", but hopefully we can also think about it and start working on it too :-)
Let me know if that sounds like it would meet your needs. It might not solve the auth problems you mention, since your users likely won't have BigQuery accounts, but you may be able to solve that by proxying oauth2 access tokens.
Is it possible to use Google Analytics API's to track Mac OSX applications?
If not could any one suggest me an alternative for Google Analytics.
Google Analytics is designed to work with web applications not for desktop apps. Although it might be possible to collect info about your application and send it to your Google Analytic account but the amount of work required to retrofit might be better spent, building your own Analytic solution.
A good starting point would be to create a simple web service, which collects information regarding clicks. Then rewrite your application to call that web service on every click within your application.
You would ideally want to store this information locally and submit it to the web service in batches. You would also want to design the application, so that if you ever shut down the web service, the application would still be able to operate.
UPDATE: As pointed out in the comments by Václav Slavík, they have added apps analytics for iOS/Android.
I made a simple set of classes for doing this:
https://github.com/stephenlind/SimpleCocoaGoogleAnalytics
Google Analytics is not only for web applications, but also for mobile. It's available on the platform like android, iOS, etc. If you want to track your MAC OS X application, you can choose DeskAppTrack or DeskMetrics. DeskAppTrack is only available on MAC. It provide a professional data statistical analysis and it's free. While DeskMetrics is available on MAC and Windows. Either one is ok.
This really depends on how detailed you want to get. If you are are truly looking for analytics with detail and control flow data, you are better suited to created your own web service, as mentioned.
However, if you simply want to know a small number of operations, that occur at a small volume, i.e. when the app is launched (a quick and dirty solution): then in theory you could create a landing page on your site that contains a minimal head section, and a blank body, and then load the URL with an NSURL when you want to trigger the action.
Of course, you would have to include the google analytics tracking codes in the header, and you may need to load an off-screen webview to get the javascript to run. Like I said, quick and dirty.
In either case, you want to make sure the application will continue to perform properly, even if the web service / page is not present.
How can I build a simple 2-player game, that communicates over the internet?
I need to solve the problems of:
lookup or rendezvous - two players want to find each other.
ongoing communications. Either player can initiate an action that requires delivering information to the other side, in a reasonbly quick timeframe (IM-type latency, not email-type latency).
In this regard, I suppose it is equivalent to a 2-way chat, where people want to be able to find each other, and then also, once paired up, intercommunicate.
Further requirements:
for now, assume the endpoints are Windows OS, relatively recent.
assume neither endpoint machine is directly accessible from the internet. Assume they are client machines, hidden behind firewalls that block incoming requests. The machines can make outbound requests. (say, over HTTP, but TCP is also fine)
communication should be private. For simplicity, let's say there's a shared secret already in place, and the endpoints are able to do AES. I guess what I mean by this is, any intermediary should not need to decrypt the message packets. The decryption will happen only at the endpoints.
all custom code should run only on the client PCs.
Assume there is no server in the internet that is under my control.
I'm happy to use third-party servers to facilitate intercommunication, like an IM server or something, as long as it's free, and I am not required to install custom code on it.
What APIs are available to facilitate this design?
Can I do this with IM APIs? WCF? Are there WCF Channels for Windows Messenger?
What protocols? HTTP? I have this tagged as "peer-to-peer" but I mean that virtually; there's no hard requirement for a formal p2p protocol.
What message formats would you use?
EDIT
To clarify the requirements around servers, what I want is NO SERVER UNDER MY CONTROL. And NONE OF MY CUSTOM CODE ON ANY SERVER. That is not the same as "No server".
Think of it this way: I can send an email over SMTP, using custom code that I write on the sending and receiving side. My custom code can connect via a free SMTP server intermediary. This would require no installation of code on the SMTP server. This is something like what I want, but SMTP is not acceptable, because of the latency.
EDIT2
I also found this: library for Instant Messaging, like libpurple, but written in C#
ANSWER
I can do what I want, using libraries for IM frameworks. One simple way to do it using Windows Live Messenger is to use the Messenger Activity SDK. This proves the concept, but is not really a general solution. But, similar things can be accomplished with the IM libraries for various messenger systems, like libpurple, or using libs for IRC channels. In all these cases, the IM servers act as the firewall-penetrating communications infrastructure.
IM is the wrong tool. Instead, use an IRC chat room.
With an IRC chat room, your clients "log in" to the chat room, and that is used for your "presence". Anyone in the chat room is "available" to play the game.
Once that is done, the game instance communicate with each other through the chat room. They can use the global channel, or simply private IRC channels for game traffic.
The issues to solve:
First, all game state is shared on the clients. Many games have done this (RTS's like Age of Empires, RPGs like Diablo). But client states are susceptible to hacking and cheating. That's just a plain truth. If the game is popular, it WILL be hacked.
Ping traffic. Basically the flow is you log in to the room, your client is in "available to play" mode. Then it pings EVERYONE ELSE to see if THEY are available to play. This will happen with every client "sign in" to the chat room. You can then use the public room for broadcast events "Frank is ready for a new game", "Frank started a game with Joe", etc. That can help keeps games in sync and not chatty, but when a client connects to the chat room, it's going to go "Hi All, it's Bob, what are you all doing". So you need to manage that.
Traffic volume. IRC rooms can handle a lot of traffic, but not a LOT of traffic. Most are designed to prevent "spamming", "flooding", etc. So you may well be rate limited on you game play. Not a problem for "Checkers", more so for "World of Warcraft" during a 40 man Raid. That's a game design issue.
Terms of service. The IRC provider may well say "Uh no, you can't do that with our service". I haven't looked in to it, so I don't know, but could be an issue.
Other than that, IRC is a pretty good fit. Lots of IRC bot code floating around on the net, I've never used any of it.
Every two-player game must have some type of server environment by the basic need of having to communicate between two clients/players at the very least. Keep in mind, each of the clients/players can also act as its own server to communicate with other linked clients. But the need to keep tabs on all clients/players at any given time and the need to facilitate searching of other clients/players inherently requires some type of server environment to begin with.
libpurple along with otr can give you the privacy-over-IM such an application would need.
You could setup a message board on one of the free message board servers so that players can find each other. You'll probably want to encourage them to use private messages to exchange IP addresses. Then, use a protocol that connects using IP addresses. Good luck with that. Firewalls make it a pain.
Then, of course, one machine of the pair would need to act as server, the other as client. Your software must contain both sets of code. I've written such a game and can tell you that the communication code gets a little confusing.
I can tell you right now that you'd be much happier in life if you wrote a web service to facilitate communication. But, then, you'd need a server for that.
Good luck. You're going to need it.
OR, you could just write a game for an IM client, like Microsoft Messenger. I've seen games for that one, so I know it can be done.
As somebody has said, it may not yet possible to do so if you don't have any mediated server between 2 players. As you're happy to use third party server, I suggest that you build your system using Google App Engine + XMPP over HTTP. It works nicely over internet and behind firewall. And yet it's free (as long as your system doesn't grow out of GAE quota).
Peer to peer is out due to your firewall constraint. This doesn't really work easily for directory services anyway.
The next easiest method I would use is to toss up a very simple CGI server script on one of the numerous super cheap web hosting sites. It seems that you don't want to go this route. Is there some particular reason? 100 lines of code and a super cheap server should give you everything you're asking for and more.
I suppose you could hook into some sort of third party chat library thing. I don't know about the current IM protocols, but good old IRC and a separate channel for your game would work. You even could cobble something together using FTP. BLOG comments on a free blog site would work too. The question is why?
These are all kludges. They get the job done in obtuse, inelegant, and poorly scaling ways.
I urge you to reconsider the web server solution.
You have a lot of conflicting requirements. Both clients behind a firewall blocking incoming requests pretty much means they can't do peer-2-peer since neither machine can act as the server, and you will need to have a transport server in the middle somewhere routing messages to each client. Right now what you are asking is pretty much not possible given the no server requirement.