Replies: 1 comment 2 replies
-
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. :-) |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions