Should we move some API calls to the app repo?

[mktcode]

I'm wondering if it might make more sense to make some of the API calls directly in the frontend.

The whole API repo basically only exists as a replacement for Nuxt's server middleware that I used before, so the app can be deployed as a static page and of course we need some API server to hide away some secret stuff... well, actually that's only the github client secret to get an access token.

But in all other cases, we can actually make those queries right in the frontend. I don't know yet how paying for queries will really work in The Graph's decentralized mainnet environment though.

The queries to GitHub mostly use an access token just to have per-user rate limitations. Making those calls right in the frontend would actually even avoid sending those access tokens anywhere other than GitHub.

The API also decides which Subgraph to use (octobay or octobay-dev). This could also be handled directly in the app.

Any thoughts on this?

[alo9507]

This is an instance of the classic "monolith vs. microservice" debate.

Collocate code, or decouple code? Both have their benefits.

Since the benefits of collocation are fairly obvious (all the tools in one toolshed), I'll just cover some decoupling benefits I've noticed after being on projects that are decoupled, and why the extra work is often worth it.

Code that's collocated tends towards coupling over time. As it couples we may find ourselves in scenarios where a backend dev (where I tend towards) will need to know some Vue and FE code in order to contribute effectively, which may be a deterrent. For me I don't mind, I'd love to learn Vue, but other weekend warriors...

Imagine we had a backend task on our own bounty system. We link to the area of code that must be updated, and it's in the context of Vue. A dev may self-disqualify thinking "I don't think it's worth learning Vue to earn this bounty". Decoupled code is easier to contract because the skills needed are clear and the context is smaller.

Keeping the seams between the FE and BE mediated by two different services let's us wrap the GitHub, Graph, and any other 3rd party APIs in interfaces that suit us, and having such an interface means we can write a full mock of our backend on our frontend for testing. Backend devs could make updates without us having to redeploy our frontend.

I know that right now we're basically just using the API as a proxy between the frontend and GitHub. But as things grow, and our business logic grows more complex, experience has told me that that business logic ought to live on the backend, with the frontend as simple as a presentation layer as possible.

The pros/cons of BE/FE separation ebb and flow over the lifetime of a project and microservice topology ought to be a living beast. Right now decoupling is a con, soon I think it will be a pro, and later...we shall see. :-)

[mktcode]

100% agree about our general approach being microservice oriented. In this case I just thought the API acts as an interface to already existing interfaces. In the frontend I have to do APIs call of some form. I need to call the correct endpoint in the correct way, to get the correct data. That's what a frontend dev is responsible for. The question in this particular case is simply why do we restrict the frontend developer to only use prepared queries through our API server instead of just querying data from the Subgraph directly? I think now it is actually coupled a lot more because of that. I feel it when working on the frontend. I always wonder why exactly to I need to jump over to the API repo now the make that call from there?

[alo9507]

I see. Why wrap a GraphQL backend in REST.

Let's get Apollo Client on the FE. Since our preliminary research on Apollo Federation seems like we won't be able to unify non-Federated graphs that we don't control behind a single gateway, I'm starting to agree that we should decommission the API.