I'm thinking of using the Google Endpoint service to add some simple features on my Android app. Following a tutorial on Github (https://github.com/GoogleCloudPlatform/gradle-appengine-templates/tree/master/HelloWorld) I managed to create a very simple servlet with basic code and that's all I need. But it's not clear if I'll have to pay at some point (30 days free trial?) or if I only have to pay to access to the whole platform.. Is a simple servlet on Google Endpoints completely free without restrictions?
It depends on where you are hosting your servlet. If it e.g. meets the constraints for Google App Engine's free quota you won't have to pay (as far as I know). I am in fact running such an application since quite a while now.
Related
There is a warning on the Firebase best practices documentation against using Firebase with multi-tenant applications: https://firebase.google.com/docs/projects/learn-more#multi-tenancy
This is what I am most concerned about: "Multi-tenancy can lead to serious configuration and data privacy concerns problems, including unintended issues with analytics aggregation, shared authentication, overly-complex database structures, and difficulties with security rules."
There is also plenty of official Google documentation supporting the use of Firebase for multi-tenancy, for instance: https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication .
Do you know why they would have these conflicting recommendations and examples? Does use of Google Identity Platform fix the core security deficits mentioned in the warning?
I am re-posting this question, with additional clarification in the title, and a few edits/removals from the body, to specify that I am only looking for why this widely used product has this particular warning in its official documentation. I have removed most subjective content. I have no opinion on this that is relevant to the question - I am only looking to understand the warning. It seemed there was one good answer before the previous question was closed, so I will link that here for reference: Why is Google Firebase not recommended by Google in their own documentation for multi-tenant applications?
That does make sense if you manage 2 separate applications which have no relation with each other. Let's say you have an app that manages a school's information and other one is a restaurant management app. Now in this case I don't see any event that the school app might need access to restaurant data.
If you use the same project, then all the firebase services (auth, database, analytics, etc) will be shared among them. It'll be hard for you to separate analytics for each of the app. As the database is shared, you'll have to explicitly separate data of both apps by separating the path in db. (/apps/school for school, /apps/restaurant for restaurant).
That being said, any user registered on the school app can login on restaurant app without creating a new account there as you are sharing the same project among them.
Now if your client pays you a the Firebase costs every month, you cannot distinguish between how much should the school client pay. Now even if both the apps are your, the complexity will increase significantly if you go on using it.
https://firebase.google.com/docs/projects/learn-more#multi-tenancy <-- this explains how "Firebase Projects" works and https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication explains about "Google Identity Kit" multi-tenant auth. So that's not a Firebase-only thing.
I'd like to get access to the API Testing console (the one mentioned in the Quick start of the Cognitive services translation services, useful to test the API without writing a single line of code), but I don't find any direct access to on the Microsoft Azure. Thanks in advance for your help.
I think the text you mention about the console is a copy-paste error from other cognitive services quick start page.
Generally with Cognitive Services, you can find webpages which seems to be hosted under Azure API Management, where you got the basic documentation and access to a testing Console. For example for West Europe, all the services are here: https://westeurope.dev.cognitive.microsoft.com/docs/services/
And for Anomaly Detector API, you can see the link to the testing console:
Sadly, it seems that there is not equivalent for Translator API.
You still have samples on Github that you can use, in several dev languages: https://github.com/MicrosoftTranslator
Or you can directly call the API with a tool like Postman, it is really easy to implement
I am evaluating wep api gateway for my new projects. I used azure api gateway in the past. Reading about nginx as it is new and adopted by many. Can someone help me point out with some facts, pros, cons? Bug matrix will be a best help for me
Azure API Management is a mature and widely-used product, with many customers being very respected enterprises. Take a look at some public case studies.
It offers a very wide range of features, which are typical of an API management platform, and it is still being very actively developed. However, one of its biggest strengths lies in integration with Microsoft Azure services and features - multiregional deployments, virtual networks, monitoring and alerting solutions, native support for Service Fabric, Azure Function Apps and Azure Logic Apps, Azure Active Directory and others.
If you are considering hosting your new projects with Microsoft Azure, Azure API Management is a no-brainier.
The product is also one of the main reasons why Gartner named Microsoft a leader in the enterprise integration space.
Disclaimer: Although all of the above is best to my knowledge, I am affiliated with Azure API Management.
Although I have just started looking into this myself, here's what I can already conclude.
Looking at www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/, Nginx requires a lot of manual configuration washed over many text files. That doesn't look flexible or effective, but I may have gotten a wrong impression.
Judging by how you're supposed to define your API keys using the map directive, Nginx API Gateway also looks like a new idea stretched on top of the existing product, while Azure API was designed for that exact purpose from the ground up.
Azure APIs, when published, come with auto-generated documentation and an interactive console that are in sync with all your updates.
With Azure API, you're putting all your eggs into one basket and completely depending on it's pricing and availability. At any moment Microsoft can increase their prices, or discontinue the product, and you cannot migrate elsewhere, at least not easily/quickly. At the same time, you can do your Nginx work once and run it on pretty much any server, starting with a low-end VPS or a Raspberry PI, if you'd like. It's pretty much yours.
I want to write a google cloud function that will respond to POST requests. I want to write it in Javascript.
I've found Google's tutorial on how to do it, but at the beginning of the tutorial it says that this is a deprecated thing, and I have to do it using Cloud Endpoints Frameworks for App Engine. However, the link they provide doesn't help.
Any ideas on how to write a javascript google cloud function?
Link to the tutorial that I've found:
https://cloud.google.com/endpoints/docs/frameworks/legacy/v1/python/getstarted/clients/js/add_javascript
The warning that's displayed at the beginning of the tutorial:
Cloud Endpoints Frameworks v1 has been deprecated and will be shut
down on August 2, 2018. We recommend that you use the latest version
of this feature, which is renamed to Cloud Endpoints Frameworks for
App Engine. This new version supports App Engine standard environment,
provides lower latency, and has better integration with App Engine.
For more details, see Migrating to 2.0.
The migration link points to https://cloud.google.com/endpoints/docs/frameworks/legacy/v1/python/migrating
There are two completely different things you're talking about here.
Google Cloud Functions is a serverless way to write functions in Javascript which respond to HTTP requests.
Google Cloud Endpoints Frameworks for App Engine is a way to write App Engine applications in Python or Java which respond to HTTP requests.
The first link you provide is about writing browser-side JavaScript code which calls an Endpoints service. The corresponding link for the Endpoints 2.0 product is here.
Depending on what you actually want to do, you should consult one or more of these links.
Do you know if it's possible to build an application for the LinkedIn platform?
Yes, they have API at http://developer.linkedin.com/index.jspa, allowing access to the profile, connections, messaging and more.
While LinkedIn has promised a public API for a very long time now, they have yet to deliver.
No, there is no public LinkedIn API yet.
IMO, their widgets (which there are only two of at the moment, which are very limited) don't count.
They say that they are open to being contacted with specific uses for their API and they may give access to parts as needed - but that is if they accept your ideas for integration. They have been very picky with this - and have not accepted my attempts to integrate with LinkedIn yet, they tell me I have to wait with everyone else, apparently my applications are not "high-profile" enough.
Sure, you'll find many Google results talking about their "promised" API, but they are empty promises and won't be of much help.
Yes, Linkedin has an API:
http://www.programmableweb.com/api/linkedin
http://blog.linkedin.com/blog/2007/12/the-intelligent.html
So you could build an application that uses it.
Update: (from second link)
We’ll be phasing all of this in over the coming months and to get involved with the Intelligent Application Platform either for APIs, widgets, or hosted applications, send us an e-mail to developers#linkedin.com telling us what you want to build and what you need to build it.
Since there are published Mashups using LinkedIn I would assume that means you can use the API even if the documentation isn't readily available.
As a tip, in the future include links to what you found that didn't work, so we know not to give it to you again.
I poked around a bit more and I found some more on their widgets which appears to be the main focus of their API.