> On Apr 21, 2015, at 12:17 PM, Dan Ciruli <cir...@google.com> wrote: > > > Hi, Karl - > > I'm Dan Ciruli, and I recently took over as Product Manager on Endpoints. I > really appreciate your feedback. My team is currently looking at improvements > that we’d like to make in the next version of Endpoints and your comments > jibe with what I’ve been hearing from a lot of our users. We are working on > both the developer experience as well as providing some features that help > you with managing your API (controlling access, etc). > > > >
You know - one thing that I would suggest is separating the serialization features from the overall endpoints functionality. My hand-rolled solution has to dig around in the guts of the ndb.Models (using ndb.Model._properties) and I’m afraid you guys will break that since it’s not a publicly documented API. What I would find useful is an API that gives you the ability to: 1. Introspect ndb.Models (and the equivalent for other runtimes) to find just the datastore properties. 2. Convert the property datatypes into JSON / Protobufs / whatever 3. Helpers to selectively serialize entities and entity graphs 4. Callbacks / transforms during serialization to handle API and data model changes, friendly name changes, and things like automatically fetching keys (which I do). With that I could easily turn an entity or entity graph into a serialized format that I care about. I could then more easily build out my REST APIs using whatever I wanted. You could, of course, build the rest of Cloud Enpoints on that (and probably already have all of this functionality in the internals), but for those of us that don’t find Endpoints to be a great fit this functionality would really make life easier. Some other notes about Endpoints: 1. Discovery is just not that interesting to me for APIs that are completely internal (i.e., only accessed by code that I control) and it comes with additional complication and a pretty significant startup delay for the default clients (from what I remember). Yeah, yeah, I know all of the REST purist arguments about discovery, but it just isn’t worth it a lot of times for me and I’m guessing others as well. Think about being able to just decorate a single URL handler so that it handles serialization / de-serialization, auth, etc. without having to muck around with discovery and the client libraries (I would in a lot of cases just use a standard HTTP API to call the APIs). 2. It would have helped immensely to document how the URLs would be mapped. I had some trouble getting things running initially (can’t quite remember what the problem was) and I was trying to just use curl or something to figure out where the problem was. But I had to figure out what all of the actual URLs were. I remember having trouble even figuring out what the discovery url was, but that seems to be a little better documented now (https://cloud.google.com/appengine/docs/python/endpoints/access_from_python). 3. Authorization - it would be nice if this wasn’t endpoints specific but fit in with the rest of GAE (like the minimal authorizations that are available now in app.yaml). And having a fully functional users API would make it much better by having a standardized identity (presumably with roles) that you could use in authorization statements. 4. Like I mentioned before, having separate types for requests and responses is a basic requirement for me. > I would be interested in a follow-up conversation with you -- send me an > email (my last name @google.com) and I’d like to set something up. > > > > Great - I’ll drop you an email. Karl > Thanks - > > > Dan > On Monday, April 20, 2015 at 7:38:45 PM UTC-7, Alistair Burrowes wrote:> Hi, >> >> I would echo a lot of what Karl said. >> >> >> I would like to see more examples of complex usage of GAE and or managed >> VMs. These are the kind of usages that more advanced developers might want. >> Here are a few examples of things that I have figured out or want: >> >> >> - CI/CD set up, with dev/staging environments and one button deployments to >> production. It was a pretty long process of trial and error to achieve this. >> >> >> - a single page app with separate the web front end and the backend >> (endpoints) modules. This was also tricky since endpoints live behind /_ah >> which can't be routed away from the default application. I think separating >> these out and their build processes is healthy separation of concerns. >> >> >> - integrating gulp build processes into GAE dev servers/build processes. In >> my case I'm using gradle app engine plugin. >> >> >> - "ismorphic" javascript app, with server side rendering via something like >> react (I assume this would be a managed VM running node js) that speaks to >> endpoints, from both client side and the node js layer. >> >> >> Also I agree that more transparency on the roadmap/discussions on direction >> would be really useful. >> >> >> For example the lack of java 8 on GAE is a concern of mine - >> https://code.google.com/p/googleappengine/issues/detail?id=9537 >> >> >> . There isn't any communication as to what the status of this is (note: AWS >> beanstalk supports java 8). >> >> >> I love the minimal configuration/maintenance of the GAE sandbox, but I need >> to know if a shift to managed VMs is the longer term direction for java >> support. It is not clear when starting a new java project if I should bet on >> GAE java sandbox being supported in the long term or just go with java 8 on >> a managed VM. >> >> >> Other than this, I have found GAE/GCP to be fantastic and I am really happy >> with the different tools and quality of the libraries provided. >> >> On Thursday, April 16, 2015 at 3:37:31 AM UTC+10, Katie Ball (Google Cloud >> Support) wrote:> Hi, >>> >>> >>> My name is Katie, and I am on the Google Cloud Platform technical support >>> team. >>> >>> >>> This message is to Google Cloud Platform community members, especially if >>> you are newer to GCP. I would like to know what our team can do to help you >>> have a better and more enjoyable experience during the first days on GCP. >>> >>> >>> Did you need technical support? If so, I’d like to hear all about it. >>> >>> >>> I’d also like to know: >>> >>> What did you find most difficult about the first-time user experience? >>> >>> >>> Where did you get stuck? >>> >>> >>> >>> >>> Please reply to the group with your answers or any ideas you have on how >>> the technical support team can help new customers get familiar with GCP. >>> >>> >>> And as a thank you for the great ideas, we will be giving away support >>> coupons worth $450 (equivalent to 3 months of silver support) to 5 lucky >>> community members who post a response. Please make sure to reply before >>> April 22nd. >>> >>> >>> Thanks for your insights, and cloud on! >>> >>> Katie >>> >>> >>> >> >> > > > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-appengine+unsubscr...@googlegroups.com > . > To post to this group, send email to google-appengine@googlegroups.com > . > Visit this group at http://groups.google.com/group/google-appengine > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-appengine/5610bc4d-852b-4476-a10b-51574cb2e925%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout > . -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/1AA8B6DC-16ED-4737-A559-A626B18E3E48%40rakkoon.com. For more options, visit https://groups.google.com/d/optout.
