I built a web based prototype for an application using a Docker microservices architecture:
postgreSQL, redis, traefik, etc. - the regular stuff - which works great.
Now, the application's usecase is actually better suited in a offline environment with a standalone executable,
and I'm struggling to make this transition.
(How does the app work?
Think of the application as a file indexing system: you specify a folder on your local hard drive and the program will analyze the files (might take up to 30 minutes) and store metadata for it in a search-optimized datastructure.)
From what I understand most applications also separate frontend and backend layers and let the processes communicate via message passing
over some form of channel and protocol. The solutions I found include Unix Sockets with gRPC (https://docs.microsoft.com/en-us/aspnet/core/grpc/interprocess?view=aspnetcore-6.0), local HTTP Servers with a REST API or gRPC, even
JSON over stdin/stdout (https://github.com/xi-editor/xi-editor).
Solutions for datastorage include custom file formats, sqlite databases or bundled mongodb instances into the main application.
I figured out the backend part with analysis running multithreaded and writing into a sqlite database.
For the IPC I spawn a gRPC Server which clients connect to over HTTP/2.
That way I compile a platform agnostic backend and platform specific frontends.
It all works okish but I feel like it's unnecessarily complicated and there could be a common strategy I am missing.
*TL;DR: What are modern architectures for desktop applications equivalent to a microservice architecture with backend/frontend separation, message queueing, pub/sub, authentication, ...?*
In general it sounds like you're working too hard to introduce a strict process separation between the UI and the backend. A desktop application won't have multiple clients connecting to the backend, so you can run everything in one process. That's the use case for which SQLite is designed.
Your UI framework may introduce some level of process separation anyway: if the UI is a WebView or Electron, then it's going to run the renderer in its own process. So there's no need to go crazy with splitting up into tiny little services.