search

gramps-project / gramps-web

Frontend for Gramps Web
https://www.grampsweb.org
GNU Affero General Public License v3.0
381 stars 50 forks source link

Gramps Web API + Gramps.js = ? #49

Closed DavidMStraub closed 2 years ago

DavidMStraub commented 2 years ago

This is more of a strategic question than a technical issue, but I'd like to kick off a discussion about how we should evolve Gramps.js & the Gramps Web API in the next, say, 1-2 years. As described in this post, I think the projects have made really good progress in the last months, approaching a point where they become a broadly usable web app for collaborative genealogy.

I think it was a good choice having an app-agnostic and Python-based web API with as much reuse of Gramps library code as possible, and a pure Javascript frontend based on web components. This makes it much easier to spawn new projects if someone feels like it (a mobile app with the web API as backend, a different frontend reusing some of the web components, ...), or to get rid of some parts when it turns out they are not needed anymore.

However, from forum/issue discussions and from trying to come up with an understandable documentation, I am getting the impression it is really hard for users to understand how it all fits together. And it would be a pity scaring off potential users by requiring them to delve into architectural issues they shouldn't care about.

So, while I wouldn't change anything about the project layout, I would suggest some changes in presenting the project(s).

Apart from simplifying documentation, having a single name for the app would also allow to do some things that would make it easier for potential users to find and adopt the app:

Thoughts?

@Nick-Hall, @cdhorn, ...

cdhorn commented 2 years ago

That seems reasonable, to make it a formal part of the Gramps organization and call the combined solution the "Gramps Web UI" or something to that effect.

Mattkmmr commented 2 years ago

We can give a name to the collaborative genealogy web app that is Gramps Web API as backend and Gramps.js as frontend.

@DavidMStraub For simplicity there should be only one name for both components (frontend & backend) which is communicated to users. The name could start with "Gramps" so users can easily recognize it as a part of gramps-project as @cdhorn already suggested it. The second part of the name could be the plattform, so users can easily understand where they can use it.

Example naming scheme:

Set up 1 click hosting for XXX [...] it would allow users to host the app without worrying about setting up Docker.

That would be perfect for usability.

DavidMStraub commented 2 years ago

Yes, I agree Gramps Web would be a fitting and catchy name.

Since we're all interested in history :wink:, some related historic names of stalled projects:

Nick-Hall commented 2 years ago

Doug Blank came up with a few suggestions in his post "First pass on a Django Data Model complete" from 2009.

The Gramps Online project never progressed very far.

DavidMStraub commented 2 years ago

So, my suggestion to proceed would be as follows:

:+1:/:-1:?

emyoulation commented 2 years ago

On a strategic level, what is desired?

If you want it to really take off, there needs to be a path for commercial cloud farming... like MediaWiki allowed Internet Service Providers to farm WIKIs. (Or the way WordPress & Drupal CMS server farms came into existence.)

Those ISPs get paid for providing a blank ready-to-populate wiki site, the labor maintaining/updating/archiving the MediaWiki framework, helping clients troubleshoot add-ons, restoring from backup, there are scalable fees for the bandwidth, storage capacity, pipeline diameters. The novice clients only worry about gathering & uploading content and tweaking themes.

So, what do we get? Optimization.

Profit is not our motivation, but it is theirs.

Every unnecessary minute doing maintenance, every burned cycle of server processing, every avoidable byte of FTP, every redundant byte of storage costs an ISP sweat & money. So their CTOs analyze how to make farms more efficient/profitable and workers find ways to make the work easier.

They might work on making Gramps source Pyjion compatible for better speed on .NET servers. They might write DB backends for high-performance DB engines. They might write tools for Media synchronization with delta-compares to minimize FTP. They might write a tool to collate Media scattered across a local network to a hierarchy in a single FTP folder. They might make images of Gramps installation to repair a corrupted Gramps core without affecting content, themes or continuity of access. They might find ways to make a Gramps handshake with a blank (or outdated) online Gramps instance and fully populate it with a single "synchronize" click. They might find a way to make an upload work in the background... flowing initial data in JIT fashion. So that a new user can see just enough data to work on configuring the look&feel of their online presence while the remainder of the tree uploads.

(PortableApps has done some admirable work divorcing Gramps data & plugins from fixed paths under 32-bit Windows. Hopefully, this will roll back into the main. Adding portable Linux, macOS, & 64-bit Windows versions would allow a single DVD/Thumbdrive to archive a person's Genealogy Research which would be accessible on any computer without any installation.)

Gramps has scalable online solutions making Gramps attractive to ISPs for upselling services to clients:

For the future, it may be necessary to look at how the web version of Gramps will have to evolve to minimize maintenance downtime.

DavidMStraub commented 2 years ago

Hosting & deployment are important topics, yes. An end goal could be to have a shared server hosting many trees at once. This would minimize the cost for the individual user. But in the near term, I agree the goal should be to make it as easy as possible to host a single instance in the cloud. The challenge is a bit different from MediaWiki or Wordpress since we can't run on a usual PHP + MySQL stack, but we need docker hosting. I think PhotoPrism is a good example how to do it, see here for their documentation of DigitalOcean 1-click app hosting.

However this is a bit off-topic for this issue - let's hear @Nick-Hall's opinion about the proposal above: https://github.com/DavidMStraub/Gramps.js/issues/49#issuecomment-977154961.

We can continue discussing deployment options over at https://github.com/gramps-project/gramps-webapi/issues.

Nick-Hall commented 2 years ago

I don't mind creating a new repository for the front-end code. We could even promote it as a recommended application.

Why do you want to remove the API documentation? This would be useful for anyone developing their own web application.

DavidMStraub commented 2 years ago

Yes, I fully agree the documentation is very important. The suggestion is to host the user documentation, backend and frontend development documentation in the same place (web.gramps-project.github.io). So the docs directory would just move to another repository where also the frontend docs would be added.

Nick-Hall commented 2 years ago

OK. Whatever is easiest for you.

DavidMStraub commented 2 years ago

@Nick-Hall, I tried to transfer the Gramps.js repository to the gramps-project org but it didn't work as I don't have permissions to create public repositories in the organization. Would you mind granting this permission to all organization members? (https://docs.github.com/en/organizations/managing-organization-settings/restricting-repository-creation-in-your-organization) I could then transfer Gramps.js and also set up the new gramps-project/web documentation repository.

DavidMStraub commented 2 years ago

The repositories have been moved/created and I started reorganizing the documentation on the new documentation site: https://gramps-project.github.io/web/. Closing this issue!