Choice of stack

PS. Regarding MongoDB vs MySQL: I'm actually wrestling with scalability and performance in MongoDB in my own business as we speak, so MySQL doesn't sound too bad right now :)

I don’t think a load time after IDLE is a problem. As you said it’s going to be one large Lambda holding all the code which means it will most likely be in cache, so nothing to worry about. Also, it’s not aditonal seconds, but rather a couple hundred milliseconds which is not a problem normally.

Regarding serverless, I don’t think it’s has gone the right way. Also, it was always buggy and has never kept backwards compatibility (I’m using it for multiple projects). Instead, I would look into something like SAM - a framework developed by AWS with the same idea as serverless framework (https://github.com/awslabs/serverless-application-model). However, I still haven’t tried SAM myself.

If it's only a couple hundred milliseconds it's definitely not a problem. I thought I measured it at a couple of seconds when I experimented with it, but it was a year ago so I could be remembering wrong. Sorry to hear that Serverless hasn't improved. It seemed promising at the time. Let's avoid it then.

Ok, so the way I see it we're starting to narrow in on React, GraphQL and probably Apollo for front-end and API.

Great discussions about backend options! We should probably go with something that the team has experience with, and that is relatively easy to maintain. It's also very beneficial it's easy to replicate the setup. This is what ensured the success of the Dreams project as an open-source project. Because it was a very simple Heroku install that could be done in less than 30 minutes, we got other events and organisations to start using it. I'm definitely not saying that we should go for Heroku, just that easy maintenance and replicability are factors to consider. Cost is actually less of an issue. We will never be dealing with huge loads for this sort of specialised application. Choosing something that would cost us a few hundred USD per year would be fine if that meant that it was easier to set up, maintain or replicate.

As for DB, looks like jury is still out, most people mention Mongo but we could also do SQL. I'm perfectly willing to drop the Neo4j idea, but there are few perspectives that have not been brought up that I'd like us to take into consideration.

We're not only building a web service. If we're successful, we are actually also building a digital representation of the Borderland community. A community can be represented by a graph. Having a database that is a 1:1 mapping of that graph can have benefits. For example, if we have a graph database the community and how it fits together can be queried for connections and explored graphically through any client that works with graph databases – generating visualisations out of the box. We have a lot of smart and very insightful people in the community that would probably gain new and interesting perspectives from this data. We could provide it as a tool for the reality guides, and the board could use it for strategic insights. Especially if the project grows in the future and we start mapping out even more connections, like interactions, comments, membership of camps and past responsibilities. And I've seen first hand that non-coders can learn the basics of Cypher to start making these queries in a matter of an afternoon, and people usually have a lot of fun with geeking out about it. Our own master wizard @danieldeterrencebr is one example of that.

It's very possible that this benefit does not outweigh the problems that come with using Neo4j as a datastore. Indeed, @vladmickevic has made some very compelling arguments for using almost anything else, and I'll be the first one to listen to experience. But I want to add this perspective, because I have a gut feeling that choosing a graph database now could possibly pay of in terms of creative possibilities in the future, even if it hurts performance.

With that said, I'd be happy with anything we love working with that gets the job done. That this gets built and that we have fun building it is the first and most important priority.

Great points. Choosing something that's easy for a new contributor to set up on their machine is worth a lot, and speaks against a serverless architecture I think. @vladmickevic seems to have more up-to-date experience with this than I do though. Could this also be a minus-point for neo4j, or is it just as easy to install and clone as other databases? I know almost nothing about it, so I can't really speak to the risks vs benefits of it overall.

I’ve actually forgotten about the fact it’s going to be used by other communities. The serverless might be challenging setting it up in that case (however, it’s still really easy to run and set it up locally; it’s just that you’re bond to AWS in that case). So, since it’s an open source project it would probably better not to be bound to a specific cloud and just go wolith Node.js/Express path in that case, so people can deploy it anywhere. Also, it’s possible to support both - lambda & regular node.js/express with some additional code.

Regarding neo4j, we can have a copy of the set of data (which is heavy on relationships between nodes) going to neo4j and enable the opportunity for other people to play around with a graph. I think it’s more imporant to have a faster and easier work pace of the main developers rather than enabling other people to experiment with a graph sometimes.

Hey everyone, apologies for getting involved in this conversation late - seems like the stack has been decided but there wasn't a vote? Shall we formalise it using a vote? (that's what Loomio is for after all...)
On the DB question, I would really like to go with Neo4j - this is an app dealing with a highly interconnected network of individuals, so the use case is well-suited, and I would personally like to work on a native graph project. :slight_smile:

I'd like to point everyone to keep an eye on this conversation: https://www.loomio.org/d/ySZ1xVKa/realities-platform-concept-notes

@emindurak had some good pointers on that we should clarify the purpose and mission with a brief and a set of guidelines before we get too far into choosing technologies. I think that's wise, and I think there is a lot of clarifying info in that thread.

@gustavlarsson You work at Unomaly? I was having an interview with Ingrid last week - but too bad I already decided for another job :) And nice with freewriter! Could you please tell me where you got the avatars from? I'd SO much love to use them for my project: https://app.pomegra.org ^{^} Anyways, sorry for the noise guys.

Great input! Yes, indeed I was almost warming up with the Neo4J but having read the reviews I started to doubt again. Nonetheless I totally agree with you @hugi about your points regarding "choosing a graph database now could possibly pay of in terms of creative possibilities". Overall, it's a promising technology with so much relevance in future.

I have the feeling that we can extend the usage of MongoDB, for example, to work with graphs easily and well. If there isn't any solution out there, maybe we build our own solution and put it in the jungle for others to also nurture? Actually there seems to be: https://www.mongodb.com/presentations/mongodb-days-silicon-valley-implementing-graph-databases-with-mongodb

I think it's better to use non-relational db like Mongo rather than relational because we can define the relations ourselves rather than having to stick to strict table schemas. I really think we should actually avoid relational/sql db for this kind of stuff precisely because we're going to deal with such data whose nature is very dynamic. I mean the correlations will change all the time. Like in Mongo, being able to store an array in a field representing i.e. the history of who took the responsibility of a need, will make it very easy for us to track things as well: not to mention being able to use JS...Of course one can do it with sql too. But I just feel it's harder :)

I don't know maybe it's because I don't have sufficient experience with relational db :p If you have a different opinion, please state!

What I know is that using some ready-made UI components like React Semantic UI, we can super easily build all the UI. I have a lot of experience of React that I'll be happy to contribute with...

Last thing I want to say is that, which I've previously shared with Hugi, if we are actually to do an application beyond the usage of Borderland, that which transcends how we fix things in our communities, we shall have a different agenda (of stack, of deployment, of strategy in general). And I'd absolutely be up for contributing a lot to it. Basically what we're building is an extremely useful tool for anyone who is in need of proper local participatory-governance. And I don't think one has to be so anarchist like me to realise the fact that this is a fundamental need in all places in this whole world. And I'm not saying just Africa, I mean we could definitely use this in my neighbourhood here in Stockholm too :)

So why not build something that can be replicated in just about anywhere?

Oh, cool, and congrats to the new job! Yes, I work at Unomaly as a frontend developer since a few months back :).

I'm glad you like the avatars! I "made them" myself, as in taking existing photographs and editing a little bit in photoshop. Would be really cool if you or anyone would like to use them, so you inspired me to put them on GitHub: https://github.com/gustavlrsn/artist-faces. Pomegra looks cool, I really like the idea of online book circles!

Back to the topic, great discussion in here! I'm mostly a frontend developer so I'm a bit agnostic as to the specifics, but I think some good points were raised about ease of setup and ease of use for other communities.

@hugi Re the screenshots of the Neo4j queries, I'm not sure I fully wrap my head around how those queries relate to the capabilities of GraphQL, other than that they seem a bit different. In GraphQL you build queries where you ask for different fields on different objects, that have all the relationships to other objects so that you can nest your request and traverse through the graph. I don't know if that makes any sense, so I'll see if I can find any way to easily mock a GraphQL endpoint so that we could play around with it to better understand the capabilities.