This post follows on from Global groupware requirements, which describes the software a lot of people seem to be looking for. The distinction between a website with content and a web application is becoming sharper, and its clear that systems in the paradigm of content management (like Wordpress and Drupal) are not optimal for social organising.
I've been convinced for a couple of years by another approach proposed by David Bovill, namely that REST microservices are the way forward.
Web 2.0 involved building large back-end systems like Drupal, which generated and sent full web pages to the browser. All the features you wanted in an app had to be implemented in the same framework running on the server. As we move towards app-based architecture, apps manage the user experience completely on the device, i.e. the mobile phone or tablet, and they pull and push data as needed and render it in the User interface.
Architects of heavy duty systems like Twitter have turned to microservices because they scale well - each service can live on an optimised server. But David's sees a different value in them because they make it possible for different organisations who want to be interoperable but who have different brands and different functional requirements to share code and and become interoperable. For example you could have a calendar microservice which allows users to add events to a database. The events database can be visible to other groups using that microservice, or the microservice might offer a federated search. Other groups might not want events, but they could still find each other.
Furthermore, each microservice can be written in a different language, and they can make superfast REST calls to each other, which means any volunteer developer who comes along can contribute.
I recently started to realise though that this approach isn't as simple defining an API for each function, writing the front and back ends and switching them on. Though individual microservices are likely to be relatively simple scripts, they won't operate entirely independently and will more likely depend on and refer to each other to some extent. For example any posting like a calender entry will want to reference the name of the person who posted it. And certain configuration options, (which could be in any microservice), might need to go through a governance process, such as a vote by committee members, to be changed. So before we could start bulding microservices, we would need some kind of a core, and an API for communicating with that core. Features like:
- Allow disallow search bots
- Translation interface
- Download data backup
- grant & retract user roles.
- message all members
- Need multiple channels to contact members, e.g. whatsapp, Telegram, Email, Discord
- Edit the menu
- Edit the contact email for the site admins
- invite a user
- Store and access files like pdfs and working files in a common space.
- Compose newsletter
- Member notification options. (personal digest module)
- manage categories
- create a new photo album
- Admins can keep private notes on users
- Edit the email footer
Commercial platforms like Liferay and Mulesoft have various answers to these questions, but we will only consider open source! David has proposed a new project called Platform Earth which aims to create this open source core. So I have my fingers crossed, but I'm not holding my breath. It will only work to the extent that the organisations who (I think) want this stuff, get engaged.
Comments