Do you have an integration guide?

[dlobo]

Hey folks:

Not really an issue, but wondering if there is a guide on how to integrate flow editor with other applications.

We are developers of Glific, also an AGPL 3 project and are integrating flow editor into our next point release (v0.2)

We are figuring things out and semi-reverse engineering it from your rapid-pro integration. While we are making fairly good progress (and yes, we'll document and blog about it for future folks, would be great if there is some document that we can access letting us know what API to implement for the asset server, how to config flow editor programmatically, tips and tricks etc.

Alternatively, if someone at Nyaruka is willing to walk us thru the above points, we'd be happy to document it and share it with the world.

Thank you for a great project and contribution to the wider community, much appreciated

[nicpottier]

Hi Donald. We don't right now, you would be the first to try to integrate it with an outside system. Happy to answer any questions you come across here.

[dlobo]

great. awesome and thanx for the quick response. We'll have a blog about our progress with incorporating it and our strategy by end of this week and we'll share the link here to get some feedback to ensure we are going down the right path.

[nicpottier]

Ok. Note that we aren't entirely sure how you plan on adopting the editor but not the engine as they are pretty well tied at the hip, but we'll do our best to answer any questions you come across.

Also can you share why exactly you are building yet another open source messaging platform?

[dlobo]

we wanted to use turn, but they were not interested in making their product open source. Based on some conversations with them, we felt that rapid pro did not meet our needs exactly (we might be wrong) for a whatsapp-centric platform (and hopefully signal in the future if possible). Happy to get on a call to discuss

[nicpottier]

RapidPro supports WhatsApp natively and manages national scale numbers. I'd recommend doing some more exploring of RapidPro before trying to create a new thing that is unlikely to take off in a crowded market. It is probably going to be a lot more work to try to integrate the RapidPro flow editor into some brand new thing rather than just extending RapidPro in whatever way you think is lacking. There are decades of person-hours in it to make sure it scales reliably and to make sure it fits the most number of use cases.

[dlobo]

thanx. we'll take another look also. besides rapidpro, what other open-source messaging platforms are out there?

[dlobo]

Just as a followup, our first attempt at documenting our learnings:

https://chintugudiya.org/experiments-with-rapidpro-floweditor/

The code has not yet been merged into master, hence no links there. We'll merge it into master in the next 24 hours or so and update the post

Thanx for your support and an amazing well thought out flow editor :)

[rowanseymour]

To reiterate what @nicpottier said, it still sounds like you'd be better off using RapidPro (or building something on top of RapidPro) than trying to reinvent the wheel here. It's all open source, you can host your own instance if you want. The editor works against a flow specification that the engine works against. That evolves over time as we add new features and tweak existing ones. If there's something that RapidPro can't do that is a deal breaker for you, open a ticket or send a note to the developer mailing list and we can discuss if it can be added.

[nicpottier]

I feel like you guys may be falling into the trap of mistaking having a prototype working as being most of the work required to complete a project. We are pretty familiar with that phenomenon because we went through it three years ago when we rewrote the editor and engine. It all looks pretty promising and quick to implement at first but then you realize how many edge cases there are and how many other pieces are needed.

Rebuilding an engine from scratch to execute RapidPro flows built in our editor is a silly task. Even if you want to tie everything together in a different ecosystem, you'll at the very least want to use the GoFlow library and build something around it to take care of execution for you. If not you will not only need to implement each of the actions and all the various ways they can interact, but also the entire expression engine and rules associated around that.

Using the editor without the engine is kind of the worst of all worlds in that you are going to present something that very much looks like it will have flows that can interoperate with RapidPro flows but subtly different enough that they won't. So instead of building on an ecosystem that already exists you will be fragmenting it.

From the outside at least this really feels like a Not Invented Here situation.