[google-appengine] Mail Service Deprecation?

https://cloud.google.com/appengine/docs/python/release-notes > Google no longer accepts quota increase requests for the mail service. Customers should use Sendgrid instead. Google will probably deprecate it soon, and close it a year later. -- You received this message because you are subscribe

Re: [google-appengine] Mail Service Deprecation?

yea, I think we all saw this coming. On Fri, Apr 29, 2016 at 10:17 AM, pdknsk wrote: > https://cloud.google.com/appengine/docs/python/release-notes > > > Google no longer accepts quota increase requests for the mail service. > Customers should use Sendgrid instead. > > Google will probably depre

Re: [google-appengine] Mail Service Deprecation?

Suggestion for the team: If you do decide to do this, keep your existing API and just swap in SendGrid as the underlying transport layer. Maybe we could put our SendGrid API key (or however they deal with that) into the console, or in app.yaml someplace, or something like that. I’ve got dozens

Re: [google-appengine] Mail Service Deprecation?

Hey Joshua, That's certainly an interesting idea! While I can't guarantee we'll implement it, be assured that we've heard this suggestion and will consider it. In the meantime, if a deprecation were announced, we would certainly welcome the opportunity to help as many users as possible easily m

Re: [google-appengine] Mail Service Deprecation?

The Mail API is extremely important to us and provides satisfactory deliverability for our use cases in its current form. For the amount of mail we send, alternatives are still too expensive. -1 on shutting the API down completely. We rely on it and find it useful. On Monday, May 2, 2016 at 1:4

Re: [google-appengine] Mail Service Deprecation?

Hey John, Thanks for your feedback. We definitely appreciate hearing from users on issues like these. As one helpful recommendation which you might not be aware of, I can link to SendGrid's documentation on their free tier , which is awesome in the amount of quota /

Re: [google-appengine] Mail Service Deprecation?

yeah, one less reason to bet on App Engine: it's such a moving target. We can't afford to rewrite critical parts of the code every few years just because APIs get deprecated. Blobstore first, now this. Mail has been the single most reliable feature for us over the past 5 years. I understand the pr

Re: [google-appengine] Mail Service Deprecation?

Geez, the blobstore? Old skool :-) Jeff On Tue, May 3, 2016 at 3:14 PM, Emanuele Ziglioli wrote: > yeah, one less reason to bet on App Engine: it's such a moving target. > We can't afford to rewrite critical parts of the code every few years just > because APIs get deprecated. > Blobstore first

Re: [google-appengine] Mail Service Deprecation?

Hey Emanuele, I understand your concerns about needing to revise your codebase - nobody wants to spend more time than they need on maintaining or adjusting a system when they could be blazing new trails and writing new behaviour and system, but rest assured that we really do try to ensure that

Re: [google-appengine] Mail Service Deprecation?

How simple and easy life seems when one’s job is just to write support e-mails. Programming e-mail support in the cloud is a different story. It took me a long time to get the GAE mail service work reliably and I am very happy with it. I had to deal with encoding issues, MIME issues, etc. I do n

Re: [google-appengine] Mail Service Deprecation?

The challenging part of email sending is the verification and related dns uglinesses, so it's not as simple as replacing the API layer Even setting up senders with App Engine is quite challenging, you have to create the email, add that email as an admin etc. (back in the old days, not sure how

Re: [google-appengine] Mail Service Deprecation?

This is really funny, having Gmail as one of the best e-mail infrastructure, but unable at the same time to provide a managed e-mail service for its cloud offerings. We implemented AWS SES on all our GCE fleet as sendmail relay since long time and it's running like a charm. I don't see any reas

Re: [google-appengine] Mail Service Deprecation?

> On Jun 27, 2016, at 3:37 PM, 'Kim Lewandowski' via Google App Engine > wrote: > > deprecating a service without giving customers a pathway to a comparable > alternative is not a tenable strategy. Wow. You must be new here. Someone get this new PM a long sword and some armor, so they can m

Re: [google-appengine] Mail Service Deprecation?

Hi Joshua, I am not sure what you are referring to but what your write is not consistent with my experience using GAE for a very long time. The mail service is an isolated case and my understanding is that even in the case of mail GAE has grand-fathered all of us who have been using mail in our

Re: [google-appengine] Mail Service Deprecation?

There are so many examples: HRD is *not* a comparable alternative to the original data store. It lacks a bunch of consistency guarantees that require all sorts of hacky workarounds in apps that we didn’t used to have to do, and for relatively small-scale apps are completely silly. Cloud Storag

Re: [google-appengine] Mail Service Deprecation?

Geezus…inline… On Mon, Jun 27, 2016 at 4:41 PM, Joshua Smith wrote: > There are so many examples: > > HRD is *not* a comparable alternative to the original data store. It lacks > a bunch of consistency guarantees that require all sorts of hacky > workarounds in apps that we didn’t used to have t

Re: [google-appengine] Mail Service Deprecation?

Jeff, Many good points but please stop taking on the mail service especially with this tone. Using your language, one could argue that the mail service was there before the Java runtime and Cloud SQL and if Google was not "wasting" its engineering resources on these newer efforts, many of the

Re: [google-appengine] Mail Service Deprecation?

> > for >1000 emails, I don't think SendGrid would easily allow sending > emails, as far as I contacted such services before, they considered high > amount of emails as newsletters and required very strict consents from > users and proof of such consent > We've been using SendGrid (though not