That's an error produced by the GitHub action when trying to deploy a Static Web App with some Durable Entities in its /api folder.
More precisely:
Function Runtime Information. OS: Linux, Functions Runtime: v3, Node version: 12.X
Finished building function app with Oryx
Found and validated 'routes.json' within build artifacts folder.
Error in processing api build artifacts: the file 'AppointmentEntity/function.json' has specified an invalid trigger of type 'entityTrigger' and direction 'in'. Currently, only httpTriggers are supported. Visit https://github.com/Azure/azure-functions-host/wiki/function.json for more information.For further information, please visit the Azure Static Web Apps documentation at https://docs.microsoft.com/en-us/azure/static-web-apps/
If you believe this behavior is unexpected, please raise a Github issue at https://github.com/azure/static-web-apps/issues/
Exiting
Obviously everything works perfectly on the devbox.
Why is it that "Currently, only httpTriggers are supported"?
Which component introduces this strange limitation and why?
With "only httpTriggers are supported" there isn't much we can do on the backend side apart from "hello world" scenarios!
Static Web Apps abstracts the Azure Function away from the user to streamline the experience of developing full stack web applications. As part of this abstraction process we needed to impose this limitation, so its our service adding this limitation.
Do you mind sharing more about your use case? There is a lot you can do with http triggers so I'm interested to hear what you are trying to do.
Do you mind sharing more about your use case?
So far it's nothing but a demo project demonstrating the use of Durable Entities (written in TypeScript) who's state is automatically propagated to the client side (React+TypeScript) with SignalR Service. The idea is to minimize efforts needed to implement an MVC-kind application with Views implemented as React components and Controllers implemented as Durable Functions/Durable Entities on the server. Durable Functions/Durable Entities are essential for the whole setup to work.
Code is here, btw.
But in general, I do believe that Durable Functions/Durable Entities is a very useful backend feature, so no reason for explicitly putting it aside.
Totally agree, today we do not support Durable Functions/Entities with the Functions deployed via Static Web Apps. You can still deploy the Function app separately and update your CORS to allow the Static Web App to communicate to it assuming that it is a public api.
This feature gap is something we are working on!
@miwebst I'm running into a similar issue with timer trigger functions as only Http triggered functions seems to be supported. Since the underlying product for the APIs are Azure Functions, I don't see why you are explicitly choosing to drop support for other trigger types.
Our usecase is that we have a couple of HTTP triggered APIs to CRUD reporting data. We also run timer triggered functions to periodically pull and update certain entities. This prevents the user from manually calling the update API.
I realize the static web app directories are structured well enough to deploy them as two separate builds to functions and blob storage but I was hoping to avoid having to find multiple Github/custom workflows to take care of this.
Thanks for the feedback! Unfortunately this is not possible today and is something we are looking into.
Do you have an estimate on when the timerTrigger function and the eventGridTrigger will be available?
Hitting this problem too trying to use Durable Entities with a SWA.
Very annoying given that it works locally!
Most helpful comment
So far it's nothing but a demo project demonstrating the use of Durable Entities (written in TypeScript) who's state is automatically propagated to the client side (React+TypeScript) with SignalR Service. The idea is to minimize efforts needed to implement an MVC-kind application with Views implemented as React components and Controllers implemented as Durable Functions/Durable Entities on the server. Durable Functions/Durable Entities are essential for the whole setup to work.
Code is here, btw.
But in general, I do believe that Durable Functions/Durable Entities is a very useful backend feature, so no reason for explicitly putting it aside.