fenos

This is indeed at the very top of the list :)

We don’t support static website hosting just yet - might happen in the future :)

That is also a common pattern I agree, both ways are fine if the upload server is optimised accordingly :)

Our S3 Driver is compatible with any S3 Compatible object Storage so you don’t have to write one :)

Yes indeed! I would call it S3 on steroids!

Currently, it happens to be S3 to S3, but you could write an adapter, let's say GoogleCloudStorage and it will become S3 -> GoogleCloudStorage, or any other type of underline Storage.

Additionally, we provide a special way of authenticating to Supabase S3 using the SessionToken, which allows you to scope S3 operations to your users specific access control

https://supabase.com/docs/guides/storage/s3/authentication#s...

Yes, I agree! Although I should have specified that we support signed URL https://supabase.com/docs/reference/javascript/storage-from-... just not in the S3 protocol just yet :)

Thanks for asking this, we do not support signed URLs just yet, but it will be added in the next iteration

You can think of the Storage product as an upload server that sits in front of S3.

Generally, you would want to place an upload server to accept uploads from your customers, that is because you want to do some sort of file validation, access control or anything else once the file is uploaded. The nice thing is that we run Storage within the same AWS network, so the upload latency is as small as it can be.

In terms of serving files, we provide a CDN out-of-the-box for any files that you upload to Storage, minimising latencies geographically

Yes, absolutely! You can download files as streams and make use of Range requests too.

The good news is that the Standard API is also supporting stream!

We do not store the files in Postgres, the files are stored in a managed S3 bucket.

We store the metadata of the objects and buckets in Postgres so that you can easily query it with SQL. You can also implement access control with RLS to allow access to certain resources.

It is not currently possible to guarantee atomicity on 2 different file uploads since each file is uploaded on a single request, this seems a more high-level functionality that could be implemented at the application level

Yes, both can be fine :) after all, a Protocol can be interpreted as a Standardised API which the client and server interact with, it can be low-level or high-level.

I hope you like the addition and we have the implementation all open-source on the Supabase Storage server

Fantastic! I've never had a chance on launching the app on windows, I'm glad it worked!

I think you are running the dev mode, that's why the Chrome dev tools appeared :)

The import paths feature will be released soon so stay tuned! In the meantime, you can temporarily place the imported protos close to the one you want to use

Ty

Thanks, I’m glad you like it!

Yes, TLS will arrive very soon. Reflection too but it will take slightly longer.

Request chain will follow along!

I haven’t thought about recording and replay.

That is a great addition to the editor once we support request chain

Wow! Those two features will be certainly a good addition to the client! I’ll be adding them to the list

Hi! Creator of BloomRPC here. Thanks for the warming welcoming of the client! I’m glad to see lots of positive feedbacks.

The client aim to give the best developer experience possible on your day to day usage of GRPC services.

We are using it heavily internally and improving it everyday

I hope you’ll enjoy working with bloomrpc and that will be soon your GRPC companions