Can you program apps or extensions? New API examples on GitHub.

Question

Hi WikiTreers,

This is for those of you who have programming skills and might be interested in developing apps or extensions.

First, I want to say a few words about our vision for WikiTree and its future development. Our mission has remained the same for 14 years: To grow an accurate single family tree that connects us all and is freely accessible to us all, forever.

This is a big mission, but there is no big corporation behind WikiTree. The team is tiny and mostly part-time. We want to keep it that way for a long time to come. I think that becoming a large company or becoming part of one would be bad for our tree. The community would have a smaller voice in decision-making, and bad decisions would be made because of it. WikiTree would get worse over time, instead of slowly getting better, as we have since 2008.

Since the team is so small, we need to keep the core of WikiTree fairly simple. We can't develop and manage too much in-house. But community members are constantly finding needs for new features and functions. So, we want to make it increasingly easy for community members to create and manage apps and extensions.

To that end, we just released new sample code and explanations on GitHub. Check out https://github.com/wikitree/wikitree-api

You can see all the current examples here: https://apps.wikitree.com/apps/wikitree-api-examples/

We hope to add more examples soon, with your help.

We're also working on something else. One problem over the years has been how to integrate all the various apps with the core of WikiTree so that it's easy for users to navigate between them. 

Jamie Nelson is now working on a new version of our Dynamic Family Tree, which was itself originally created as an app many years ago by Justin York. The dynamic tree is entirely open source and we want to make it collaborative. We envision it being regularly improved upon by the WT Apps community, and more importantly, that it become a hub for navigating between independently-developed tree views and other apps.

If you're interested in coding and improving our single family tree, please join the group.

Chris

Comments

Chris, I may be slower than most, but when you say you're working on "how to integrate all the various apps with the core of WikiTree so that it's easy for users to navigate between them," I'm not really sure what that means in practice.  Is the dynamic tree the "core"?  Will it necessitate some rework of the apps we have now?  I wonder if you could expand on that a little bit, and perhaps cite an example or two of the type of problem users now experience that you would be solving?  Thanks!

---

Chris, I wouldn't be surprised if the majority of WT members are not sophisticated app users.  (It took me a long time to begin using even one.)  What can be done to make sure they are not left behind?

---

Chris, I'm interested to learn more, and will be digging in - my coding experience is with less modern languages, so it will be a higher hill to conquer. I am interested to know if there is any thought to convert the underlying database and code to handle UTF-8 - our tree will not be very global until we can handle characters that are commonly used in the names on the tree.

---

Dennis, the distinction between the "core" and "apps" is blurred by the Dynamic Tree. That's essentially an app. It uses the API. But it's on the main server instead of the apps server. The Dynamic Tree has always been open source but there's never been a development community for it. Justin York wrote it. We integrated it. Now Jamie is rewriting it. Soon after the rewrite we want to adjust its user interface so it's easy to switch apps without switching profiles/trees. You can already do that with links on the Family Tree and Tools page for profiles, but hopefully this would be a little smoother for switching between tree views. Greg Clarke made a great start on this for his fan chart app. I think we'd follow his lead.

Julie, you should always feel free to ask in G2G about apps -- how to use them, and what you'd love to see done in the future.

Duane, welcome! Almost all our code can handle UTF-8. Maybe ask a new question about a particular problem you're seeing, and we'll make sure it's on the to-do list to fix.

---

Thanks for the shout-out, Chris!  

Kudos to the team on the new API documentation - well done and organized.

I just re-read your post, and I think I'm seeing some very cool potential with the Dynamic Tree - would love to be able to seamlessly switch from the Dynamic Tree view to the Fan Chart view to a couple other apps that I'm currently working on ... Looking forward to this!  Count me in when it's time to collaborate!

Answer 1

I am a s/w developer of some 30+ years. There do not appear to be any design documents - just code. All  the code shows is what it does - it does not show what it is supposed to do. You cannot even test code unless you have a definition of what it is supposed to do.

Where are the design documents showing database structure, logic flows, objects used in the system. Hopefully you have  some ;-}

Comments

I do not know of any design documentation. The easiest is to get access to the datadump and study that. There is also the -limited- talk on the google mail group.

Does this page help? https://www.wikitree.com/wiki/Help:API_Documentation

---

I don't suppose there is even a proper test data set, or an automated test suite! Are changes made to the live system, or is there a development system and a test system?

---

Perhaps someone should attempt to write some! Otherwise you will be in big trouble, pretty soon. In my experience you can't have many developers working on a project without excellent design documentation.

---

I agree - how would you have that - if there is no design documentation to say what is supposed to be done,how can it be tested against anything.

---

Are you guys talking about contributing to apps, or to what we call the core of WikiTree? The core is not open source. See https://www.wikitree.com/wiki/Help:FAQ#Is_WikiTree.27s_software_open_source.3F

What we're envisioning is that the Dynamic Tree, which uses the API and is essentially an app, would be open source and collaborative. (It's always been open source, but never really collaborative.) To collaborate effectively with more developers, I am sure you are right about what we need to do. We're just not there yet, so please be patient and help get us there.

---

Lol, apparently Philip has never worked at my company! We have no real requirements, other than be completely backwards compatible to the undocumented existing products.

I agree, documentation, automated test suite, and all that are important. You can get around that if you have a small group of long-term people who have "tribal knowledge" as we call it. But bringing in new people to the tribe, or losing an existing member is a major problem without good documentation.

---

Well said. That is particularly true where it is a volunteer 'work force' not subject to the legal constraints of employment etc.

Also, unless one has knowledge of the data structures etc. it is impossible to know how efficient the structures are themselves, for their intended purposes. The same applies to the algorithms  accessing them. That is a major concern for any system with an intended long 'shelf life'.

Security issues are another matter - just because one publishes data structures etc. does not necessarily make them more vulnerable to 'attack' - security lies at a different level of abstraction.

---

I would recommend some way to organize. I like the Epic/Feature/Story setup. I was looking over things and it seems there are a lot of fluff still hanging around and no where to really see what is going on.  Need a tool to help manage that backlog with the stories and prioritizing. Doesnt mean a volunteer programmer cant focus on what they want but it does help everyone see what the Product Owner is wanting to accomplish.

---

UML models would be useful.

Answer 2

I hope you're open to pull requests.

I note your python example is Python2 - which is end of life.

I have a fork with the beginnings of a more up-to-date python interface.

Comments

Yes, the reason we put it on GitHub is so others could add examples :)

---

Pull request submitted, though I notice another for a similar purpose.

My python example goes through all API calls, the other is just authentication. Both are useful examples.