Can we use php-gds as the official Datastore library?

[jgeewax]

See https://github.com/tomwalder/php-gds

Is this something we could discuss with the owner about merging into gcloud-php and being "the official library" ?

[jgeewax]

/cc @tomwalder :)

[tomwalder]

Hello.

[dwsupplee]

Hey Tom! 👋 Hope all is well and thank you for the contributions!

The library looks solid and I really appreciate your usage of design patterns, especially the implementation of the gateway. Usage is straight forward and the examples are very helpful.

I see that you provide options to wrap the appengine sdk and the google api client.

So far, with the work I have started on the storage client (and after quite a bit of deliberation) I leaned in the direction of not relying on existing libraries and going the route of some our sister libraries (gcloud-python, gcloud-node). The flexibility of not being tied to upstream libraries when we scale and the ability to provide full customization over the underlying http layer were important factors to me.

As the library grew have you found there to be any challenges or issues with wrapping the existing google clients/sdks?

[tomwalder]

Thanks for the vote of confidence!

The library was born out of my need to use Datastore in production. Initially, there was only support for the JSON API.

I've worked with @sjlangley to get the native Protocol Buffer stuff up to scratch. The performance benefits are clear.

I have retained support for the JSON API, but the features are not a 100% match, which can cause some problems maintaining feature equality.

To be honest, I think the vast majority of users now use the PB implementation.

The local development server does not support GQL, so I had to throw together a basic GQL parser to get over that hurdle.

I need to make the roadmap a little more obvious. Lots of plans!

Would you plan to re-write a ProtocolBuffer direct interface in gcloud-php? Seems like a significant amount of work, given that the sdk is included in AppEngine deployments by default?

[dwsupplee]

Could those interfaces be generated using Protobuf-PHP? Also, we have no guarantee someone would run the code on app engine. Do you know if the appengine-php-sdk is intended for use outside of that environment?

[JustinBeckwith]

making sure @tmatsuo and @bshaffer see this

[tomwalder]

The app engine SDK makes use of a compiled PHP module for the final
make_call() RPC method.

I'm not familiar with the inner workings of this, but I expect it to be
local-network-sensitive.

There is a RemoteAPI component, but not really familiar with how that might
factor in...

On Thursday, 11 February 2016, David Supplee [email protected]
wrote:

Could those interfaces be generated using Protobuf-PHP
https://github.com/drslump/Protobuf-PHP#generating-php-classes? Also,
we have no guarantee someone would run the code on app engine. Do you know
if the appengine-php-sdk is intended for use outside of that environment?

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

Tom Walder, CTO
We're hiring. Find out more at www.docnet.nu/jobs
http://www.docnet.nu/jobs?utm_source=email_signature&utm_medium=email&utm_campaign=email_signature
Call: 0161 660 7110 / Web: www.docnet.nu
http://www.docnet.nu/?utm_source=email_signature&utm_medium=email&utm_campaign=email_signature
This message is private and confidential. If you have received this message
in error, please notify us and remove it from your system. Venditan Limited
t/a Docnet is a company registered in England and Wales. Registered number:
9604502. Registered office: Speakers House, 39 Deansgate, Manchester, M3 2BA

[tomwalder]

GoogleCloudPlatform/php-docker#54

[tomwalder]

I'm planning support for the v1beta3 API now...

[dwsupplee]

@tomwalder

Let's see if we can get to a place where our plans can align here :). Before we could move forward with merging anything in there are some items we need to address:

• Support for the REST API should not happen by wrapping the google-api-php-client. We would need to remove this dependency, and ideally follow a pattern that matches what we are building for the services we are providing support for in this library currently.
• Support for protocol buffers should be handled by gRPC and not through the appengine-php-sdk. There are projects in motion which utilize gRPC and handle a lot of the plumbing work around dealing with the auto generated PHP from proto files for us. These tools are still a bit early in their development, but you can learn a bit more here and here.
• Naming conventions and method signatures should be handled in a manner consistent to the rest of the code in this project.

If it would be helpful, we could schedule some time to do a quick video chat and discuss more details this week.

Let me know what you think. Thanks!

[tomwalder]

Hi there.

Happy to chat through this. All sounds pretty workable.

I'm in the UK, on BST at the moment - let me know when might be a good time!

Tom

[dwsupplee]

Great! :)

Any day Tuesday-Thursday and preferably in the 9am to 5pm EDT range would be good. Shoot me an email @ [email protected] and we can iron out the rest of the details.

[dwsupplee]

/cc @tomwalder

[ajck]

Not wanting to add noise, but as some of us are betting the farm on Google Cloud :) , just wondering if any updates on the overall official Datastore support in PHP please? (i'm using Datastore with Standard PHP AppEngine via Tom's excellent library). Many thanks.

[dwsupplee]

Hey @ajck, thanks for your interest in the platform :).

We were looking forward to working with Tom on this one but the timing unfortunately didn't work out.

Support for Datastore over REST is expected to be available within the next month, with gRPC support coming soon after.

[ajck]

@dwsupplee Thanks that's great to hear. Just a couple of questions please - what sort of geopoint support can we expect from the PHP Datastore APIs (i.e., I need to find coordinates within an area) and secondly, will API docs and/or example PHP code be available too?

Many thanks,
Alex

[dwsupplee]

Docs and some basic usage examples will be available. @jdpedrie has been the primary on the datastore implementation and would likely be the best fit to answer your question about geopoint support :).

[jdpedrie]

Hey @ajck. Our implementation of datastore will support geopoints. And yep, we definitely provide documentation and example code for every method.

[tomwalder]

AFAIK, the v1 Datastore API does not support geo locality (near to) type queries though? Against Geopoint properties. Happy to be pointed in the right direction if this is not the case?

You might be able to implement some geohash stuff in the library layer I guess.

[dwsupplee]

We will be supporting data access around geo point types but as far as I am aware @tomwalder is spot on in that there isn't support for location based queries in datastore yet. There are currently no plans to add this functionality to the library and other tools will currently be needed to achieve it.

It does look like support in datastore may be on the way as the alpha release of geospatial queries for Java hints, however. We will be happy to make sure this functionality is included in the library as soon as it becomes available.

@pcostell might be able to share some information on expected time lines for for geospatial queries for us :).

[tomwalder]

You can use the Search API to do geospatial stuff now (and other basic full text search)

https://cloud.google.com/appengine/training/fts_intro/

https://github.com/tomwalder/php-appengine-search

[pcostell]

Nothing I can share, @dmcgrath may have more information.