Proposal: GraphQL API

[riesinger]

Currently, the plan is to create an HTTP JSON API (hopefully a bit RESTful 😉 ). While this currently is the de-facto industry standard and has quite a few benefits, the main one being easy to understand and for new people to start using it.

However, after using GraphQL quite a bit at work, I would believe that it is the perfect fit for this project. It would allow the Web UI to issue a single request to grab all sorts of data. With a standard RESTful API, request count gets out of hand very quickly. Here's an example: The Web UI currently shows avatars of users with whom a file is shared (in the main file table). The Avatar component shows an image for each user and if none is available, shows their initials. This would likely require one request per user to get their profile picture URL and name.

I'm not bound to GraphQL, but would love to experiment with it :)

@mheidinger, what do you think?

[riesinger]

What I could also envision is splitting the server into multiple services which then get proxied by a GraphQL gateway. This would obviously be against the original spirit of keeping it super simple. However, I would actually believe that by providing the correct tooling (a docker-compose file, a Helm chart, ...), a relatively inclined sysadmin should be able to setup the system in a few minutes. With the current choice of database (Neo4j), additional setup is needed anyway.
Furthermore, as the application grows, I'd think it gets hard to separate the concerns in a single server application.

This is a different thing to talk about though, so I'm more than happy to open another discussion for this

[mheidinger]

In general I think the idea of a GraphQL API is quite good as it should fit this use case quite nicely.
But for now (also as backend and frontend development is decoupled) I would like to stick to REST until the basic functionality is implemented and I can be confident that the current approach is going into the right direction.
I'll look into how in general GraphQL backends can be built in go and how it could be nicely integrated.

As for having multiple services, I think that this could be something to look into when the time is right so to say. For now it would just increase the complexity of the development. Maybe in the future we even can build a monolithic and a service oriented package from more or less the same codebase.

[riesinger]

That's nice to hear! I agree that we need to make progress on the basics first 👍

I was asking at this point because I was looking into state management for the frontend. There are some graphql libraries which come with automatic request and data caching, which looked promising. I'll keep the state management flexible though.