i want to know that can i use shared hosting service for push notification or i need some another? which one is best for push notification please tell me.
It depends on the capabilities allowed by the shared hosting service.
You will need a site that allows you to run code (perl, python, ruby, php, etc) and database access will probably be needed for most applications. I have notifications working on a shared hosting site that I have shell access to and can run scripts along with SQLite and MySQL. I pay $25/mo for my service.
Related
Background:
I'm building an API service app. The app is just like any other, you send an HTTP request and receive a response. This seems simple up until I start thinking about user registration, payments, authentication, logging and so on.
Application:
tl;dr simple app diagram
Endpoints listening for HTTP requests and doing all the request related work. This is the core of the service, what the service user would use this app for. Directly not accessible to the end user (unless somehow it knows the url). Python flask server, deployed on google cloud RUN.
API gateway acting like a proxy and a single access point forwarding the requests to the endpoints. This is the service access point for the end users. This part will also be responsible for authentication, limitations, logging and tracking the use of the API endpoints. Python flask server, deployed on google cloud RUN.
Website including documentation, demo and show off of API calls through API gateway, registration, payment (thinking of Stripe) etc. VueJS app on NodeJS server on google cloud compute VM.
Database storing credentials of registered users, payment information and auth keys. Not implemented yet.
Problems:
Is this architecture proper? What could be done differently or improved? How could I further simplify all the interactions between separate parts of the app? Am I not missing any essential parts?
Haven't yet implemented the database part and I'm not sure what should I
use? There are plenty of options on google cloud. Also I could go with something simple and just install a DB with http/JSON interface on google cloud compute VM. How do I chose the DB? Given such an app, what would be the best choice?
Please recommend literature/blogs/other sources of info on similar app
architecture for new developers not familiar with it?
This is pretty open ended, but here are some general comments:
Think about how your UI will work. Are you setting up a static app served directly from cloud storage or do you need something rendered on the server? Personally I prefer separating UI from API when I can but you need to be aware of things like search engine optimization. Even if you need to render some content dynamically your site can still be static. Take a look at static site generators like Gatsby. I haven't had to implement a server rendered UI in years and that makes me happy.
API gateway might be fine, but you don't really need it for anything. It might be simpler to start without it and concentrate on what actually matters. If your APIs are being called by an external client you can't trust the calls anyways and any API key you might be using will be exposed. I'd say don't worry about it for a single app. That being said, if you definitely want to use a GW then use one, just be aware that it is mostly a glorified proxy and not some core part of your architecture.
Make sure your API implementations don't store any local state so you can rely on Cloud Run scaling your services up and down. Definitely don't ever store state directly inside your containers. If you need state on the server it needs to be in some external data store.
Use JWTs or an external IDM (that will generate JWTs) for authentication. Keep session data on the client side as much as possible and pass the JWT in every API call to authenticate the caller. If you are implementing login on your own the only APIs you need to expose without tokens are for auth and password recovery, which you can separate into their own service.
Database selection depends on how well you understand your processes, how transactional your services are and your existing skillset. Overall I would use what you are comfortable with, you can probably succeed with a lot of things. Certain NoSQL flavors can seem simple on the surface but if you don't have a clear understanding on the types of queries you need to run they can get tedious to work with. Generally you should stick to relational databases for OLAP style implementations and consider NoSQL for OLTP. Personally I like MongoDB and it is very popular, probably because it sort of sits in the middle of the pack which makes it fit a lot of applications. Using MongoDB also makes you cloud agnostic since it is available on every platform. Using platform specific database flavors can lock you down to a specific vendor.
Whatever you do, don't start installing things on VMs. You can be almost 100% sure you are doing it wrong if this comes up. Remember, the services you consume don't all have to be managed by Google or even run on GCP. You can get MongoDB capacity directly from MongoDB who manage it on your behalf on all of the Big3 cloud vendors.
At least think about the long term, even if you don't necessarily need to have it impact your architecture right now. If you are expecting your app to be up for years try to make it more platform agnostic than less. This might mean sticking away from some really platform specific serverless features that will force you to jump a couple of extra hoops. If you are using Cloud Run you are using containers which already makes your app pretty portable, don't lock it to one platform by using a lot of platform specific features. That being said, don't stay away from them either. You should always go for the low hanging fruit, so don't try to avoid using things like secrets manager etc. If your app has a short lifespan and you need really fast time to market then don't worry about it.
Just my 2c, what you are doing is very generic and can be done in a lot of different ways.
I am interested in learning to use the Smartsheets API. In the past I created workflows in Google Apps Script, which has a built in IDE that houses the script. Does Smartsheets have something similar? If not, where is a common place to keep your code and have it react to webhooks/events?
Regards,
Shawn
The API is just a way to communicate between your application and Smartsheet - there is no hosting for your executable code. Smartsheet provides a number of SDKs to help make the calls easier to perform, but in theory you could use any language to make the REST commands. So, pretty much any service that allows executable code would work, such as Amazon AWS, Google Cloud, Microsoft Azure, or others. Here's a brief comparison of services.
You can start developing on your own computer before you worry about cloud deployment. See the getting started guide and samples here: https://github.com/smartsheet-platform/getting-started
If you really need to respond to webhooks, your code will have to run somewhere that accepts incoming HTTP calls from the Internet without being blocked by a firewall. This could be in your data center, any of cloud services, or via a tunnel such as https://ngrok.com/
I'm writing a mobile application, and this mobile application will be talking to a server in Azure to get data, and possibly push some too.
Now, I always had it in mind that I was going to write a simple RESTful web service that was going to deal with all this, and host it on Azure in a website - however, I've since discovered their Mobile Services, and I'm not entirely sure I understand what it's for.
Looking at it, it seems that it's about extracting away the code running on the server from you, and what you push to it, is what you get back? So it wouldn't be much use for me, as my web service is going to be returning data dependant on logic etc. However the ability for the Mobile Services to deal with push notifications directly is nice (how hard is it to use Azure Websites to send push notifications through mobile services?)
However, I wonder if I'm missing something? I'd rather not have to go re-invent the wheel as such, is Mobile Services will do what I need, especially as I'll be using Xamarin and there is a nice component to talk to Mobile Services...
Thanks
I am facing the same question: Should I use Azure Mobile Services or roll my own REST service. Below are some discoveries I have made so far.
With Azure Mobile Services there is a backend running a set of assemblies, which your code ultimately depends on. This is fine until you start using versions of other assemblies, which are not compatible with the versions Microsoft hosts. To me this is a major pain. This problem alone makes me question whether I want to use Azure Mobile Services. If you make your own REST service, I do not expect you to face these problems. See this link for details.
You should note that an Azure Mobile Services is tied to a single Azure region: If your Azure region fails, you need to manually migrate to another Azure region. This might not be a problem for your project. If you want to run in more than one region, I think it will be easier to roll your own REST service.
Regarding push notification, you could do that without using Mobile Service. See these links:
http://msdn.microsoft.com/library/azure/jj927170.aspx
http://weblogs.asp.net/scottgu/broadcast-push-notifications-to-millions-of-mobile-devices-using-windows-azure-notification-hubs
Auto-scaling is supported out-of-the-box in Azure Mobile Services. You would need to make your own scaling logic if you make your own REST service. You can scale VMs using Azure’s REST API, but it will be more work than using Mobile Services.
Authentication is supported in Azure Mobile Services. You would need to look into a separate framework to do this if you make your own REST service.
If you use Mobile Services you will probably create ASP.NET Web APIs through the Visual Studio wizards. There are examples and tutorials, which is great. However, even if you roll your own service, you could build on other frameworks. One example is ServiceStack, which I would strongly consider if you want to make your own REST service. I think ServiceStack could also help with authentication.
If you use Mobile Services you will tie yourself stronger to Azure. By rolling your own REST service it will probably be easier to move to another infrastructure later.
I would like to be able to have my login work in development mode (localhost:3000) as well as on the production server, and ideally, on a staging server.
Apparently you can only configure one domain for login, unlike Google apps, which is much smarter.
Maybe I could rig up my hosts file to do something spiffy with a subdomain?
Under Basic Info: App Domains, you can put in your domain. It will handle all subdomains if you just put in the main domain name: '<yourdomain>.com' So it will definitely be able to handle your dev.yourdomain.com, qa.yourdomain.com, staging.yourdomain.com, etc.
As for your local development, that's where it gets tricky. You can't use multiple domains, as you've noted. You can definitely try to follow this answer: https://stackoverflow.com/a/7493806/183880 which involves creating a second Facebook app and configuring the domain to localhost.
I'm not sure if anyone else has solved it yet, but I came across the problem where if you are trying to develop Open Graph actions and objects, it's pretty much difficult if not impossible to develop those locally. This is because the Facebook servers need to be able to access the Open Graph object urls. And in this case since you'll be developing locally, they can't access http://localhost:3000/my-object-url. Somehow you need to be able to expose your local environment to the external world. More trouble than it's worth, in my opinon. My only work around is to just deploy to a development server http://dev.yourdomain.com and test from there.
I need a webbased group chat client that can interact with various xmpp servers.
I did some research and found muckl , speeqe and tigase minichat but I have one more issue I am deploying my site on shared hosting.
So want to know if anybody has installed any group chat software on shared hosting ( like bluehost ) and which will be the best possible client for the same.
Speeqe is actually 99% javascript, so it will work well on shared hosting. The requirement for Django is just to do things like remember sessions and have nice url structure. It may take a small amount of work to take away Django, but it shouldn't be much.
There are also Django hosting providers, so that might be an option.
Speeqe can also work with any XMPP server, public or self-hosted, etc. I used it many times to join groupchat rooms on arbitrary servers, and there is even an IRC gateway.
For XMPP shared hosting, there are several options now, including a service by Process One: http://process-one.net