I've only worked with some of these technologies so I can't make an informed comparison. What I can say is that I've recently fallen in love with React + GraphQL. I'm currently using Relay Modern, which is brand new and sometimes frustrating because of it. It gets better with every new release though. Apollo may be a good alternative but I haven't worked with it.

Why are we interested in Neo4j? Is it mainly the visualisation tools? How might they help us?

Never mind. I just saw that you talk about the reason for using a graph database in the video you posted in the other thread. Makes sense :)

What are we thinking in terms of backend if we go GraphQL by the way? There are GraphQL libraries for a bunch of languages. Node and Express?

I think Node and Express makes sense. It’s what a lot of people have experience with right now.

I also really like React and GraphQL! A couple of thoughts:

• In regards to Neo4j, my understanding is that all the desired benefits mentioned in the video, like being able to easily map out the relations from a single node, is achievable just by using GraphQL (and keeping the data in a relational or document-based database). That said, I have zero knowledge of Neo4j, so there might be other benefits to using it other than that.

• I’ve worked with Meteor in the past (building https://freewriter.io), and I really like it for it’s ease of use and the speed of development that it offers. However, some of the downsides could be that it’s a bit of pain to host, a bit of a ”walled garden” and not as popular any more. Also, using GraphQL replaces a big part of Meteor which is it’s pub/sub data model.

• As for Apollo vs Relay, I’ve only used Apollo a little bit but I get the impression that Apollo has stronger community around it and better documentation and resources available? This might have changed though, I last looked at this about 6 months ago and things move fast :).

• Something I can really recommend for the frontend is Next.js (https://github.com/zeit/next.js/) - it’s an super easy way to create React apps without any overhead of having to deal with Webpack configs and so on. It also gives you server-side rendering out of the box and an easy to use routing solution.

I'd absolutely be willing to try Apollo. The documentation for Relay Modern is sparse to say the least. Next.js looks interesting. I've only used create-react-app to bootstrap react apps.

I'm not familiar enough with GraphQL to understand what we could do with GraphQL + other DB to give us similar capabilities. Maybe someone who's familiar with GraphQL could look at this, how easy would it be to explore our data in this way using GraphQL and MongoDB? Of course, in this case there is also the Neo4j client and it's visualization tools, but I'm also thinking about querying for sets based on relations in this way?

Great discussion guys.

For backend I would recommend to go with AWS: API Gateway + Lambda. That way we don’t have to pay for the servers. Lambda has quite large free tier. In terms of code for Lambda I would suggest using Node.js - loads of modules and fast pace to write software.

Database:
I have experience working with neo4j i production and would really suggest not using it here. This database (in my opinion) is purely designed for offline work, e.g. run cron jobs, calculate stuff and generate online-ready data. I haven’t watched all the video, but what I can see from the sketches - any database would do it without problems: mongodb, mysql, dynamodb, postgresql. Neo4j is slow, expensive (when you want to scale) and hard to write fast queries + steep learning curve if you want expand your team.

Mongodb - cheap to start in terms of setup and amount of work, expensive continue when the data grows.

Mysql - easy to setup and run on amazon (AWS Aurora). The pace of writing code is fast enough.

Dynamodb - amazing performance and scale, relatively cheap to support, but can be challenging to write code.

Postgresql - same as mysql, but more expensive to run.

Conclusion for databases for this project: my first choice would be mysql on amazon aurora. My second choice would be Mongodb.

For frontend I would recommend vue.js or react. Vue.js is easy to learn, react - easy to write modules. I think here we can choose whatever people in team are going to like.

GraphQL - might be harder to maintain comparing to REST, but could be very suitable if we go direction: AWS API Gateway + Lambda.

Awesome input! I played around with AWS Lambda around a year ago, using Node and the Serverless framework (https://serverless.com/). I decided the framework was too immature at the time to continue using for my apps, but I'm excited to give it another try now that it has hopefully matured a bit. My only concern would be that Lambda functions take a few seconds to warm up if you have low volumes and deploy a lot of code to a single function (as we would probably have to if we have a single /graphql endpoint). The only downside for the user would be that it takes a few extra seconds for the app to load after no one else has used it for a while, so it's probably an OK trade off for us.

I actually think GraphQL is easier to maintain than REST. REST APIs tend to lead to adding a bunch of "special" endpoints in an attempt to improve load times for specific views in my experience, which then need to be maintained and cause headaches. I think one of GraphQL's main benefits is that it ends up being easier to maintain.

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.

Hi Gustav!

Thanks a lot for having made them, and for sharing publicly! It's amazing!! <3

Glad that I inspired you, and happy that you like Pomegra :)

I don't have much more to say today ;D

Doocreate is a possible project we could get components or event a whole boilerplate from. Check it out and see what you think: https://www.loomio.org/d/J1ouReCt/doocreate-a-boilerplate-app-to-pivot-realities-from-

I'm taking a look at Doocreate and will get back. In the meanwhile, here's a guide I like to follow for organising the code in a React project: https://medium.com/@alexmngn/how-to-better-organize-your-react-applications-2fd3ea1920f1

I'm open to other ways too of course but I've found it works well as a base. It's also nice to have a blog post to link to when getting new devs up and running with the project.

It's time for us to get this show on the road! :clap: I've spent some time with @emindurak and @danieldeterrencebr today, and we think it's best to kick this off in the most Borderland-way possible, maximizing Doocracy.

Anyone who has time and wants to try to set up a boilerplate that they think meets the requirements of the whitepaper, can do so. That way, we can all start prototyping on our own for a bit. Preferably, it would be great to have a boilerplate we can start from at the end of the week. Who's feeling up for it? :)

I'm up for it! Wrote some more info in the Doocrate thread. I'll try to get started on it this evening and post the repo here so anyone can follow along and add to it.

Awesome! I think you could assume a Mongo setup and then if we want to rework it to neo4j down the line it shouldn't be that difficult since both work with json objects.

As for helping out this week, maybe @vladmickevic and @gustavlarsson have worked on similar stacks? I could also give it a go, I'll see how close it is to the stuff I know once I see it!

Yep, I'd be available to help out a bit in the evening during the week (Swedish time). Next.js will provide a great boilerplate for the frontend part. I'll start looking at some tutorials and playing around with building a GraphQL backend/API server (this is the part I'm least proficient in but also something I want to learn more about).

Let me know when you have a repo up and running @erikfrisk :)

Here's the repo! https://github.com/erikfrisk/realities

I put both the frontend and backend in the same repo, even though they're really independent from each other. I normally never do this, but I've seen others do it and thought it might be easier to get new people up and running if everything is collected in one place. Let me know if you'd prefer that I split the repo into two.

I've set up a backend with a simple GraphQL endpoint. No database yet. The frontend is just Next.js's example Apollo project so far. I didn't have time to start modifying it. I'll continue tomorrow evening (Colombian time). Please feel free to poke around and add to it before then if anyone has the time. Something I'd love to get set up on the backend for example is eslint with the Airbnb configuration (or whatever people here prefer) so that we have consistent code from day one.

@gustavlarsson I found a GitHub user with your profile pic, so you should already have an invite to collaborate on the repo. Everyone else who want to contribute; please send me your GitHub usernames and I'll add you.

Great! I'm aerugo on GitHub, add me too!
Should we set up a Trello to keep track of TODO?

@hugi I've added you! Yes, a Trello board would be awesome! If you create one you can invite me at ef@erikfrisk.com. What do you think about also setting up a Slack group as a complement to Loomio for the hackathon? Loomio is OK as a kind of message board for general discussion but for collaborating remotely in real-time we need a proper chat tool. It wouldn't be used for important decisions that we want everyone to have easy access to. Just real-time collaboration.

PS. We could also use a channel in the Borderland Slack group.

I think it makes a lot of sense with a mono-repo in this case, as we could then utilize GitHub's issue tracker in one single place if we'd like to (might be an alternative to Trello?).

Eslint would be great! The Airbnb configuration sounds good to me.

I agree that Slack or any other real-time chat would be nice also! I really like Slack but a good alternative could be Gitter which is more open (open sourced, all conversations public, anyone can join)

Good call! I agree that Gitter is better for us and we could start with just GitHub issues for to-dos. Less visual but definitely nice to have everything in one place. If it gets too unwieldy we can always set up a Trello board later.

Can you also add me? github username “vlamic” and email for trello: vladislav.mickevic@gmail.com. Thanks!

@vladmickevic Added you to the repo!

We have a Gitter! https://gitter.im/realities

Yeah, git actually has a really great built in Trello clone that integrates with issues, forgot about that! Check it: https://github.com/erikfrisk/realities/projects/1

What we went with (or rather what I suggested) was that since the person building the boilerplate needs to be familiar with the stack, anyone who could put time into building a boilerplate following requirements could define a stack and start working. Erik did, using React, Next, Apollo/GraphQL. So since it was a decision we left up to doocracy, it’s kind of still a decision in process. But it’s probably time soon to run a Loomio decision on the architecture in a wider sense - both with regards to stack and what I’ve started sketching here: https://www.loomio.org/d/trRnp3wA/project-architecture-and-boilerplate-development

As for Neo4j, I’d love to use it, but since Erik might not have time to learn it, someone else would have to give him a hand and define what he’s started working on with Neo4j rather than Mongo. Good news is that this should not be hard - Apollo and Neo4j are supposed to go hand in glove. Feeling up for syncing with @erikfrisk and start working on DB @matthewparsons ?

I've watched a couple of YouTube videos on Neo4j and it doesn't look too difficult to get started. I still haven't added a database to the boilerplate, so feel free to dig in and add it @matthewparsons.

Any preferences for authentication? Auth0 (https://auth0.com/)?

Looks simple enough. Would be nice to have a service to take care of that for us, and Auth0 has a lot of providers. I have no idea how auth works with an Apollo API, but I trust your judgement.