[Google Places] Best Practice

Forge Component
Published on 2017-04-03 by Ouen Worth
5 votes
Published on 2017-04-03 by Ouen Worth
Firstly great forge component.

I managed to do it all but no where near as beautifully as this pattern but where I was getting stuck was the idea of collecting all the data client side and then passing it back. This seemed against my current best practice judgement. I feel as if the client should really only pass back the a key if possible (Place_ID in this case) then with in your server processing call google places to retrieve the detail. Why? well previously passing info back to the server from the browser has been expensive and open to tampering. I went as far as looking for the swagger file for calling the google places api.

Should I be happy to change my admittedly 'Client Server' archtecture view on this in 2016.? I know this architectural question will come up again for me.
The primary business value was to have a lightweight component that helped to reduce the number of key strokes needed to enter address data. The secondary business value was to try and skirt around the Google API call limitation without having to set-up an account with them.
Browser side API calls are not cumulative against the application and do not count against the server side API calls which the Google Maps component would use.
The performance value was to leverage a shortest path principle with regards to calling the Google API directly instead of brokering it through the server. This improves the auto-complete response time as you are piggy backing off of Google global presence.
The response JSON could be processed in the browser directly into the form which is a pattern that I have used. The record conversion was added to make the component available to a broader audience.
The API calls are over SSL (if I recall correctly, Google enforce this now) and the JSON response string (or any form submission) should be passed back to the platform over SSL. The browser is the security weak point in the chain but this can be mitigated server side if needed by doing a lookup using the places_id.
The plus side is that you get the GeoLoc data and the Google place_id along with a ton of context rich other information depending on what is selected by Google. This is all publicly available on Google and free to use as long as you follow there branding guidelines.

Hi Ouen,

I agree with everthing you said and it is great documentation for your great pattern.

My question was using this example but holds true to many examples
  • Create a page with your great pattern
  • Select address & fires off client side and gets lovely info
  • My question is this I would normally NOT want to pass this amount of data back to the server. Dont get me wrong I want the first two steps to occur! Using this as an example I guess most people will want to create a database record using the information gathered on the client BUT arhitectually I have been trained to if possible go and get the info again server side so that the data is clean, untampered with, less returning widgets etc to handle across the web etc. This is my question what is the performance hit of returning so many fields/widgets and is it architecturally sound. This question is appropiate to a lot of the api economy and the drives at the heart of the design of input pages...should you return fields when you dont need to if they are avalible at the server level.

What I dont want to find out in years to come was sending the fields back, unpacking them, etc cost many more times then a server api call to go get them again...this is not just for goolge get places ok.

what I don't want is a solution architect looking at the application and saying we expressly forbid using a webpage form as some sort of container on the client to store data which could otheriswe be fetched by the server more securely.
Your last points touches on the conundrum which the HTML5 bucket of technologies and the omnipresent "Web 3.0" cloud bring to the architects table.
There is a principle of Isomorphic JavaScript where code can run both in the server and the client. This Isomorphism of client vs. server side responsibility needs to be factored into the modern architects thinking when delivering business value and customer driven experience applications or solutions.
The approach that I take to balance this conundrum is to think OutSystems First and then evolve the architecture from there while following the principles of best practice that the platform suggests.
The looming P10 release will bring client vs. server side optimisation to the platform for mobile applications. I am sure that the thinking that has been employed there will follow through to the browser based applications at some point.
IMHO, the conundrum will never be eradicated. The technology constraints and advances will always force the architect to balance their thinking around performance, security, responsiveness and digital channel. Having said that, I am confident in the knowledge that the platform caters for that substantially and it then allows me to focus on delivering business value instead of technology hurdles.
Thanks Ouen for confirming to me this is an area that is still a grey area.

You may come from this from a different perpective as an Outystem representative already but most will be trying to get Outsystems accepted into their organisations with out mandate via the solution gate keepers, and here I will be changing a habit of a life time and going 'Outystems Second' as opposed to 'Outsystems First' as first has not been successful for me.

It is important this time around to understand exactly what is happening under the covers. We the experienced solution guys here must try and shape the product so it does not unnecessarily provide excuses to traditional IT to humor lowcode, hence my question. Think I will stick to mimizing the amount of data stored with in pages and passsed back and forth to the server.