Decide what tools to use

[stpoa]

Frontend

• Language: TypeScript
• Rendering Framework / Library: React
• Testing: Jest
• Bundling: Parcel
• State management: none

Backend

• Api communication: GraphQL
• Framework / Library: Express, Apollo
• DB: TypeORM + MySQL

[stpoa]

1. In my opinion we should use TypeScript everywhere, because it gives many advantages comparing to JS and doesn't require much more work.

2. As a frontend rendering library I would suggest React and if necessary switching to preact in the future https://preactjs.com/guide/switching-to-preact

3. I would use redux, since we are all somewhat familiar with it, but after reading this article: https://hackernoon.com/how-graphql-replaces-redux-3fff8289221d I think we might not need state management at all if we use graphql

4. For testing:

   If you require a broad API along with specific (perhaps unique) features then Mocha would be your choice as the extensibility is there AVA or Tape gives you the minimum requirements. Great for providing a solid minimal foundation for you to get going fast If you have a large project, or would like to quickly get started without much configuration, then Jest would be a solid choice

I would go with jest (react, snapshots) or/and tape (simplicity, no globals)

5. For bundling I would choose parcel, because it is truly 0 config. https://medium.com/@ibrahimbutt/if-youve-ever-configured-webpack-parcel-will-blow-your-mind-b615468cee78

6. For api communication I would suggest https and websockets (for chat) using graphql https://www.apollographql.com/ https://github.com/apollographql/subscriptions-transport-ws

[morganfree]

+1 for TypeScript and React.

Graphql looks good but it adds a little extra complexity on the server comparing to rest. Anyway I would go for graphql. Clients to choose are: Relay Modern and Apollo (https://medium.com/@wonderboymusic/upgrading-to-relay-modern-or-apollo-ffa58d3a5d59). It seems that apollo is a more mature and easier way to start.

I would choose Jest for front end testing because it is focused on React.

+1 for parcel - it looks very easy to start and when we ever would need a better production build we can always switch to a more configurable tool.

[GoldenTK]

Probably good approach is to use redux for state management and graphQL for our API. We should consider to use express on backend side. I would prefer to use docker containers for backend and put whole UI to fireBase because it was easy to restore previous version of code, put it on our pipeline in gitlab and most important thing it should be scalable depends on traffic.

+1 for TypeScript, React, Redux, Jest, (Webpack / parcel).

[stpoa]

I updated list in original post. State management and DB are undecided.

For DB I would go with MySQL + TypeORM https://github.com/typeorm/typeorm

For state management I would not use redux until we decide that it is required, because it adds a lot of boilerplate.

[EDIT] Another article about redux and graphql https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a

[stpoa]

Regarding graphql servers:

https://www.prisma.io/ https://www.graph.cool/

Very interesting projects, if we used one of above we wouldn't have to map data between DB and graphql endpoint.

[morganfree]

I wouldn't use redux from the start. I do not think our app will require state management at all because data fetching/caching/denormalizing will be handled by the graphql. Without redux we can encounter the problem with prop drilling but:

• React 16.3 has stable context API which can be used for such problems https://blog.logrocket.com/how-and-when-to-use-reacts-new-context-api-b584e41b2704
  • Possibly, Apollo also has a way https://www.apollographql.com/docs/link/links/state.html

If state management will be needed anyway, we can add it in the future to some part of the app.

---

TypeORM looks great and MySQL is good enough for the app. We should have at least a mysql container, so +1 for docker.

I am not convinced to a library for mapping schemas between db and grahql. The idea seems to be shaky - it reminds me of implementing a regular crud-rest api. It probably works great at the beginning when you need to implement the same crud operations for basic entities but not so great/useful when the app evolves and becomes more complex in terms of business logic and database handling.

Some valid points from the comment from the prisma introducing article (and the the link to the comment):

Using GraphQL in this way seems problematic and of little value. If all GraphQL is being used for is to expose the data in a database that seems fairly anemic. That kind of use fails to give the data any added meaning or context. An API should not be just the way we access our data. An API should be a means of describing what can be done with the system, not just what is being stored in the system’s database. An API should relate to the value of the system in terms of activities otherwise, it fails to add value.

Using GraphQL to merely replace SQL as a query language sells GraphQL short though. Its mutation capabilities allow for far richer expression of domain concepts than REST and can be used to actually encapsulate and present business logic in a friendly way. GraphQL represents a much more compelling solution when it’s pushed towards the top of the stack rather than towards the bottom.

Also, implementing simple and repetitive crud like graphql schemas/resolvers from the scratch allows us to better understand the concept and we become more familiar with the raw graphql api and its power. When we encounter more complex problems which cannot be solved automagically by prisma we will already have the understanding and familiarity with graphql. Instead of fighting the library/framework, we will be exploring graphql possibilities.

For testing I would check if jest is a good enough tool for testing backend - because it is already used in front. If not, tape is good enough.

For: apollo + express, typeorm + mysql, docker, jest/tape

[GoldenTK]

+1 for raw graphQL api. We are able to have better understanding what is under the hood of graphQL. Ok we should try with context api.

[GoldenTK]

I think we need to consider to use AWS RDS / Google CLOUD SQL. It's easier to start with cloud DB service.

[stpoa]

closing for now, we can reopen after we will start backend work.