I have created a new repository called “web-api”.
Of course we’d use Python to develop the web-api, but is FLASK the framework we want to use? I know that David used FLASK. I just didn’t know if there were other frameworks we should consider. I’m more familiar with JAVA based frameworks such as Spring/Boot.
I would definitely suggest to use Flask since it’s lightweight but powerful, actively developed, and has many useful extensions (in particular one for building REST APIs). It also has a much shallower learning curve than Django, which I think would be overkill for this.
2 Likes
Hi all, after re-reading this thread, I noticed that I had missed a few questions/comments partly directed at me, apologies.
That could be very handy for people (like me) who want to try using R for some data analysis and presentation.
For that I don’t think an API is necessary. In fact I use Jupyter (with Python, but you mentioned you can also call the Python code from R) directly with the Gramps Python library to have fun with data analysis & visualization. This will become even easier once Gramps becomes pip-installable, which will allow doing this in a virtual environment.
Have you considered the possibility of keeping the WebApp a multi-user ‘Read Only’ database tool but adding a Feedback form that sends free-form edit suggestions to the webmaster?
That’s a great idea for allowing contributions from relatives but not trusting them with making direct edits (I see a lot of motivation for that)! I think this is “only” an issue of permissions and UI: it can be handled within Gramps as a note with a certain tag (TODO or something like that), so one would only have to make sure that a certain user only has API permissions to add new notes. The rest is “just” the UI implementation.
To me, this would be broken into maybe 3 parts - the web GUI (design), the API design, and the back-end (core) GRAMPS database. We’d want to be able to leverage as much from the existing core Gramps as possible, but I think most of it is GUI/front-end work, that would need to be totally re-done.
Fully agree. The backend should be almost completely covered by gramps.gen, but one could make minor additions that make the use for the API easier without affecting the desktop app (such as this one). Concerning the frontend, I am working on one, but the great thing about a common API would be that there can be multiple different approaches/apps. Whether an “official” one will emerge I am not sure. At the moment it seems a bit too ambitious to me.
If our databases became accessible from the web, most definitely the owner would be able to set it as read-only. As far as being able to update a database from multiple users…I know most genealogists cringe at this idea, but if we could develop in a way that tracks changes, and easy revert, or like GIT where people can submit changes, for review.
If I think about my own use case, I would definitely want to keep it read-only for most users, perhaps allowing the “feedback as note” suggested by @emyoulation above. But I do see a use case also for allowing full edits - for instance, by myself when I’m sitting in an archive and don’t have my laptop with me. Or maybe for one or two select genealogists in my wider family whom I trust.
Having versioning with possible rollbacks is certainly intersting, but to do this in full generality seems too ambitious to me as it would probably require major changes to the database model, with no benefit for the deskstop app. More realistically, one could enable automated XML exports on every edit. (One could even think about making a pretty visualization of a diff between two Gramps XMLs, maybe somebody has already done that?)
1 Like
It is overly ambitious but … how about thinking beyond comparing 2 XMLs towards some histogram features?
(The Import Merge Tool basically does a DIFF and then offers accept/decline. It’d be kinda nice if there was a way to save just the DIFF so options for dealing with it via automation … or manually in piecemeal fashion … could evolve.)
The auto backup does timed iterations of our trees. Diagramming the change patterns would tell us a lot about our productivity. The history in page edits in the wiki, the diffs the GitHub produces; both of these widen our perspective of the data. And even the calendar views of Windows Restore Points & Wayback Machine page capture help us understand how well we track ‘change’.
There is already a report that does a diff compare Database Differences Report addon. In fact the import merge tool uses some of the same underlying code. But of course using this report in some sort of automation would be difficult at best. As usual, choosing a standard for such a purpose is the real problem.
1 Like
I do that a lot, and was one of the main reasons for me asking for an interchangeable graph file format…
Something that noone saw any point doing, it was an useless suggestion.
I also use Graph software to find connections over multiple nodes bewteen people that you normally don’t see any connections between.
Graph visualization and network graphs that show more than “just the family” is a great tool for finding new clues or even find connections that can’t be seen in a Table View or in a “Family Tree”.
Another thing is that if users shall be able to use this type of features, it must also be available on Windows and MAC, and it must be without the demand of having a degree in Python development for “normal” users… Ask “Normal” users about Docker, and they don’t have a clue what you talk about.
A lot of developers seems to “forget” or deny that there is people using Gramps that do not use and never have used Linux, and that many users do not have any knowledge about Python programming/scripting.
1 Like
Oh, you resuscitated an old thread which has partially been made obsolete by the developments on the Gramps web API 
Concerning write access to the Gramps web API, there is an open issue here:
My dream for managing synchronisation of a web-based database with multi-user write access and my local Gramps databse would be modifying @prculley’s Import Merge Tool for that purpose. It’s really powerful and I think it already contains all the necessary logic. After all, this is not too different from how commercial web-based genealogy services with Desktop apps work. There is an issue to discuss this here:
Another thing is that if users shall be able to use this type of features, it must also be available on Windows and MAC, and it must be without the demand of having an degree in Python development for “normal” users… Ask “Normal” users about Docker, and they don’t have a clue what you talk about.
A lot of developers seems to “forget” or deny that there is people using Gramps that do not use and never have used Linux, and that many users do not have any knowledge about Python programming/scripting.
I’m not sure what you’re referring to here. I agree of course that Gramps should be usable on Windows and Mac. I disagree though that a web app backend should run on Windows and Mac. If a user does not know Linux or Docker, they should not be setting up a web app. Why? Because it’s easy to screw up big time when you don’t know what you’re doing. For instance, set up the app without SSL and it will be trivial to spoof the access tokens, gain full control and delete stuff (or publish private stuff).
That doesn’t mean that less technically proficient users should be ignored. On the contrary! I started the whole thing also to share my research with people who I’m not sure are technically proficient enough to install Gramps 
But IMO the way to make this (the Gramps Web API and everything based on it) more accessible is not by making it run on Windows, but by offering a hosted service.
1 Like
I infected this zombie thread cuz it was where someone mentioned testing this with a Raspberry Pi! 
And the thought of a Pi faced Gramps just gives me the giggles.
But I also really like the idea of taking a NAS attached to a WiFi load-balancing Pi array to a family reunion and claiming that the Pi was my contribution to the snack table. Then all the cousins would be able to access the data with their phones & tablets during the reunion. [Come to think of it, that means more people would be obliviously absorbed be their gadgets too. Another winning reason for the introvert shamed into attendence.]
1 Like
Right 
Btw my own instance is running on a Pi. The Web API repository has a Github action that builds x64 and ARM docker images and pushes them to DockerHub on every commit (see here gramps-webapi/image.yml at master · gramps-project/gramps-webapi · GitHub), so you can do docker run ... dmstraub/gramps-webapi:latest on a Pi without problems
I then use a Docker-Compose similar to this one, adding letsencrypt-nginx-proxy-companion for SSL.
1 Like
who would support the Hosting service for those not so technically?
This is a weakness of the Gramps Web API approach compared to other solutions, e.g. webtrees, or even Gramps static web reports. As stated somewhere above, in my opinion the solution to this is to offer a hosted version.
in the Hosting scenario, would the user have to copy there database to the Hosting Site, or would it be a connection to a offsite database (and if so, wouldn’t the website go down if the users computer went offline or would the database be stored in a “cache” system on the server?
It would have to be copied. What we are missing to make this really usable in practize is synchronization.
Or would they need to export a subset of the database to a xml file and export that data to the web service.
XML ex-/import would certainly be the way to make the synchronization possible, but one could make it convenient via a sync button/dialog in Gramps desktop.
Where would the Hosting Service be, in what country?
For many users, it can be an issue where the data is actually hosted, we all know that there is a lot of American Hosting Services that don’t confirm to i.e. European rules regarding privacy etc.
My own tree is running on a Raspberry Pi in my basement. For me, that’s the optimal privacy. But of course that’s not the best solution for every user. A hosted solution will always be a compromise between privacy and convenience.
And seriously, to say that people not knowing linux and docker shouldn’t set up a web app? isn’t that a little ignorant?
Yes, you are right, that statement was too strong - I rather meant this web app. Having a Python web app (as opposed to, say, PHP) has many benefits (especially for Gramps), but deploying it is not one of them.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.