In other words, what part of Google Cloud Endpoints is not in the SDK?
I've seen several people saying that simply running their application elsewhere doesn't work. For exaple, see: https://groups.google.com/forum/#!searchin/appscale_community/endpoints/appscale_community/BFagV00RUcU/taaAoV5mxNEJ
What part of Google Cloud Endpoints is not in the SDK? Are there any initiatives going to try to implement that?
Endpoints has two components. The first is the SDK, and the second is the API proxy. In theory, both could work on other platforms, but the reality is that you would need to really understand the finer details of the interaction between the two to execute it. You could also in theory try to use the dev server servlets to run on other platforms. I make no guarantees about the robustness of either solution.
Related
I was surfing on internet for solutions and tools related to the API Layer and I find a company (maybe a startup) that is developing an ecosystem that allow to "virtualize the API Layer" (at the moment only in .net Core). It seems they allow to don't code the Api layer, don't write documentation of endpoints, don't writeE2E test (automatically inferred), change behaviour of endpoints at runtime and reuse the entire stack in another project. Do you think is it really possible something like this and useful in the world of API development? thanks
If I understand the question, your wondering about setting up an API layer with just the endpoints, but the endpoints have empty logic in them, right?
If so, then yes its possible to do this with a variety of tools. One tool I use is Postman, which allows you to setup a "skeleton" API you can call for design/testing purposes.
It allows standing up a mock server that hosts your skeleton API, in which any consumer can hook into.
I have an API that is hosted on GCP (no matter if its Compute Eninge, App Engine or any other) and I want to give access to it for selected applications that run outside of my company. I do not need such sophisticated service like Apigee (it is too expensive also), I just want to distinguish applications that call my API and do some individual restrictions for each (like which endpoint they can call).
As I have done some research I think that Cloud Endpoints + API Keys fits my requirements. I could create API Key for each client (API Key is sent in query, so I suppose I can get it in my backend?), but I am a bit confused if it is "the right/recommended" way. As stated here https://cloud.google.com/endpoints/docs/openapi/when-why-api-key#api_keys_provide_project_authorization it should help me to identify project, or rather for my case application, which is communicating with my API, but it feels like its more dedicated for apps that run within my organizations because it can have access to Google services Apis (like I should not give API Key to someone else outside, although I can even restrict IP addresess which can use it).
Would be glad to hear if someone had a smiliar goal and if solved it this way.
I don't know if my app will work in China and I don't know how to test it. I had read somewhere that there's a firebase Chinese domain .cn in operation. Is there a possibility to transfer the current project to the Chinese domain and make it work, if it doesn't already?
If I create a new project and select the Chinese servers for my firebase services then will it have any other adverse consequences for the rest of the world? This solution would literally force all the developers to have the firebase servers located in China, just so they don't miss out out on their Chinese user base, which I assume could be an issue to some.
I might not have the best ideas but any suggestion and a workaround would be appreciated.
There isn't a simple way to do that. Indeed, trying to set the servers there might a be way, but it's not a guarantee, since China Firewalls are constantly changing. You can try some onlines tools as this one here to verify if your domain is blocked, by adding the URL of your application.
Besides that, the best option is the one clarified in this other post here. You would create an API in Heroku and make the data and calls from Firebase go over this API, so it would make the connection. Another option you may try is using a proxy server - as very well explained in the article Firebase: Accessing Firestore and Firebase through a proxy server - so it gets complied and it's possible to be used in China.
The usage of VPN is not a very good option, as not of them work in China and the ones that work can easily vary, also, this could impact the usability, since it might affect performance and usage for the users there.
To summarize, there isn't a specific and fully correct answer to using Firestore in China, due to the fact that updates and changes on their rules are regular, but these are some alternatives that you can give it a try. It's more about trying the one that would be less damaging for your use case.
Let me know if the information helped you!
Might be helpful for someone...
There is a Firebase alternative for China - Huawei Mobile Services. It contains services like Auth Service, Cloud Functions, Cloud DB, Crash, Push Kit, Ad Kit, and many more...
Suppose we have a site on Google Firebase Hosting that routes some requests to a Google Cloud Run service. The service is considered entirely an implementation detail and its only client is the single website. The only reason for using a Cloud Run service is that it is the only suitable technical option within the Firebase platform.
Now, suppose that the API of the service may have a breaking change with every update, so the Firebase Hosting content must change too. How do you update or roll back both parts together so as to avoid incompatibilities?
Straightforwardly, we can update the service and the site content in separate steps, but that means some requests from the old revision of the site may reach the new revision of the service or the other way around, causing errors due to API mismatch. The same issues are present when rolling back the site content and the service at the same time.
One theoretical solution would be to deterministically route requests to different service revisions based on revision labels, but that is not supported on Cloud Run.
One realistic solution would be to create a new service for every update of the site content. However, that would result in unbounded accumulation of services which are not automatically deleted like service revisions are.
Another solution (proposed below) would be to maintain backwards compatibility in the service - it would support both the latest and the previous API version. However, this can be considered an unnecessary overhead. Since the two parts (static content and the service) have no real need to ever be updated independently, it would be very convenient to avoid the overhead of maintaining backwards compatibility in the service.
For what I know there is no way to make this update in a single transaction to avoid this behavior you mentioned as Firebase and Cloud Run are different products.
Also a good Practice in API design is to allow Service Evolution this means that updating the API shall not break the apps consuming it and new versions of the app shall be able to evolve in a way that they can consume the current API.
Something that is done when a new API will not allow retrocompatibility is to have different endpoints this is why some APIs are apiName/V1/method and apiName/v2/method but in this case both versions of the API are deployed.
What costs are involved with developing and/or releasing a Google Assistant App?
eg: Can you develop an app using DialogFlow and a backend (say Firebase) without having to pay while you learn?
First of all - you don't need to use Dialogflow or Firebase to develop your action. Both are suggested, but neither are required. You can use any NLP you want, or none at all if you use the Actions SDK (but you want an NLP). You can use any backend at all, including running it off your local machine and tunneling to it via ngrok, but you don't want to do that for production.
But, during development (and even during a light deployment before your action becomes massively popular and a stand-out hit), you have lots of solutions that will be free.
Dialogflow is free for use with the Google Assistant. Period. There is an Enterprise edition which offers additional services and support for a cost, but you won't need them. There are restrictions, but you won't bump into them until you hit 3 requests per second - which you shouldn't during development.
Firebase's free tier (the Spark Plan) is good for very simple experimentation, but once you start doing network calls to outside Google's network (if you are trying to call the network API for other services), you will be blocked. No worries! The "Blaze Plan" paid tier does require a way to bill you, but they don't start billing you until you get quite a bit of usage: 2 million function calls / month and similarly scaled usage of CPU, memory, and network. So even the "Blaze Plan" will be free during development (and for basic usage).
Updated, December 2020
Things have changed a bit since the original answer was posted, but the underlying basics remain true - there is no charge to develop for Actions on Google.
Dialogflow now has an "Essentials" edition and a more advanced "CX" edition. While you can still use both to build Actions, they're not really intended for this purpose anymore.
Instead, Google has included the Actions Builder into the Actions Console to handle the NLP work. The Actions SDK works with this, but can also just pass along all the STT information to your webhook. Both are also free to use.
Dialogflow is for free if you don't use it as an enterprise:
https://dialogflow.com/pricing/
And Firebase free tier should be enough if you not using firebase
already for other projects. enter link description here
But of course you have to calculate your own time so in case of the
spent time probably not.
For everything else yes it is, as long as you not using it already somewhere. You can for development also host your server local and use an ngrok tunnel as sever address for Dialogflow.
As an addition to shortQuestion's answer:
The free plan in Firebase should be enough if you're just using it for learning and developing apps for personal use. If you want to go a bit further you'll need to upgrade the plan.
You can sign up with a free trial for actions on Google to get 300$ of credits during a 12 month period which would be more than enough to do anything you want.
The costs of Firebase/Actions on Google on a higher plan aren't anything to worry about though, you'd be talking about a few cent per multiple hundred thousand requests.