-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
[V2] RFC : new official implementations choice #694
Comments
So [V2] means reimplementation of same conduit a improvement of same project with different backend and frontend specification? |
Yes, the V2 is still about Conduit and the implementations of the specs. |
So...what is the detail of new specs? |
You will find more information on this pinned issue : #693 Please move any further conversation there as this issue is about the implementations choice. |
Here are my thoughts about the implementation choice. SurveysAccording to the Stackoverflow 2021 survey the most popular framework for frontend is React, followed by Angular and Vue. For the backend, that would be Express, ASP.NET (core or not), and then Flask/Spring, depending on if you ask professional developers or everyone. Then there's the State of Developer Ecosystem 2021 by JetBrains, which again put JavaScript on the top. Here the order is React, Vue.js and Angular for the frontend. Sadly they don't have a breakdown by web frameworks in general. FrontendSo for the frontend, React would seem to be the obvious choice (I use neither of the big three, so I have no dog in this fight). It fits the readability and popularity requirement as it's the most popular frontend framework, and it fits the stability requirement as it's been really stable for the last few years. A caveat would be that React tends to come with a lot of different options for state, CSS, things like that. We could avoid that by sticking to vanilla React as much as possible. BackendOn the backend, Express would allow using the same language for the frontend and the backend. It fits with the 4 requirements of readability, simplicity, popularity and maintainability. Flask is the same, although Python is less popular than JavaScript in general, but people might want to showcase two different languages. Both have the caveat that they are far from batteries included, but both have an ecosystem to solve the common problems of database access, authentication, etc. From my (limited) experience, Spring Boot is far from simple, but it comes with more solutions out of the box. I have no experience with C# so if people could contribute their views it would be great. I'd personally favor Express, because that's the most boring choice, in the http://boringtechnology.club/ sense, considering JS is already used on the frontend. LanguageThere is a last consideration, which is TypeScript. As we can see in the two surveys, it's also a really popular alternative JS alternative. It works well with React and Express. TS also solves some of the issues with JS. It makes the code more readable and more maintainable. It is less popular than JavaScript, but it will mean that we only have one language across the stack. That will make things easier than any combination of two languages. SummaryFor the reason exposed above, I think React, Express and TypeScript are the way to go. |
@lucas-deangelis Thanks for your feedback. BackendTo fix issues with the current API, I created and deployed a new one (https://realworld-temp-api.herokuapp.com/api). The Readme will include a section about how to deploy it on Heroku for personal usage. FrontEndI agree about React. |
To move to the next version of the specs, we need to be able to experiment, test, and showcase changes to the community.
To do so, we need to create a Frontend and a Backend implementation.
Making the community fully part of this project is crucial for us and we want everyone to contribute to it.
Our first move for the next version of the specs is to define which language/library/framework to use for each of those two implementations.
We have some requirements for maintainable implementations:
Readability
We can't expect everyone to know a defined stack.
But we can work on choosing the best solution to make sure most of us will be able to understand the source code.
This requirement is more about the readability of a language/library/framework than about the way to write code (but we'll value the latter one too)
Simplicity
To use the best of a library/framework isn't a requirement.
It's fine not to use some features to keep it simple and easy to read.
It might even break the rule of readability.
Popularity
The source code must be easy to read.
But it should be easy for people to contribute to the implementation.
Using a popular language/library/framework might be useful.
Maintainability
We want to create these implementations to showcase the specs, not for the sake of using a hyped solution.
We need a stable language/library/framework.
Provide your solution
Do you want to contribute by providing a solution? Please answer this issue by arguing about your solution :
provide examples of the readability
which features would you choose not to use to keep it simple?
give insights about its popularity
explain how stable your solution is
The text was updated successfully, but these errors were encountered: