Let me take an example, I wanted to use Google Places API in my app. But due to usage limit it only allows me to use 1000/day requests for one key. So what I did was created multiple keys from different gmail accounts. I am using these multiple keys in one app. Is it allowed to use commercially?
Google already mentions that on the documents
You can use one Developers Console project to manage all of your work, or you can create multiple projects, depending on your development and collaboration needs. Consider whether you're collaborating with a different set of people, want to track usage differently, or need to set different traffic controls for different parts of your work. If so, breaking up your work into multiple projects might make sense. That said, you cannot use multiple projects to try to exceed API usage limits.
From :Google Docs : Creating and shutting down projects
So you cant use it multiple key for project its better to use the commercial package offer by google.
Try use the Google Place for web, it haven't requests limit. I think you are developing for android, so
use this tutorial: http://wptrafficanalyzer.in/blog/showing-nearby-places-and-place-details-using-google-places-api-and-google-maps-android-api-v2/
Related
I work with a large university and we track hundreds of subdomains and we also have a few apps. I'm looking for the best solution as we migrate to GA4. (I know, should have been done long ago.) We currently have 20+ Properties which all contain up to 25 Views, each configured to track individual subdomains or apps and we grant user access to these individual Views.
With GA4, Views are deprecated. I'm wondering if anyone has dealt with this type of challenge and how they split up subdomains. We need to keep one account (if possible) and a general plan of action for breaking up all these domains so we can streamline the Analytics data for our end-users.
We do use Google Tag Manager as well.
So far, we have one "main" GA4 property with a single datastream for the root web. The app side is not configured. We also have about 3 other properties setup for individual big players (i.e. colleges or departments which we know will need lots of customizations).
I'm wondering if we should make more properties with multiple "web" datastreams for the many subdomains, but then, how might this affect user engagement with this new Analytics model. Should we handle this in a completely different way.
You don't make properties for stakeholders. You make properties for tracked activity types. Duplicating the tracking is not a good solution.
You don't have the views, but you have the hostname dimension which you can use to filter reports. Feel free to make hostname-based segments and teach your stakeholders use them.
Finally, native app tracking is done through Firebase. Firebase can then be linked to GA4 as its own stream. Better to keep in the same property you keep the web data.
The general rule is: Don't make additional properties unless you know what you're doing. Additional properties will increase complexity on both ends: the collection and the post-processing of data. Increasing complexity needlessly is just pure incompetence that will make many people frown upon it when they inherit your design.
I got a project assigned where we already have an up and running website and one of our clients wants to be able to track statistics from the website.
We want to make this available to all our clients as soon as we finish the development. Note that each 'client' have their own 'subdomain' to say so. Eg. www.website.com/client1 , www.website.com/client2 , etc. And we want to track the usage separately for each of these clients.
We will need to create statistics based on the usage of our own platform, pull in data registered by Google Analytics and also pull in data from a 3rd party which they will offer by an API of their own (they have a 3rd party solution that uses the data accessible via our API).
All this data needs to be shown on a webpage with graphs and tables.
I wanted to make sure we choose the right architecture from the start, in order to avoid scalability issues later on.
Started reading about Private and Public API's lately.
For now, we do not have another (internal) application yet that would use our own statisics, it would just be the website using it. But in order to be able to scale-up later if needed, and another application would like to use the statistics I think a private API would benefit us greatly.
In order to allow 3rd parties to use the statistical data we chose to let out, I was thinking of creating a Public API.
Is a Private&Public API the correct way to go about this?
One of the questions I am stuck with is how does the architecture for these API's look like. Mostly, right now we already have a public API regarding vacancy data. This 'API' is basically just a PHP class (controller) inside our CodeIgniter solution. It gets called via its URL and returns a JSON object with the results. (e.g. www.website.com/api/vacancy/xxx)
In order to create a (proper) private & public API solution/architecture. Should the API be set free from the website (CodeIgniter)? What are the common go-to solutions for this?
Or is it fine to keep it in our current platform the way it is now? (and people call the stats API via www.website.com/api/stats/xxx for example?)
It's almost always right to go with microservices like architecture so your initial thoughts sounds reasonable. Acting like this will give the possibility to scale and deploy your api independently and also will help you avoid performance side effects to your site (and vice versa). Pay attention how you access your main site data from within the new api if you don't want to finish with a monolith application.
Regarding the API i would suggest you to implement protocol like oauth2 in order to achieve the flexibility you (might) need. Also you can use swagger to document and test your API.
All i said might helps you a lot but first you have to answer yourself do you really need to go so deep or you just need a simple solution.
I think multitenancy is the best choice. Generally speaking, multitenancy is when every customer has own database. Data is separate. The codebase is same and already exists. As I understood the project is in progress status. You do not redesign and rewrite anything.
I am looking to develop a cross platform mobile app involving real-estate. I have looked at Zillow's API and I think that will be one of the API's I utilize.
https://www.zillow.com/howto/api/APIOverview.htm
My question is if I were to utilize their API as well as those of some other real estate sites, would it make more sense for me to call those APIs directly from the mobile applications, or would it make more sense to have a proxy server, possibly with my own databases compiled from these sites, that the mobile application would call? I have only read the basic overview of the Zillow API, but it looks like it is limited to 1000 calls per day. I understand it is a fairly general questions. If there are any more details that would help to make a better answer, please let me know.
Also, if you know of any other free/cheap real-estate APIs, can you please provide them?
Thanks
Not exactly sure what your metrics are.
But generally speaking, it is a bad idea to hook your mobile app directly to third party API for the following reasons:
You do not control the API, if the third party changed their API your app won't work, the user would have to upgrade. But if you isolate the mobile app by connecting to your server you have more control and can have much longer life.
Caching/rate limits. You can get the data from the third party and store it (if you are allowed) then share the data with all your users
Multiple datasources: Usually you get the data from multiple datasources, so aggregating the data on your server then send the enhanced data model to the app is a lot easier than pulling data from different sources and compiling them on the app itself.
Our Team is trying to build multiple Windows 8 Store Apps for an enterprise.
How do we maintain a common session for all apps(where we store data which need to be shared)?
How do we enable direct interaction between the apps developed i.e. sharing objects or string(JSON) among the apps?
There is not built in way to do this. Realistically you probably have three options to share data between applications.
The first is to use the cloud / web services. This makes the most sense as you'd have full control about what is shared, authentication etc. Using libraries such as SignalR could let you add real time functionality between the applications as well as multiple users.
The Share contract, by using custom data formats you could enable the apps to share specialised data between each of them. This can make sense if the user has a set of data they want to send to another application to enable a quick piece of workflow as the Share target is only partially launched. This also is limited in that it's enabled by user action.
Custom protocol handlers, by giving each app it's only protocol my-custom-app:///some-action?param1=value etc then you can pass data between apps, note this launches the app in question when you launch that uri. This would be best for more longer running scenarios.
I'd suggest a combination of all three depending on the user action. Cloud services to store the data for the user and then a mixture of Share and Protocol to enable to the user to smartly move the apps seamlessly.
Here exactly the same question as yours. In short: there is no such ability. Sometimes I think that it will be easier to share data via Internet that in device.
I am working on a system using php/mysql where I am allowing users to subscribe monthly to various, small browser based web apps. Each app will have different subscription terms and plans. The apps are all currently built and they reside within the same framework.
I am in the modeling phase so I am looking to make this system as flexible as possible wheren the terms from one plan to the next will vary. Any thoughts on how to elegantly model this?
Rather than building this yourself you could look into using something like Zuora.com. Please note that I haven't used these guys or have any affiliation, I just remember reading something about services like this starting to emerge for web-app publishers needing a simple billing/metering solution.
Of course, you also need to consider which payment gateways you support, but I think that Zuora does that behind the scenes.