From looking at App Engine's XMPP docs at https://cloud.google.com/appengine/docs/go/xmpp/
It seems that Google only offers a client to be hosted on appengine, but not the XMPP server itself. For that, one needs to use a different host (such as GTalk)
Am I understanding this correctly?
If so- does that mean I must host my own xmpp server (ejabbered) if I want on-the-fly session-based clients?
If that is also true- then is there a mechanism in ejabbered for lightweight session-based clients? (i.e. many to be quickly created and destroyed- only needs to respond to presence requests for the duration of the session, will never be used again)
Is there a stable, scalable host out there that can do this for me so I don't need to worry about the ejabbered server going down (whether it's hosted on AWS,GCE, etc. the beauty of AppEngine so far was I never had to worry about that)
Thanks!
To address your questions:
Am I understanding this correctly?
You use to have to use Google Talk XMPP service, but I guess, yes, now you need to deploy your own server.
If so- does that mean I must host my own xmpp server (ejabbered) if I want on-the-fly session-based clients?
Not sure what "on-the-fly" session means, but yes, it seems you need your own server.
If that is also true- then is there a mechanism in ejabbered for lightweight session-based clients? (i.e. many to be quickly created and destroyed- only needs to respond to presence requests for the duration of the session, will never be used again)
Not sure what you mean by this. XMPP is a connected protocol. It means the session is linked to having a TCP connection opened. That said, ejabberd SaaS allows to maintain the session for a while if you do lose the connection (designed for mobile). You can simply reattach to it.
And by the way: In XMPP, you do not "respond to presence request". This is the reverse: Your presence is broadcasted to your contact (roster)
Is there a stable, scalable host out there that can do this for me so I don't need to worry about the ejabbered server going down (whether it's hosted on AWS,GCE, etc. the beauty of AppEngine so far was I never had to worry about that)
The easiest (and arguably cheapest) way to use ejabberd is to use ejabberd SaaS, managed by ProcessOne, developer of ejabberd (I am developer of ejabberd and founder of ProcessOne).
Related
What's the best practice for connecting to an SQL database from Vercel/Next.js serverless functions? I've seen a few options commonly mentioned:
Create a new direct database connection in the serverless function. This has important drawbacks:
Connection pooling: every new invocation of a serverless function would create its database connection, which could quickly overwhelm the database
Security: the database has to be publicly exposed since Vercel doesn't support static IPs or VPC peering. This unfortunately is deal-breaker for any security-sensitive application (fintech, healthcare, education, etc.) and SOC 2 compliance
Add an intermediary service that receives HTTP requests and proxies it to the database
My understanding is that this is a common thing people do? How does this work?
Use a vendor-specific solution, like the Prisma Data Proxy product (requires using the Prisma ORM) or AWS Aurora Data API (essentially an out-of-the-box version of the second option, now deprecated)
Trying to understand what the "best practice" solution to this problem is — have others deployed solutions they're satisfied with?
For personnel blog application should be okay to connect your edge function direct to database. Unless, this small website becomes super popular.
Eventually, For your application hosted on edge, another API endpoint is needed. It can be REST API or GraphQL does not matter. What matters is that, at the front this endpoint will accept loads of request from your edge functions (nodejs applications on vercel/netlify) and at the back, it will communicate with database, pool the connections and caching so on.
You can add nginx load balancer in front of that API endpoint to make it scale.
There are tons of options to engineer it
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 two App Engine apps that need to communicate with each other. I am not using modules.
I use HTTP url fetch to communicate between them. Do I need to make the requests HTTPS to ensure secure communication.
I seem to remember an article stating that all communication within Google's infrastructure is encrypted/secure by default, therefore making HTTPS redundant.
Can anyone confirm this as it would be good to save some valuable CPU clock cycles with zero effort?
(I know how to ensure the identity of each server using the HTTP Headers so identity is not a problem.)
The purpose of SSL is to keep some hacker from sniffing your requests/responses to steal valuable info, like your online identity. A call from one Google server to another should not be exposed to any sniffing. Thus, in my opinion, SSL between Google instances is unnecessary.
SSL is not necessary if you set the follow_redirects parameter to False when invoking fetch. This will ensure the call will not leave Google’s infrastructure. Please see Making requests to another App Engine app or Google service section of this document.
On the other hand using SSL will not increase instance's CPU clock cycles, but the request-response will take a bit more.
As I know the GAE does not support use the raw TCP/IP sockets, i.e. java.net.ServerSocket. Is there any other well known cloud service I can use it? E.g. Amazon EC2?
My client application needs the permanent TCP connection to the server...
Thanks a lot
STeN
Any IaaS provider will allow to do that. IaaS is Infrastracture as a Service, where Amazon EC2 is the most known one. In IaaS you can do all the same things that you could do with a dedicated server. The only difference is that it is using visualization and you can deploy and undeploy servers within minutes. You can find a number of IaaS providers at cloudorado.com .
GAE is PaaS - Platform as a Service. You don't play there with servers at all, you even don't know how many servers is your application using. You just put your app (like war) into the service and it hosts it. The platform will take care of scaling, distributing, etc. But there is an expense - you need to limit yourself, since the application needs to almost stateless (apart from session object). You cannot start your own services, db servers, start threads, etc.
EDIT: It appears now to be possible with GAE Managed VMs: https://cloud.google.com/appengine/docs/managed-vms/
sockets in GAE is a coming soon feature.
I read from here http://code.google.com/p/googleappengine/wiki/SdkForGoReleaseNotes
For now you need to sign up as a trusted tester to use this feature, but I guess this will be available to the public in the future.
How to use Java GAE with an external jabber server like Openfire? Any guide?
That depends on what you mean by "use with". If you want to send messages to an external server and receive messages from it, you can do that just fine by setting up federation the usual way. If you want some other form of interaction, you're out of luck - App Engine doesn't use XMPP as a client, but is instead tightly integrated with the server.