New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Politeiagui code refactoring #990
Comments
Proposed solution #1Layer GraphQL on top of the REST API Create a layer between www and the GUI client where we could add many data sources to a graphQL server which would be then consumed by the GUI.
A good example of how this works can be found here
I propose we develop a small POC which executes a few functionalities of the GUI to evaluate the result and its potential to become mainstream. The POC:POC Diff GraphQL Server
GraphQL Client
/**
* Apollo Client setup
*/
const link = createHttpLink({
uri: "/graphql",
credentials: "include"
});
const client = new ApolloClient({
link
});
export default class App extends Component {
render() {
return (
<Provider store={store}>
<ApolloProvider client={client}>
<Router>
<LoaderComponent>
<StagingAlert />
<SessionExpiresIndicator />
<HeaderAlertComponent />
<Subreddit>
<Routes />
</Subreddit>
</LoaderComponent>
</Router>
</ApolloProvider>
</Provider>
);
}
} Full source code can be found here.
const AllVettedQuery = gql`
query getAllVetted {
proposals: vettedProposals {
name
username
censorshiprecord {
token
}
}
}
`;
const AllUnvettedQuery = gql`
query getAllUnvetted {
proposals: unvettedProposals {
name
censorshiprecord {
token
}
}
}
`;
export const AllVetted = graphql(AllVettedQuery)(ProposalList);
export const AllUnvetted = graphql(AllUnvettedQuery)(ProposalList); Full source code can be found here Running the POC:
Resources: @sndurkin @tiagoalvesdulce @thi4go @camus-code @lukebp @marcopeereboom please take a look and let me know what are your thoughts. |
Apollo looks like a good solution! Also, what about the snew-classic-ui? I think it would be better for us to sit down an discuss the whole new design for Politeia, since our UI kit is outdated. Also, we can work on improving the mobile responsivity, which we don't have. IMO, creating a new design kit from scratch would take less time than keep improving an existing one. I'm able to help to create this! |
IMO snew-classic-ui has to be dropped and a new UI lib has to be built taking in consideration responsiveness, customizability and general UX.
|
Completely agree @fernandoabolafio. snew-classic has become a big bottleneck and I don't really think it adds that much in terms of functionality. Not to mention it prevents people from easily being able to contribute to the GUI repo. I'm not sure if the ideas is to create a UI lib from scratch or to implement an existing one, but I've come to really enjoy Semantic UI - React for building responsive & customizable UX. They have a pretty expansive module / element collection that covers pretty much everything we already currently use within the GUI. |
@camus-code this UI Kit is awesome! Great idea! |
Just as an outsider to politeia code looking in, as a suggested alternative to Apollo Server, I've had good experiences myself using Apollo Client with the Go based gqlgen as the GraphQL server. It's something I may have time to help out with in terms of coding as well, if you go that way. Overall, I've found GraphQL brings great benefit to the front end, by pushing a lot of that complexity to the server. It's harder to optimise on the server, but optimisations can come later. Apollo Client also has caching options to reduce calls to the server which can help out. |
@orthomind that's an interesting point of yours. If we opt to use a graphQL server written in go, we may want to have the gql service within the politeia repo where all the go code lives in. So, every functionality that we want to migrate from REST to gql would require 2 PR's, one for Politeia and another one for Politeiagui. |
Take my remarks with a grain of salt, as I'm not much familiar yet with how politeia works and the various components that make it up. With that now said...
|
Sorry for the delay @orthomind and I much appreciate your comments. I think your point that it may belong neither in politeiagui or in politeia makes a lot of sense. It can be a separate service which politeiagui or any other frontend consumes from. Not sure about it should be born inside politeiagui or not. If it's written with nodejs, I would rather keep it in the same repository.
About writing in Golang may be a good idea since we have Go specialist in the team. Although my first intention is to make the graphQL layer friendly for the frontend developers so they can quickly abstract services from the backend and put it to run in politeiagui.
|
Hey guys. Been thinking about this GraphQL approach to our refactor, and I believe it will bring many benefits to the frontend developers, current ones and newcomers. Currently, our redux layer is doing a lot of heavy lifting, resulting in bloated boilerplate whenever we want do add a feature, be it a simple or complex one. Adding this aditional GraphQL layer would reduce complexity by a good margin. I've been trying to think what would change practically in our code base, and from what I understood (correct me if I'm wrong please) graphQL queries can substitute both connectors and selectors. Each component would still need a provider (or whatever its name) to pass down its necessary props, which would be fed by custom queries from apollo client to that component. So in @fernandoabolafio's PoC, in Also thinking about local state, I stumbled upon I'm hacking into the PoC to see if I can advance in some parts, especially in a satisfying architecture for the new components folder, the substitution of the redux folders boilerplate, and how we'd manage local state data within apollo client. Have you guys thought of other ways we can advance in this PoC? Any input would be great. @fernandoabolafio @victorgcramos @camus-code @tiagoalvesdulce @orthomind @sndurkin |
I've been thinking more about it and let's keep this possibility in mind but I think we need to discuss this after the new design implementation and also the decoupling of snew. After those two things are done, it will be much more clear for use if we can just improve our Redux code or we need to switch to graphQL. |
Yeah people didn't seem to care as much about the reddit like heritage of the design as much as I thought they would; so no hard feelings cutting it out of pgui. I'd like to suggest that React hooks and Context Providers are excellent, make redux completely unnecessary; and would be a great way to make the redux code more manageable without having to also dive into graqhql at the same time. It's similar enough to the redux pattern and selectors that it could be done piecemeal on a per-component basis. |
Most of it was accomplished with the redesigned version. Other parts of it such as state management and caching optimization are being tracked under other issues. |
As we approach the redesign of Politeiagui, we are considering a significant code refactoring to deal with DX and scalability issues that have been raised by the developers along the development process.
That way we could align a brand new design with better code and performance. See this discussion on Matrix for instance.
Issues raised so far:
We need to discuss possible solutions to it and evaluate the feasibility of doing it.
Please, write your proposed solutions or thoughts in the comments.
The text was updated successfully, but these errors were encountered: