Re: Foodsoft Docker PR

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Foodsoft Docker PR

wvengen
Administrator
On 04-08-17 08:00, Dan wrote:
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 [1] + foodsoft-shop client [2], 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 things.
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 Foodsoft API.

Hope this answers your question and gives a bit of background, at least from my point of view.

- Willem


[1] https://github.com/foodcoops/foodsoft/pull/429
[2] https://github.com/foodcoops/foodsoft-shop

(*) 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.