RVDAS API's to enable "Bring your own GUI"

[gabesargeant]

Hi @davidpablocohn

After recent discussions from the RVDAS workshop in Hobart, I've put together a basic set of API's endpoints to enable people to create GUI's for the rvdas server API without needing to use Django templates.

Rather, anyone can build out a React.js project or something that fits their requirements. If they are not hosting locally to the machine hosting the RVDAS Django application. All they need to do is ensure their GUI host is in the django_gui.settings.py ALLOWED_HOSTS array. And they should be able to make requests without issue.

I would anticipate most people would extend the nginx.conf to have a webroot to another git repo to serve their GUI project to keep things simple, or if they have another app they want to integrate RVDAS management into they could just connect to the nginx directly on the /api/ endpoints.

The forked branch is dev-api
https://github.com/gabesargeant/openrvdas/tree/dev-api

This implementation is built with Django REST framework and DRF-Spectacular. This allows the most code reuse of your existing django code without having to rewrite a ton of url handling in a totally disjoint API framework.

The api_views.py files reimplements the django_gui views.py files interactions with DjangoServerAPI but in a more structured way so that each endpoint represents an explicit GUI action that was previously handled by switching on Django POST parameters.
A good example of this is the views.index path that handles 'delete_cruise', 'select_mode', 'reload_button' etc. There's are each an endpoint alone.

The overall code changes are actually pretty light. It is a non breaking set of changes.

The notable changes are:

• I've upped the version of Django to 5. This was a non breaking change as the existing app doesn't have a lot of complexity that is affected by such a jump.
• I've also imported the DRF files and the DRF - spectacular libraries. including the sidecar library to give everyone access to the swagger ui.

Happy to discuss this in greater detail.

Regards

Gabriel Sargeant.

[davidpablocohn]

Pulled this in and played with it a little - most excellent, thanks again! The one thing I need to grapple with is Django versions vs OS versions. We're still supporting Ubuntu 18, which comes with Python 3.6, while Django 5 requires 3.10 or above. This means either: 1. Letting the Django version float with the OS (rather than version locking it) 2. Explicitly mucking with required versions in requirements.txt depending on OS 3. Forcing installation of more recent Python versions (maybe via something I've not seen called "deadsnakes"?) to support the required Django version I can see advantages/disadvantages to each (risk of breakage, complexity of installation script, longer, slower build...). Does anyone have any strong opinions one way or the other?

…

On Wed, Apr 17, 2024 at 6:49 PM Gabriel Sargeant ***@***.***> wrote: Hi @davidpablocohn <https://github.com/davidpablocohn> After recent discussions from the RVDAS workshop in Hobart, I've put together a basic set of API's endpoints to enable people to create GUI's for the rvdas server API without needing to use Django templates. Rather, anyone can build out a React.js project or something that fits their requirements. If they are not hosting locally to the machine hosting the RVDAS Django application. All they need to do is ensure their GUI host is in the django_gui.settings.py ALLOWED_HOSTS array. And they should be able to make requests without issue. I would anticipate most people would extend the nginx.conf to have a webroot to another git repo to serve their GUI project to keep things simple, or if they have another app they want to integrate RVDAS management into they could just connect to the nginx directly on the /api/ endpoints. The forked branch is dev-api https://github.com/gabesargeant/openrvdas/tree/dev-api This implementation is built with Django REST framework <https://www.django-rest-framework.org/> and DRF-Spectacular <https://drf-spectacular.readthedocs.io/en/latest/>. This allows the most code reuse of your existing django code without having to rewrite a ton of url handling in a totally disjoint API framework. The api_views.py files reimplements the django_gui views.py files interactions with DjangoServerAPI but in a more structured way so that each endpoint represents an explicit GUI action that was previously handled by switching on Django POST parameters. A good example of this is the views.index path that handles 'delete_cruise', 'select_mode', 'reload_button' etc. There's are each an endpoint alone. The overall code changes are actually pretty light. It is a non breaking set of changes. The notable changes are: - I've upped the version of Django to 5. This was a non breaking change as the existing app doesn't have a lot of complexity that is affected by such a jump. - I've also imported the DRF files and the DRF - spectacular libraries. including the sidecar library to give everyone access to the swagger ui. image.png (view on web) <https://github.com/OceanDataTools/openrvdas/assets/23356840/1a432e46-3ece-4136-b497-e23f957e30df> Happy to discuss this in greater detail. Regards Gabriel Sargeant. — Reply to this email directly, view it on GitHub <#372>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFO7V3VOANN4DMOA7GROZ6DY54RCRAVCNFSM6AAAAABGMLE7ASVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGUZDCOJTGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[davidpablocohn]

Hi Gabe - what would you think about unrestricting the versions for Django and djangorestframework? That way they can float with the OS release number. I've tested the unrestricted versions with RHEL 7, 8 and 9 and Ubuntu 20, 22 and 23, and it all works. That, plus a little flake8 cleanup, and I'd love to pull your changes into the dev branch. On Tue, Apr 23, 2024 at 8:00 AM David Pablo Cohn ***@***.***> wrote:

…

Pulled this in and played with it a little - most excellent, thanks again! The one thing I need to grapple with is Django versions vs OS versions. We're still supporting Ubuntu 18, which comes with Python 3.6, while Django 5 requires 3.10 or above. This means either: 1. Letting the Django version float with the OS (rather than version locking it) 2. Explicitly mucking with required versions in requirements.txt depending on OS 3. Forcing installation of more recent Python versions (maybe via something I've not seen called "deadsnakes"?) to support the required Django version I can see advantages/disadvantages to each (risk of breakage, complexity of installation script, longer, slower build...). Does anyone have any strong opinions one way or the other? On Wed, Apr 17, 2024 at 6:49 PM Gabriel Sargeant ***@***.***> wrote: > Hi @davidpablocohn <https://github.com/davidpablocohn> > > After recent discussions from the RVDAS workshop in Hobart, I've put > together a basic set of API's endpoints to enable people to create GUI's > for the rvdas server API without needing to use Django templates. > > Rather, anyone can build out a React.js project or something that fits > their requirements. If they are not hosting locally to the machine hosting > the RVDAS Django application. All they need to do is ensure their GUI host > is in the django_gui.settings.py ALLOWED_HOSTS array. And they should be > able to make requests without issue. > > I would anticipate most people would extend the nginx.conf to have a > webroot to another git repo to serve their GUI project to keep things > simple, or if they have another app they want to integrate RVDAS management > into they could just connect to the nginx directly on the /api/ endpoints. > > The forked branch is dev-api > https://github.com/gabesargeant/openrvdas/tree/dev-api > > This implementation is built with Django REST framework > <https://www.django-rest-framework.org/> and DRF-Spectacular > <https://drf-spectacular.readthedocs.io/en/latest/>. This allows the > most code reuse of your existing django code without having to rewrite a > ton of url handling in a totally disjoint API framework. > > The api_views.py files reimplements the django_gui views.py files > interactions with DjangoServerAPI but in a more structured way so that each > endpoint represents an explicit GUI action that was previously handled by > switching on Django POST parameters. > A good example of this is the views.index path that handles > 'delete_cruise', 'select_mode', 'reload_button' etc. There's are each an > endpoint alone. > > The overall code changes are actually pretty light. It is a non breaking > set of changes. > > The notable changes are: > > - I've upped the version of Django to 5. This was a non breaking > change as the existing app doesn't have a lot of complexity that is > affected by such a jump. > - I've also imported the DRF files and the DRF - spectacular > libraries. including the sidecar library to give everyone access to the > swagger ui. > > image.png (view on web) > <https://github.com/OceanDataTools/openrvdas/assets/23356840/1a432e46-3ece-4136-b497-e23f957e30df> > > Happy to discuss this in greater detail. > > Regards > > Gabriel Sargeant. > > — > Reply to this email directly, view it on GitHub > <#372>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFO7V3VOANN4DMOA7GROZ6DY54RCRAVCNFSM6AAAAABGMLE7ASVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGUZDCOJTGU> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[gabesargeant]

Hi,
I have no objection at all to floating the version of Django or DRF.

I'm not sure about DRF-spectacular. Have you noticed it being affected?

I haven't had time this past week to play around with it. ( I should have time this Tuesday AEST)

The only reason I advanced Django to V5.X was because it's a habit of mine to try and upgrade everything to get well infront of the EOL broom wagon.

Django 3.X is coming to EOL soon.
https://endoflife.date/django

That ins't the biggest issue in the world. Nothing will stop. But something to keep on top of.

[davidpablocohn]

Thanks! Running GET requests via the REST api *seemed* to work fine with everything floating. But I have to admit that I've got zero understanding of what parts of the process depend on drf-spectacular, so it may be that my test pokings didn't exercise dark corners where it could break things.

…

On Sat, Apr 27, 2024 at 9:17 PM Gabriel Sargeant ***@***.***> wrote: Hi, I have no objection at all to floating the version of Django or DRF. I'm not sure about DRF-spectacular. Have you noticed it being affected? I haven't had time this past week to play around with it. The only reason I advanced Django to V5.X was because it's a habit of mine to try and upgrade everything to get well infront of the EOL broom wagon. Django 3.X is coming to EOL soon. https://endoflife.date/django That ins't the biggest issue in the world. Nothing will stop. But something to keep on top of. — Reply to this email directly, view it on GitHub <#372 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFO7V3XF2RGPYIRZYB3XIY3Y7RZ7NAVCNFSM6AAAAABGMLE7ASVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TENBZGY2DG> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[gabesargeant]

Hi, so looking at all the intersecting requirements from each, django, drf-spectacular. I think it's safe to let things version float with django pined at the current mainline version number 3.2.X

DRF has pretty wide support,
https://www.django-rest-framework.org/#requirements

with regards to drf-spectacular, the most useful feature, aside form the fancy swagger UI, is the schema generation feature which allows client side applications to generate their REST endpoints for interacting with the server.

DRF is slowly moving away from having schema generation as part of their main offerings, They suggest drf-spectacular, that's why I included it.
https://www.django-rest-framework.org/api-guide/schemas/

From looking at the DRF-spectacular requirements I think things should be fine.
https://drf-spectacular.readthedocs.io/en/latest/readme.html#requirements