Loomio
Wed 22 Nov 2017 1:25AM

Choice of stack

H Hugi Ásgeirsson Public Seen by 19

What stack should we use? Based on the concept and the requirements, what would fit us best? Developer skills and feasibility of developing an MVP quickly, as well as ease of maintenance as a community open source project should all be factors that we take into account.

To get us started, here are a few stacks that have been discussed:
* React, Meteor, MongoDB
* React, Meteor, Neo4j
* React, GraphQL, Relay (or Apollo), MongoDB
* React, GraphQL, Relay (or Apollo), Neo4j

What do you think? What would be a good fit for us?

EF

Erik Frisk Wed 22 Nov 2017 4:36PM

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.

EF

Erik Frisk Wed 22 Nov 2017 4:37PM

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

EF

Erik Frisk Wed 22 Nov 2017 5:04PM

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 :)

EF

Erik Frisk Wed 22 Nov 2017 5:58PM

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?

H

Hugi Ásgeirsson Wed 22 Nov 2017 8:40PM

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

GL

Gustav Larsson Wed 22 Nov 2017 9:47PM

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.

EF

Erik Frisk Wed 22 Nov 2017 10:23PM

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.

H

Hugi Ásgeirsson Thu 23 Nov 2017 10:07AM

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?
Neo4j example

VM

Vlad Mickevic Thu 23 Nov 2017 5:05PM

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.

EF

Erik Frisk Thu 23 Nov 2017 5:19PM

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.

Load More