Experience from building this project about relate

[sedubois]

Hi! Good questions. The aim here so far was to upgrade my webapp dev knowledge and create a seed for a mindfulness community platform. So far, I'm happy with these choices:

React

I knew React before and it's a great rendering library with good ecosystem; besides as it's a library and not a framework like Angular, it might be swapped out if needed I guess...

From Firebase to GraphQL

I first played with Firebase as a realtime backend, but the data isn't typed and structured at all. I also didn't see with a good eye that it's a Google product in the middle of Facebook technologies (React, Redux, etc) and was wary of various kinds of friction. Obviously it still has other strong points like offline capabilities etc, but I kept thinking that there must be something out there better fitting in the React ecosystem. I then learned about GraphQL!

GraphQL

GraphQL is clearly the future of APIs, it offers a strong typed system which is great for static analysis, IDE integration etc, gives a good separation between front-end and back-end allowing them to be developed independently and yet coherently, is self-documenting and explorable through graphiql, allows to query all data in a single call (no need to assemble data in cumbersome redux code), should support realtime updates, all code is co-located, with its data fetching requirements, no need to split reducers, actions, etc. For prototyping new projects, and even maybe in the long run, there's furthermore no direct need to make your own backend, just use a cloud service.

Graphcool

Graphcool seems like a good GraphQL backend-as-a-service, their team (based in Berlin) seems motivated and dedicated, data is in Europe (Ireland I believe). An alternative I saw is Scaphold but my "gut feeling" (and their smaller Slack group) made me go for Graphcool for now. Although probably a bit biased, I also appreciate Graphcool's comparison with Scaphold on their landing page. Anyway the great thing is that if it wouldn't work out in the future (e.g not happy with pricing), the backend can normally be changed independently from the frontend.

From Relay to Apollo

For the GraphQL client, I first learned Relay, but was put off by the fact that they don't have any active involvement with the community (e.g didn't see any news about a possible Relay 2 since months), it wasn't even in line with the latest GraphQL reference implementation (at the time at least), it's incompatible with Redux, and it doesn't follow the GraphQL standard (need some tricks like accessing data through a "viewer" node). I then tried Apollo which although quite young, has now a rather stable API, integrates with Redux if needed (and whose state is thus inspectable in DevTools), and is very actively developing and engaging with the community. I also enjoyed watching the videos of the first GraphQL summit that they recently organised.

From boilerplate to NPM dependency framework

In parallel with those learnings, I first tried to use a boilerplate project to get things in a good shape on the front-end (an area which isn't my strength, as I come from a background in Java control systems then cloud backends). First I discovered Este which is nice, but also deals with native clients which is unnecessary for my prototyping (and I aim for a universal progressive webapp). I then tried react-boilerplate which is nice too, but back then its maintainer didn't have the time to maintain and develop it, and like with any other boilerplate, once you start using it, you're on your own. I also realized that the redux-observable (used in Este) and redux-saga (used in react-boilerplate) async state management libraries aren't as necessary in the beginning, once you use Apollo for remote data fetching.

Next.js

The obvious alternative was then create-react-app, but it doesn't have server-side rendering and you're forced to "eject" the configuration once you need to change anything. I then learned at the same time about Next.js which just got open-sourced, is an npm dependency and thus easily upgradeable, frees you from annoying config files and yet is configurable when needed, and although at the time it only allowed static websites, I could see that it aimed to support more complex use cases very soon. Importantly, it quickly became clear that they were several dedicated people behind the project, and main selling point, it supports SSR which I learned along the way (from rauchg's article) is still quite important.

The last big question was whether Apollo and Next.js can indeed combine well, but that finally seems to work well 😃 (see vercel/next.js#387)

Now

I'm happy so far deploying the code on now which is dead simple and is an easy way to stage your changes.

Limitations and questions

• to server-render Apollo pages, React needs to be rendered twice on first page load. AFAIK that's not as bad as avoiding SSR which has its own performance costs (multiple network roundtrips). Anyway I'm happy to hear in this thread if there's a way to avoid this.
• in a related fashion, on first page load the browser calls the Next.js server which then calls the Graphcool backend; the Next.js and GraphQL servers could be located on the same machine to avoid this (but that means taking the backend dev in your own hands).
• more perf improvements will probably come e.g when having the ability to download the Apollo modules only once (vercel/next.js#659 (comment)), etc
• not sure if/whether there's some UI library out there compatible with Next.js? (e.g Ant Design isn't)
• haven't yet thought if/how to separate test vs prod backends with the Now deployment

I still need to finish upgrade to Next 2 (dynamic routes, prefetching, etc), enhance the app contents, add business logic with AWS lambdas on Graphcool side, integrations etc, so can't speak specifically about it but don't foresee major issues so far.

I'll close this issue as there's nothing immediately actionable, but feel free to comment if you have any feedback! If you see specific things to fix, better to open a separate issue.