Ways to exposing information to static web apps

[albx]

The idea is to keep this project as a management console of my twitch livestreaming (but in a future also for manage talks, courses & so on) like a simple CMS and to expose the information to 1 or more static web apps which consume this APIs to show to the user the schedule of the live (and give feedbacks).

How could be exposed this Public APIs?

• REST
• GraphQL
• gRPC

What do you think?

[totti240282]

REST.

[skaman]

GraphQL

In my opinion these are the reasons why GraphQL on .NET with Hot Chocolate is a good choice:

• Filtering: work out of the the box on IQueryable and IEnumerable data types, so no need to manually handle them https://chillicream.com/docs/hotchocolate/fetching-data/filtering
• Pagination: same as before https://chillicream.com/docs/hotchocolate/fetching-data/pagination
• Sorting: same as before https://chillicream.com/docs/hotchocolate/fetching-data/sorting
• Projections: the client can do query that join data between tables with IQueryable, so the client is really free to query data as he wish https://chillicream.com/docs/hotchocolate/fetching-data/projections
• Subscriptions: let the client to subscribe data source and receive real time updates when they change: https://chillicream.com/docs/hotchocolate/defining-a-schema/subscriptions

On client side, there's an utility that basically is a client generator. From graphql queries it automatically build the c# client https://chillicream.com/docs/strawberryshake/get-started

Anyway graphql is not a good choice for upload files. Maybe on this side, if you plan to deploy on azure, for file upload you can use the Azure Storage. The server can generate a signed url that let the client directly upload the file on azure storage, without passing from the backend. This solution may have benefits if you plan to upload large files like videos.

[albx]

@totti240282 @skaman thank you very much for both feedbacks!

Still haven't clear ideas but my first little thoughts are:

• REST is the simplest solution. Easy to develop and maybe moving to OData also the paging, filtering, sorting etc. can be automated in some way
• GraphQL is very interesting also because I literally don't know anything about this and could be a good idea trying something (maybe during a livestream)
• gRPC is as interesting as GraphQL (maybe is not the best choiche?!)

Giving some context, the client couldn't be a .NET Client, I was thinking at NextJS for example.
In any case both the solution are still valid.

Another very important point to analyze is a good way to implement the security part (this APIs must be public).

Any other thoughts?

[skaman]

If you go with REST for paging, sorting and filtering there is also this library https://github.com/Biarity/Sieve

With GraphQL the Apollo Client is compatible with Hot Chocolate (https://www.apollographql.com/). I think the subscribe system is something out of the original protocol specification. Apollo is the most used library and Hot Chocolate use the same protocol of Apollo.

gRPC i'm not sure is the right solution in this case. gRPC is a good solution if you have a lot of data to stream between the server and the client.

[totti240282]

If you want to experience new and even powerful things use GraphQL.

[albx]

Wrapping up: I think GraphQL could be a good choice in the end.
So on Tuesday 14th evening we'll try (live on twitch) to study hot chocolate and add some graphql infrastructure :)