New frontend framework such as Angular/React/Vue/etc?


#1

I am working with Jaspar on a funding bid for an app he wants to develop for Locafora and Voetselteams. He had a technical question about how feasible it would be to link his new app to OFN. I do not have the tech knowledge to answer his question so have invited him to the OFN dev mumble on Thursday. Here is some background on his question

From: Jasper
Sent: 28 August 2017 15:31
To: Iris van de Graaf
Cc: nick@nickweir.co.uk; Bram Bergkamp
Subject: Re: Eurostars Open Food Network

Hi all,

Some background to what I was talking about in the call:

  1. Our current focus is on a subsidy provided by Interreg. This subsidy has an ‘exclusivity clause’: the subsidized intellectual property created through the funding must belong to the organization funded and be usable exclusively by that organization, creating a competitive advantage. This clashes with the AGPL license of the Open Food Network.
  2. The current OFN implementation/architecture is based on a tightly coupled model (back-end and website are directly linked). A mobile app requires a decoupled architecture (REST-ful). The OFN REST API is currently a second-class citizen compared to the website and seems to be mostly focused on third-party integrations rather than user functionality. Should the REST API be required to offer the same functionality as the (tightly coupled) website, this furthermore means that two models (tightly coupled website + decoupled through an API) will have to be supported and kept in sync simultaneously. In our opinion something can be said for then rewriting also the frontend website to a decoupled model, using a frontend framework such as Angular/React/Vue/etc.
    Best regards,

Jasper van Veghel


Enabling OFN to integrate with external systems (POS, standalone websites, Odoo ERP modules, other plateforms with DFC sandard, etc.)
Imagining the perfect platform / ecosystem session - Friday 8 Dec
#2

worth looking at the USA planning thread and what Greg (? i think) is doing in Colorado . . sorry, replying from email so don’t have direct links, but I think a conversation between them could be very enlightening. If you could respond and ping the right people would be great @nick!!?


#3

Thanks Kirsten. Yes @NorthernColorado please can you comment on this and link jasper@seajas.com in with your plans


#4

Here is an email from @iris who is working withJaspar. @NorthernColorado please could you update us on your plans. Thanks Nick.

This from @iris :
Jasper, Bram and me were discussing the options for working with OFN. We think that our main question is, if OFN is willing to:

  1. Rewrite the frontend to a purely decoupled model, using a frontend framework such as Angular/React/Vue and a REST API. This will allow us and others to then write other frontend (such as apps) as well, as all of functionality of the website would be available via a an API. This would include all information available via the Spree API but also everything specifically OFN-related, along with user authorization and so on.

  2. OFN is willing to consider relicensing to an LGPLv3 license instead of the AGPL license. This will allow us to develop our own platform on top of OFN where we contribute changes to the OFN back-end but create a frontend unique to us. This would go a long way to satisfying the exclusivity criteria of our sponsors.

These are fundamental questions. As we understand it, all frontend development on OFN is currently done with the use the (Spree) API and under the AGPL license.

Is it possible to get an answer to the above questions?


#5

Updating the frontend stack could be interesting actually, but we need to talk about both Spree and OFN API first IMHO.

This is something that we’ll need to face anyway since more recent versions of Spree go in that direction.


#6

I’ve just read this more closely and realised that there’s a pretty ‘big deal’ legal question in there as well re. license.

If OFN is willing to consider relicensing to an LGPLv3 license instead of the AGPL license. This will allow us to develop our own platform on top of OFN where we contribute changes to the OFN back-end but create a frontend unique to us. This would go a long way to satisfying the exclusivity criteria of our sponsors.

These are fundamental questions. As we understand it, all frontend development on OFN is currently done with the use the (Spree) API and under the AGPL license.

I am not sure that the license change would actually be needed if you build your own front-end e.g. if it was a separate system calling OFN API then I don’t think OFN license would apply to it anyway. But if you’re asking OFN to rewrite our own front-end to make it easier for you, then obviously we want to retain full license over what we write for our front-end! and we would want to be able to use that new front-end to adapt for other people as well. hmmmm.

I think that if people want to have that discussion someone should ‘present’ on it as next global hangout? and see if people think its something worth considering or not? @nick @iris @MyriamBoure @tschumilas @Joel


#7

From Coopdevs/Katuma we suggest the following actions:

  • keep AGPLv3 license for all the code already written and all the future code written by the community
  • develop a good OFN API (Spree API + OFN specific API) with AGPLv3 license
  • anybody will be able to develop its own frontend with whatever license they need (unless they mention OFN or use its code in any way) and point it to the OFN API

#8

@iris please can you forward the conversation above to Jaspar (or even better ask him to join this forum). Also you or Jaspar are welcome to add this topic to the agenda of one of the following two meetings and then lead the conversation at the meeting.

If you think it needs a technical conversation then details of the next OFN dev meeting are here https://docs.google.com/spreadsheets/d/164AIN1zow3OhvGJfPE5GWnPYmZNFGgznF4ThQPJV_To/edit#gid=1951824240

and/or if you think it is more of a strategic conversation about the direction of OFN then this is a more relevant meeting https://docs.google.com/spreadsheets/d/14TJgSejLlq_f4qe9bbsalTHevwuBRsNGX5SHJEdN21U/edit#gid=338251776


#9

I think we do want to go in that direction, as IMHO the product vision we have is to enable any user to have it’s own website and integrate the modules she needs in this frontend, in their own specific design. I don’t know at all about what we need technically to achieve that vision.
About licencing, I’m not familiar with those… I found very interesting those summaries of AGPL and LGPL
From my understanding, if we want to encourage the development of free softwares, I guess we should stick to AGPL, and also I think we have to given that multiples servers deploy our code. The only case when LGPL can be useful is if there are other similar solutions to the one we propose, so if prevent proprietary software to use it, they might choose the other solution, and it would not be (maybe) our interest as it would prevent the development of our solution.
@Kirsten From my understanding, if you create just a front end and plug it to the OFN local instance server, you don’t make any new version of the OFN, you just plug to the server and call data through API, which in my understand doesn’t require any change in the licence.
But I think there is a different if a white label user make his own deployment and customize things in the source code (fork) then he has to share under AGPL licence, which I think is good. You can still contribute to changes i the back-end / common source code of the OFN, which will still be distributed under AGPL.
So, again from my understanding, I think we can stick to AGPL. But maybe I didn’t get the whole point :sweat_smile:


#10

hi kristen. I am writing something that just relies upon the database rather than the whole application spree and ruby stack requirement. I anticipate a way to have a the most basic features available for low cost both hosting, setup, and updating / management scenarios. My work has kept me in the anglar4 /ionic3 app development world, I imagine having a free plugin to existing OFN sites, so they can export parts of the data they manage into ‘payloads’ which run quickly and inexpensively within the app.

For a better user experience. I also envision a desktop app (via electron) that talks to remote micro services which act as intermediaries between existing or future OFN (spree commerce) postgres databases people have.


Document our API
Road map for OFN's API?
#11

Hey all. I’ll briefly pitch in some thoughts on this topic from the perspective of using this to build a platform such as Locafora and Voedselteams.

First of all, short of rewriting the entire back-end, the AGPLv3 license will have to stay lest all contributors agree to relicense. What I believe is a good compromise to this, is to refactor the OFN back-end to be just that—a back-end. It would no longer have any kind of front-end, but would instead expose all functionality via a well-designed REST API. The front-end can then be refactored with a decoupled approach, with e.g. Angular/React/Vue/etc. under the AGPLv3 as well. Similar to the approach mentioned by @enricostn, but with the extra step of splitting out all front-end code.

The benefit of making these two absolutely separate, as opposed to also maintaining a tightly coupled front-end within the same codebase, is that no functionality will have to be implemented twice or kept in sync. All back-end functionality would only exist in a well-designed and well-documented REST API. From an AGPLv3 perspective this then becomes a pretty reasonable network boundary, as the purpose of the back-end software will be to facilitate a REST API only.

This approach would then allow for frontends to be built under different licenses as well. Locafora and Voedselteams will be able to build a front-end (e.g. an Angular/Ionic app similar to @ecocity) which meets subsidy requirements from Interreg (solution has to be competitive). This would still give back well-documented and (reasonably) generically implemented improvements to the OFN back-end. And also allows Locafora/Voedselteams and others to pick and choose which OFN functionalities they would like to use or not use, rather than keeping (and obscuring) the whole range of features offered by the OFN platform.


#12

@jasper :thumbsup: more thoughts on “splitting code” in my comment to this thread Towards a microservice architecture?


#13

I like this description @jasper and I guess that doesn’t prevent local “public instances” to also offer the current frontend on their Saas offer. Or build any other frontend if they want. I’m not a tech person so I don’t know the details on that, but I have the feeling that would serve our vision to allow multiples standalone websites to connect to the OFN back end deployed as a mutual infrastructure that multiple front ends can connect with. @Augustin maybe that can fuel also our OFN evolution vision :slight_smile:


#14

@balessan that’s about our discussion.


#15

For the communities i work with in the US and Kenya, having a JAM stack type of ( JAvascript- API, Metadata) system can cost $0/ month to run. This is the kind of budget that vulnerable communities can afford, so I am pursuing a decoupled stack that simply uses Firebase for authentication and back end primary service, with React as front end. I am using netlify to build my prototype. It is being done with spare time as-can do it endeavor.


#16

my approach has been to inventory the interactions and features of OFN from the documentation and to use screen shots as a reference for building the forms and data bindings… I dream of efficient ( and super secure ) software.