not sure which list this belongs in - i don’t see an application architecture list: one architectural change i think would help a lot would be to separate the functionality of interacting with the data from the application that interacts with it. basically, making sure there is a well defined api that can be accessed by any application written in any language. i haven’t taken time to investigate it yet - maybe it’s already defined somewhere?
Regarding a well separated frontend and backend, that's not how
Foodsoft currently is setup. When the project started, the tools to
have this clear separation were much less developed (in my view -
you could argue otherwise, but still I think this is one reason),
and Ruby on Rails first facilitated rendering HTML directly (with a
lot of ingredients to help with that). Now it's much more common to
have a clear backend-frontend separation.
A long-time wish of mine would be to make the Foodsoft backend into
purely an API, and have client(s) to interact with it. A first step
towards this is a partial Foodsoft API  + foodsoft-shop client
, which is nearing completion. Step by step.
I do see a bright future for an API-based infrastructure. It can
reduce complexity, make it easier for front-end developers to
participate (no Rails knowledge needed), and opens the doors for
different projects to work together. Foodsoft is one of many
projects that help shape a new kind of food system. APIs can make it
technically easier for those projects to integrate, allow client
developers to make tools that work with different services, or make
it easier to transition between them (*). This would require a
harmonized authentication and authorization solution, and many more
Nevertheless, I also see downsides to this. It is pretty easy now to
add something, provided you know some Ruby on Rails. Defining a
model, adding logic, and exposing it in the views is just standard
stuff without having to touch multiple projects. Also, the current
approach allows plugins to modify just about any part of Foodsoft,
without the need to touch the Foodsoft source code.
For the forseeable future, I think a mix will be present: some parts
are views in Rails, other parts are clients connecting with the
Hope this answers your question and gives a bit of background, at
least from my point of view.
(*) One example would be to allow a food cooperative to add products
from a farmer maintaining its assortiment into e.g. Open
Food Network; or may allow TransforMap to include foodcoops
for different food categories; or using Odoo for financial
transactions. Having APIs is not enough, but it can make it easier.