Suggest marking Google Cloud Functions support as experimental
See original GitHub issueIt 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 ofserverless 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
Issue Analytics
- State:
- Created 3 years ago
- Reactions:4
- Comments:8 (2 by maintainers)
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
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)
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!)
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