Hi Lahiru, Thanks for putting together this investigation. I'm not 100% sure but it looks like gRPC-JS only works with Node.js since it uses Node.js APIs. I think you'll need gRPC-Web to make gRPC calls from a browser. My understanding is that that requires an Envoy proxy on the server side. (Rereading your email, I think you probably already know this, but just in case I thought I would point this out.)
It looks like django-grpc-framework isn't an active project [1], so I agree with your concern about depending on it. One issue with using gRPC in Django, I think, is that the integration that we've done with the Django framework would need to be re-implemented, things like middleware and authentication. It's probably doable, just something to keep in mind. It would be good if the gRPC server could run on the same HTTP port as the Django server, but I'm not sure how that would work. From the client, accessing the Django server or the gRPC server should both be over SSL, on the same port. Maybe on the backend they run on different ports but with the proxy it looks like from the client's perspective they run on the same port. The django-grpc-framework project may be good to mine for some ideas. I like that it follows django-rest-framework conventions. We use django-rest-framework in the Airavata Django Portal. Thanks, Marcus [1] https://github.com/fengsp/django-grpc-framework/issues/34 > On Feb 14, 2023, at 1:17 PM, Lahiru Jayathilake <[email protected]> > wrote: > > Hi Suresh, > > Thank you for the feedback. The other library that can be used to facilitate > browser communication with gRPC services is gRPC-JS > (https://github.com/grpc/grpc-node/tree/master/packages/grpc-js). However, in > terms of browser support, gRPC-Web is specifically designed for use in web > browsers, and it supports all major browsers including Chrome, Firefox, > Safari, and Edge. In contrast, gRPC-JS is designed to work with both web > browsers and Node.js, and it may require additional configuration to work > correctly in web browsers and it is a bit cumbersome. > > @[email protected] I had a chat with Suresh and wanted to clarify a few points > with you. > > 1. In the second approach what I have done is spinup up a gRPC server in the > background (inside Django App). When I was doing that I came across a > framework called django-grpc-framework [1][2]. I did not proceed with that > framework because it is coming from a personal repository. What do you think? > Is it good to go with this? > > 2. Any suggestions or comments on the approach of using gRPC (gRPC-web) to > establish communications with the frontend? > > I'd be really happy to hear your thoughts and suggestions on these. > > [1] - https://github.com/fengsp/django-grpc-framework > [2] - https://pypi.org/project/djangogrpcframework/ > > Thanks, > Lahiru > > > > On Tue, Feb 14, 2023 at 7:47 PM Suresh Marru <[email protected]> wrote: > Hi Lahiru, > > Thank you for summarizing both of these, and your POCs of both approaches are > helpful. The second option, if feasible, will be preferable. You already > mentioned the performance. In addition, you will also get forward/backward > compatibility if the underlying protobuff structures are maintained with some > discipline. > > The big plus side of your 1st approach is the REST-compatible javascript > libraries. Other than grpc-web (https://github.com/grpc/grpc-web) have you > seen broader support? I see you are building on grpc-js how is that > experience? > > Suresh > >> On Feb 13, 2023, at 2:49 PM, Lahiru Jayathilake >> <[email protected]> wrote: >> >> Hi All, >> >> I have been engaging with the SMILES project to implement the Gateway and >> its necessary components. Just to give you a brief introduction, the SMILES >> project has three types of data that need to be combined for publication: >> Computational DB, Literature DB, and Experiment DB. There should be a >> frontend to filter, create, and delete data products, with a Django app as >> the backend that will communicate with Apache Airavata Data Catalog [1]. >> >> Mainly, I have been exploring two approaches. >> >> 1. >> <approach1.png> >> >> The frontend will communicate with the Django app via REST, and the Django >> app will manage the manipulation of data products through gRPC calls to the >> Data Catalog API. Django models will be used to represent the Computational, >> Literature, and Experiment data products, without storing the data. In the >> end, these data products will reside in the Data Catalog, following its >> established conventions. >> >> POC - https://github.com/lahirujayathilake/SEAGrid >> This has been implemented to cover the data product creation >> >> 2. >> <with-grpc.png> >> >> In this approach, the distinction will be a gRPC server operating within the >> Django app. To represent the three data products, protobufs will be defined >> that extend the DataCatalog proto messages [2]. The frontend will >> communicate using gRPC calls. >> The gRPC API can be used to manipulate data from other clients, resulting in >> improved performance. >> >> POC - https://github.com/lahirujayathilake/SEAGrid/tree/with-grpc >> (The frontend is inprogress) >> >> I would like to hear your thoughts and feedback on the designs to improve >> and to go with the right approach. >> >> >> [1] - https://github.com/apache/airavata-data-catalog >> [2] - >> https://github.com/apache/airavata-data-catalog/blob/main/data-catalog-api/stubs/src/main/proto/DataCatalogAPI.proto >> >> Cheers! >> Lahiru >
smime.p7s
Description: S/MIME cryptographic signature
