Geolocation via an API

Perfect, that made 100% sense, thank you for that.

1 Like

CORS allows web scripts to interact more openly with content outside of the original domain, leading to better integration between web services

2 Likes

sorry for my bad english :)))

1 Like

Well I have tried everything i can think of on my side to connect to their secondary API service and can not get around that error.
What i do find strange and what leads me to believe that this is not on my side but the API developers side possibly is this.

This is the working one, note in the header how there is an entry for access-control-allow-origin

While on the second service the headers have no mention of this

And I get this error message
Access to XMLHttpRequest at 'http://www.geoplugin.net/extras/nearby.gp?format=json' from origin 'http://africacollectionbs4.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Am I correct that this could be something on the API Providers side and not my side possibly.

You can’t access that service with XMLHttpRequest, they didn’t add the Control-Allow-Origin header. It is not you that has to add the header, the service has to add it. You could try to contact them about that.

An other solution is wait for us to finish the Server Connect version and connect with that, on the server side you don’t have the problem with CORS.

3 Likes

Thanks so much for confirmation @Patrick, i contacted them and they added something and now it is all working, so happy days.

Thanks again to all that tried to help with this one.

1 Like

Seems they added the required CORS header, I think a lot of people will be happy.

2 Likes

TOKEN missing. Created a yelp account and have my api key. Just can figure out how I will use it when making a request. It can’t go as a url parameter

I did take a look in the yelp documentation, you need to add an header Authorization with a value Bearer <YOUR API KEY>.

check https://www.yelp.com/developers/documentation/v3/authentication

But I think you should not use the API key on the client-side

1 Like

Thank you very much for your time and interest @patrick

I will check it out and let you know

After contacting the developer they have suggested interest in possibly getting Wappler themselves for the front end redesign of the site. Very exciting news indeed, I have sent them an invite to the forum, so really hoping Andy does join.

4 Likes

Looking forward to digging around and getting dirty in this!

3 Likes

Looking forward to having the guy that built the API checking my work, will be really awesome.

1 Like

A post was split to a new topic: API DAta Source and Google Autocomplete

Thanks Paul for bringing my attention to wappler! I’d like to take this one-off slot to explain geoplugin. Please, noone, don’t take this as a sales pitch as it isn’t meant to be one, but simply explain the raison d’être behind geoplugin. At it’s base it has always been a geolocation plugin for this type of community and as such we will always try to take on board comments to facilitate things for developers.

After browsing around a few threads, particularly for geolocation, I feel there needs to be a minor “sales pitch” if you want to see it that way to explain geoplugin! Here goes:

Established in 2006 (yeah 12 darn years!!), geoplugin was the first free geolocation API. Totally free. Over time, like all things free, it got abused and service uptime suffered. Around 2010, a limit of 120 lookups per minute was introduced and anything over that required paid service (15€/mo, 120€ per yr etc) - those price points haven’t changed - and this allowed us to go expand our infrastructure to meet demand so that reliability became our calling card amongst all the other free services that popped up.

We still make very very little profit, with most everything going into the infrastructure.

Today, we handle between 3.5 and 4k requests a second. We’ve had around 20 minutes downtime in the last 2 years (the largest just outside of that timeframe was around 4hrs when we moved our entire infrastructure to a new DC and all clients were informed well in advance of the impending downtime - it was done in the early hours of Sun morning to avoid maximal impact).

To put 3.5-4k requests into perspective, Google handles globally around 40k requests a second on average (source: http://www.internetlivestats.com/google-search-statistics/ )
So geoplugin handles a 1/10th of that - ok, we don’t have complicated search algorithms to process, but we don’t own datacentres either! Yet we handle that traffic efficiently and reliably.

We handle so much traffic and are such a small fish, that entire networks (like Level3) have null-routed us in the past thinking we were a DDoS source. When things like that happen, we know immediately because our support email is lit up like Times Square! They immediately removed the block after explanation.

I’m mentioning all this because I read in a few places things like “free geolocation API disappear as quickly as they appear”

This cannot be far from the truth for geoplugin - we were the first to start a free API (so the others are copies) and we maintain the best free deal there is today (120 req/min).

Yes, we charge a small 12€/yr fee for SSL. Why? I hear you ask as it costs “us” nothing - believe it or not, that SSL handshake adds 2ms to each lookup, which when you’re handling 4kreq/sec adds an 8 second latency to all the requests handles in each second. Hmmm, see the backlog happening? Of course, all our requests don’t need SSL as they’re server-server calls. But by adding it as a “free” option, people will use it by default - unnecessary strain on a free service. So by “forcing” users to pay a very small yearly charge for SSL (because they could opt for non-SSL via PHP for example), it takes the burden off us, off the free service and makes the end user (our “clients”) think about whether they need it.

Oooph, that was a long one! Hope though, it fully explains geoplugin - we are here for you and any minor or major request, if serious and can benefit “not just you”, will always be taken on board and implemented if possible.

Sorry for the blah blah!
Andy

5 Likes

oh yeah, we’ve been around for 18 years and as you can see, our frontend, geoplugin.com, hasn’t changed one bit in design since then! Gotta get into wappler to change that :wink:

3 Likes

@geoplugin respect for running that such a long time over heavier and harder times. ddos etc. Nothing in reality is free but great work and thanx for your „blah“… sometimes it needs to be said.

1 Like

@psweb I might need a little help. I just tried this api today and couldn’t get it to work right.


Anything that I might’ve missed in order to get the schema tree into the interface? I’ve tested write it manually e.g. {{api1.data['geoplugin_city']}} and I get the output as expected.

I’m on latest Wappler version so I’m not sure step if I might’ve missed or it’s a bug.

Thanks in advance!

Hello

In the server side API component…
For newbies like me,you have to specify the ip address in the request otherwise you will get the one of your server.

The data is retrieved as follows: [ID].data.geoplugin_xxxxXXxxx
api.data.geoplugin_city
api.data.geoplugin_countryCode
api.data.geoplugin_countryName (…)