The documentation at https://developers.google.com/actions/deploy/release-environments states "To handle release channels in your fulfillment, you should provide different fulfillment URLs (for example, one fulfillment URL for the beta and another URL for the production version of your Action)." However, there are no instructions on how this should be accomplished.
When I created my Actions on Google project, a Firebase project was created to which I upload JavaScript that supports those actions via requests to our backend service. That Firebase project provides the URL used by my Beta release for fulfillment. I now need to create an Alpha project that points to a different Firebase project to which I will upload new versions of support for requests to different versions of our backend service. I do not see a way to accomplish this. Do I need to create an entirely new Actions on Google project that has its own URL for fulfillment or is there some better way to accomplish this task?
I tried creating manually creating a separate Firebase project to host the Alpha code but that did not work. I later learned that when you create a Actions on Google project that it is intimately connected to the Firebase project created for it and cannot be pointed to another.
The problem is all in the configuration space of Actions on Google and Firebase. There is no code to show.
I would expect that some approach similar to that provided by the Alexa Developer Console and the Amazon Lambda Management Console would be available. In that approach, I have Alpha, Beta, and Production versions of the Alexa Skill and each of them points to a different version of the lambda function each of which has an appropriate value to indicate the environment that the lambda function is executing upon. This allows me to allocate requests to the correct backend service (alpha, beta, production).
I don't see a way to accomplish that in the Actions on Google/Firebase world.
If you are using Dialogflow, the Actions on Google release levels have corresponding environments. So you should be able to set a different fulfillment URL for each environment to point at the different project.
Related
I first created a Google API project on Google developer console and configured a OAuth 2.0 client IDs as credentials in order to let my C# projects to access the Google Drive.
However, I'm new to developing with Google APIs I am not able to understand when i should create new credentials or projects.
Should I create multiple credentials (maybe one credentials for one project?) or actually it's fine to use the same credential for multiple projects? What's the purpose to create more than one credential?
If you are creating different applications then you should create different projects on google developer console each with their own set of credentials.
The reason for this is to ensure that you dont run into any issues with quota. It also allows Google to track who is using their data and how much.
You should also consider when you define your project and create credentials you are giving it an name. When a user authenticates your application they are granting access to Super app one to use their data if you use this client with Super app two then they wont know who has access to their data.
My personal rules
Each application is a project on Google developer console.
in that project i create a client id for local, test, and production environments.
Update from comment about project creation quota
My current project quota
You have 37 projects remaining in your quota. Learn more.
You can always request additional projects do it early from what i remember it took a week or so to get them. Project quota requests
Update usage to create multiple credentials for same project then
Like i mentioned before if you use the same project for credentials on different projects you are miss leading your users. The fields i have marked with arrows denote an APPLICATION they are specific to the application requesting access. They are part of the project itself. All of the clients created under that project are going to use the same consent screen. If you use it for two different applications you are IMO miss leading the users in what application they are granting access to their data.
You may also be miss leading Google as i believe the TOS requires one project per application making a request hence the consent screen having application name and link to the application contacts. However i think i need to read though the TOS doc again to make sure this is a requirement.
You are also more likely to hit quota limits. A lot of the limits are project based not credential based so if you have two applications reading from the same api with two different credentials created under the same project. You are going to hit the quota a lot faster than if you had created each application its own project.
Example: Google Analytics example max project request 50000 per day.
Same project
Application one requests 20000
Application two requests 30000
both application one and application two are now blocked from making requests for the rest of the day as they have in totally hit 50000 requests.
Two separate projects
Application one makes 30000 requests
Application two makes 50000 requests.
Application two is now blocked for the rest of the day as it made 50000 requests. Application one continues to work until it has also hit 50000 requests.
Im new to iOS and new to SWIFT with no previous experience with Obj-C. But, Im not new to Ruby. I have a web based app on heroku and am beginning to learn SWIFT so I can build an iOS counterpart. I need to wrap my head around the bigger picture before I can get started and I can not figure out how these apps connect to databases.
Can an iOS app connect to an S3 database...and share that database with a website? Is there documentation on this process that I have over looked.
Connecting an iOS app to a public database would really be a bad idea - all server logic should be implemented on the client, and you would also need to hardcode database user name and password in your app.
A better way is to create a server app exposing a set of REST APIs and being responsible of dealing with the database. This way you can better control at server side what the app client is able to do on the database.
If you have an order entry app, for instance, you can create APIs to:
login
register
create an order
modify an order
add a contact
delete a contact
etc...
Some of the advantages are that:
in case you need to update the logic (but not the API interface), you just need to update the server, whereas in your scenario you'd need to release a new version of the mobile app
you control and limit how client apps access to the data (preventing for instance a user to access another user's orders)
if you want to develop the same app in another platform (android, ...), you reuse the same APIs
To get started, I'd suggest you to read the AFNetworking tutorial on raywenderlch.com, focused on a ios networking library, but talking about JSON, REST, remote APIs etc.
Next you have to choose a server side technology - the most popular nowadays is node.js - to get started you can read other tutorials on the same website:
http://www.raywenderlich.com/61078/write-simple-node-jsmongodb-web-service-ios-app
http://www.raywenderlich.com/61264/write-ios-app-uses-node-jsmongodb-web-service
if you don't want to use node.js and/or mongodb... the same architecture applies, just languages and technologies differ. Just transpose what you learn from there.
If you want to read about other languages to use at server side, just google for it - if you want to use ruby, try with ios rest api server ruby.
Note: I made no mention of swift because your question looks more like an architectural problem than a language specific problem. The tutorials I mentioned here use objective-c, once you've designed an architecture and chosen the language at server side, you can start looking into how to call REST API from swift.
I'm trying to create a redistributable web application that will integrate with Google Analytics through the Google Reporting API. Customer will install the application on their server.
I'm following this tutorial (I'm using PHP, but I believe this is not of importance for my question)
https://developers.google.com/analytics/resources/tutorials/hello-analytics-api
This works fine. No issues there.
However I can't figure out one missing element:
The tutorial starts with sending me to the Google APIs console where I have to create and configure a new API project and create and configure a client ID.
That's a lot of work that requires fairly technical knowledge (redirect url, selecting correct API, error-prone copy-and-pasting, etc.)
So my questions:
Is there an API so I can programmatically set this up for my user?
If that's not possible, is there a more user-friendly way to obtain Analytics reporting that is future-proof? (I noticed they are currently deprecating a few older APIs)
Unfortunately that's AFAIK not possible.
You could go one of the following ways:
Move client_id and client_secret to some configuration file and help your customer with deployment.
Show a one-time setup wizard for your app and guide your customer step-by-step. There you can at least provide him with the right callback URLs.
Regard your application as "installed application" and instrument curl or something similar for sending the requests.
I'm working on an appengine app which uses OAuth. Naturally, I'm dealing with multiple versions of the app simultaneously - a local version for development, a staging version and a deployment version.
To work with these, I need three separate sets of OAuth consumer keys/secrets as the callback on authentication is defined on the provider's site.
I was wondering if there are ways for providers to provide multiple keys/secrets for a given app - this would seem to make more sense than setting up a new app each time. (Of course, it requires the provider to implement this, but it seems a natural thing to implement and I haven't seen it).
More generally, what standard approaches are used to deal with this - my guess is register multiple apps and have logic in the app to determine if it's in development mode, staging or deployment. Any thoughts welcome.
I find this to be one of the most annoying parts of being an OAuth API client developer. There is no reason why providers should not allow developers to register redirection (callback) URIs for testing.
The standard approach I've seen is to allow you to whitelist one or more domains for callback / redirection. Facebook has some crazy setup where they let you "register" multiple domains by using different domains for the various links in the application profile. I did not have much luck with that. Twitter is one of the better implementation for that, letting you register multiple domains.
In OAuth 2.0 (draft 18 or newer), this topic gets much better treatment. Registration of the full URI is recommended, with the ability to register multiple callbacks and select the one you want to you dynamically at request time.
The main aspect to consider is how you want to handle permissions with a staging setup? Do you want to be able to reuse existing approvals or want to keep those separate? Also, if the API provides special client-only calls (such as client storage or management tools), do you want the stage version to share it or keep its own (so that testing will not mess up production).
At the end, providers should provide a complete development environment and that includes testing facilities for API clients. Most don't.
From an API provider's perspective your app is simply an app using the APIs. Usually there is no such thing as a "staging" API, which does not deal with live production data. Whatever it is you are testing, you are testing it on live data right?
If you are able to register several different applications with for example different callbacks then I think your problem is pretty much solved. My view is that it should be the consumer's responsibility to keep these things separated.
I have a Rails application that right now is pretty standard: Heroku/PostgreSQL backend, users go directly to my site to update data, there's no mobile app or anything. We're going to start licensing out the tech to other companies, so that different versions of the interface live on company1.mywebsite.com, company2.mywebsite.com, etc, where all of these interfaces share the same database.
I want some advice on how to go about building this. Do I create a separate Rails app for company1, company2, etc (with a lot of redundant code) and then set up each of them with API keys to query my master app, using its RESTful routes?
Any tutorials to point me to would be great as well.
I recommend you the book Service Oriented Design with Ruby and Rails, by Paul Dix. It has a lot of info about the kind of system that you want to build.
To answer your question:
Build an API server. It serves a JSON – for example – RESTful interface.
api.mydomain/client1/users.json
Build a frontend server. It consume the API service – using typhoeus for example – and serves the final pages. It uses a subdomain or domain name for identification of different clients.
client1.mydomain/users
We have a similar "platform".
What we did:
build a master API app (REST + Push)
build a core plugin for rails which has all the shared code
build a separate rails app for each client which has all the client specific code
We are using this setup for 3 years now and I'm pretty happy with it.