Dodanie interfejsu webowego do aplikacji w C++

0

Nie jestem pewien czy to dobry dział ale zagadnienie jest interdyscyplinarne.

Mam napisaną aplikację w C++ która załóżmy, że chodzi na Raspberry Pi i odczytuje temperaturę z zewnętrznego sensora i loguje ją do pliku (tzn. naprawdę mam taką aplikację ale problem rozpatruje też pod kątem bardziej zaawansowanych zastosowań).
Chciałbym dodać do tej aplikacji serwer i interfejs webowy który pozwolił by na żywo pokazywać temperaturę, pokazywać dane historyczne itd.

Od razu dodam, że na tę chwilę nie interesuje mnie przepisanie aplikacji na inny języku typu Python czy Go nawet jeżeli mógłbym to w nim napisać o wiele szybciej (załóżmy, że mam ograniczoną ilość pamięci albo interfejs do odczytu wartości sensora jest tylko w C++).

Mam kilka pomysłów jak do tego podejść:

  1. Dodać do aplikacji WebServer/framework dla C++ (np. RESTinio, RestSDK)
    W tym wypadku cały backend jest w C++, front w HTML i JS. Serwer wysyła po HTTP statyczne pliki (.html i .js), a używając np. protokołu WebSocket front pobiera dynamiczne zawartości np. aktualną wartość czujnika.
    To rozwiązanie wydaje mi się najłatwiejsze do zaimplementowania (bo tworzyłem już serwer w C++, musiałbym tylko ogarnąć JS na froncie na podstawowym poziomie)
    Z drugiej jednak strony mam wątpliwości czy na dłuższą mętę dobrym pomysłem jest "rozbicie" interfejsu webowego pomiędzy JS i C++.
    Przykładowo, jakakolwiek zmiana na interfejsie pomiędzy fronendem i backendem powoduje, że trzeba zmienić i przebudować aplikację serwera. Dla prostych aplikacji to nie problem ale w większym projekcie może to być bardziej skomplikowane. Dodatkowo, development backendu prawdopodobnie może być szybszy/przyjemniejszy używając języków innych niż C++
    .
    Zastanawiam się więc na innymi rozwiązaniami gdzie użycie C++ jest ograniczone tylko do tego co niezbędne (odczyt sensorów). Niestety tutaj wypływam na nieznane mi wody...

  2. Widziałem gdzieś rozwiązanie w stylu serwer w php generuje html/js dla frontendu + ajax dla dynamicznych zawartości (chyba) a z drugiej strony poprzez php extensions woła kod w C++.
    Alternatywnie nawet nie woła bezpośrednio aplikacji C++ tylko komunikuje się przez jakiś interfejs IPC dla większej elastyczności (to dotyczy chyba każdego rozwiązania).
    Wydaje mi się, że to jest dosyć elastyczne rozwiązanie jednak (przynajmniej na tę chwilę) raczej zbyt skomplikowane.

  3. Inną opcją jaka przychodzi mi do głowy jest backend w JS (Node.js lub jakaś lżejsza alternatywa) z jednej strony komunikujący się z frontem w JS (np. po WebSocket) a z drugiej komunikujący się z interfejsem w C++ poprzez:
    3a. IPC np. sockety, dbus
    3b. Znalazłem coś takiego: Ducktape (" You can also build the main control flow of your program in ECMAScript and use fast C code functions to do heavy lifting."). Ale jeszcze nie wiem czy można to sensownie połączyć.

Czy są jakieś inne lepsze rozwiązania? Jakie rozwiązanie wydaje się najsensowniejsze?

Na razie planuje zacząć od opcji pierwszej ale docelowo będę raczej celował w opcję 3 więc zwłaszcza sugestie do niej są mile widziane :)

2

@btw było trochę wątków w podobnym temacie ostatnio, np. https://4programmers.net/Forum/C_i_C++/335893-biblioteka_do_rest. Przeczytawszy to zdanie:

Mam napisaną aplikację w C++ która załóżmy, że chodzi na Raspberry Pi

Powtórzę swoją sugestię dotyczącą biblioteki mongoose. Jest napisana w C, ale używa się tego mega przyjemnie no i integracja w jaki kolwiek projekt jest banalna, kopiujesz dwa pliki do projektu i masz łatwy w użyciu serwer z niemałymi możliwościami.

1

Ja tam kiedyś się uparłem, że frontendu nie ruszam, aż przyszedł czas w którym musiałem zrobić aplikację powiedzmy "hybrydową". Nie wiem czy dokładnie o to ci chodziło ale w mojej apce musiała się wyświetlić mapa google, sęk w tym, że miała korzystać z JSowego API i żadne inne rozwiązanie nie chodziło w grę. Wybranie lokalizacji miało dawać sygnał do backendu napisanego w C++. Bardzo fajnie radzi sobie z tym Qt i moduły QwebEngine lub QwebView. Co prawda (jak to często w qt) oficjalna dokumentacja jest niekompletna i trzeba czerpać z doświadczenia użytkowników, ale tutaj autor bardzo fajnie sobie z tym poradził:

https://retifrav.github.io/blog/2018/07/14/html-from-qml-over-webchannel-websockets/

Jeśli myślisz o dystrybucji apki to polecam QwebView gdyż korzysta z przeglądarki jaką ma użytkownik. QwebEngine to właściwie kompletny silnik przeglądarki i nie potrzebuje zasobów użytkownika, jednak jak łatwo się domyśleć, jest ciężki, trudny w aktualizacji i z tego co wiem to Android może go blokować.

1 użytkowników online, w tym zalogowanych: 0, gości: 1