Suggest marking Google Cloud Functions support as experimental

[parkan]

It does not appear that GCP Cloud Functions are actually properly supported by the framework at the moment. For instance, these came up in the first ~3 hours of trying to develop on this stack:

• "Unrecognized provider: google" returned on every invocation https://github.com/serverless/serverless-google-cloudfunctions/issues/232 (even though builds generally do end up working)
• You must use SLS_DEBUG=* to get useful failure information, otherwise it will be shadowed by the above error
• Local invocation is broken https://github.com/serverless/serverless-google-cloudfunctions/issues/129 (reported as broken since 2018)
• Guide is not accurate (e.g. tells you to use npm i --save instead of serverless plugin install ..., and the quick start guide omits the plugin step entirely, which I assume will not work)

Still, the docs site implies that GCP is properly supported despite basic functionality like local invocation and being recognized as a valid provider being broken, even though Google is near the top of the provider list (as well as being a major vendor in the field).

I fully appreciate the complexity of developing a framework abstracting over multiple serverless providers, and the general difficulty of OSS, however the documentation is misleading as to the readiness of the GCP support. We just began building a project targeting GCP + serverless after a week of research with rapid iteration in mind but once development started, it became apparent that the tooling isn't ready. I had previously used the framework for AWS and had good results, which makes this really disappointing.

I would update docs to indicate that GCP support is partial.

EDIT: edited for tone

[parkan]

another suggestion I would make would be to add the needed plugin to package.json/serverless.yml in the template so the plugin install step is not necessary

[medikoo]

"Unrecognized provider: google" returned on every invocation serverless/serverless-google-cloudfunctions#232 (even though builds generally do end up working)

This error is equipped with extensive explanations which states how to address it, and how to turn off the error if needed. Were they not clear?

You must use SLS_DEBUG=* to get useful failure information, otherwise it will be shadowed by the above error

This is a bug that should be reported in plugin repository. At least all meaningful error information should be exposed without using SLS_DEBUG=*

Guide is not accurate (e.g. tells you to use npm i --save instead of...

PR to improve that is welcome

I would update docs to indicate that GCP support is partial.

We don't have enough resources to provide a proper support to GCP, and we're looking for maintaners that will help us to do so. We're also indicated that in main readme: https://github.com/serverless/serverless-google-cloudfunctions#contributing

We may also add note about that in documentation hosted here

[parkan]

@medikoo thanks for your reply, my apologies if the original report came off as demanding, the interlocking concerns here created a fairly frustrating situation to diagnose, so I spoke more harshly than I meant to

This error is equipped with extensive explanations which states how to address it, and how to turn off the error if needed. Were they not clear?

I think the issue with the "Unrecognized provider" error is that it can easily be interpreted as equivalent to the (actually fatal) "Serverless Error... The specified provider $foo does not exist", even though it really means "no validation was found for this provider". The effect was exacerbated in this case because the plugin didn't print the real fatal errors without SRS_DEBUG, so I was led to believe that the "Unrecognized provider" (printed in red, looks like a fatal build error in absence of any others) and the following lines about validation (printed in gray, looks like a warning/info) were separate messages and setting configValidationMode: off wouldn't help.

I'm not sure what the project's warning/error policy is, but it seems like rewording "Serverless: Configuration error: Unrecognized provider" to something like "Serverless: Configuration warning: No validation for provider $foo specified, proceeding blindly" would help avoid this confusion (as well as maybe changing color to yellow/not scary red). IMO "Configuration error" (i.e. full stop, error in config) should be a different status severity than absence of validation rules (warn but proceed assuming things will work out, as it happens now)

It would also be helpful to disambiguate the message between plugins that do not offer validation and entirely bogus providers (e.g. setting `provider: "asdf" gives the same validation error), though I suspect this may be tricky because the validate/build steps are probably separate, and besides building against a non-existed provider does give the helpful "The specified provider $foo does not exist" message, so rewording the validation error could be good enough.

I am happy to PR this repo for a wording/error severity change it it makes sense to you. I can also look into why the GCP plugin doesn't pass the real errors if I have time next week.

All that aside, the big source of frustration was picking up the framework with the idea that GCP would work at a similar level of support to AWS. It's totally ok if that's not the case! However, it would greatly benefit potential users to understand the expected support level for each platform.

[parkan]

Finally, on a really high level, I feel that working towards a uniform interface for serverlesss function deployment across providers would be a great boon to everybody in the field (similar to how the S3 interface is commonly supported across many storage vendors), and the serverless framework seems to be extremely well positioned to act as neutral ground/round table for making this happen. Perhaps targeting zeit/vercel as the most barebones platform can be a good place to start this, with other providers adding extensions based on their specific capabilities.

This is absolutely Unsolicited Architecture Advice from a third party, so feel free to ignore this part based on your domain specific knowledge 😄

[parkan]

another small note, the error message links to "https://www.serverless.com/framework/docs/providers/aws/guide/plugins#extending-validation-schema", which is housed under /providers/aws, furthering the confusion about whether the provider I'm using is supported

[medikoo]

I think the issue with the "Unrecognized provider" error is that it can easily be interpreted as equivalent to the (actually fatal) "Serverless Error...

I agree, that it easily can be misinterpreted. I've opened dedicated issue for that: https://github.com/serverless/serverless/issues/8084 we will handle that shortly

Finally, on a really high level, I feel that working towards a uniform interface for serverless function deployment across providers would be a great boon to everybody in the field

I personally share very same sentiment. At this point we're probably not close to that, but I'll definitely look forward in that direction (anyway at this point more effort is put into improving Serverless Components)

another small note, the error message links to "https://www.serverless.com/framework/docs/providers/aws/guide/plugins#extending-validation-schema", which is housed under /providers/aws

Yes, it's general problem with documentation, that a lot of provider agnostic content is hosted under AWS. I've opened an issue to tackle that: https://github.com/serverless/serverless/issues/8085 (PR's welcome!)

[hammadzz]

I will echo the same opinion, this is not production ready. Better to drop it if it cannot be supported.

[jamesClarePhdMedia]

One thing for the PR team the documentation says:

"All of the Google Cloud Functions in your serverless service can be found in serverless.yml under the functions property."

I have no idea where this is. Does it even exist?

Also on the examples it has a commented out line: resource: projects/*/topics/my-topic After a big of searching, it looks like this is a legacy trigger can the new triggers work?

[ninas]

+1 on this being marked experimental - I started with serverless, but as I tried to grow and test my application on GCP, I've had to move more and more off. It's honestly been a giant pain and waste of my time. I wish the documentation was clearer on the actual state of support, because then I wouldn't have bothered.

[medikoo]

PR that improves our documentation is welcome!

[ninas]

@medikoo added!