Honest opinion and what can be improved in the docs



  • Hi,

    So I wanted to create a typescript graphql codegen project with quasar the problems is that I couldn’t find a detailed example anywhere on how to integrate with these technologies.

    Also, Vue3 is coming with typescript, so maybe it is a good idea for the docs and future adopters of the platform to have some examples and a clear guide for integration.

    I am currently working on an example with laravel lighthouse(graphql) helped by @lorado to create a real-world example and i considered quasar for this task but unfortunately due to the lack of info and no clear way of integration, nuxtjs was chosen.

    If you read until here then read on: I am also willing to work with the quasar team after i finish the nuxtjs app to create a similar one in quasar framework.

    You can find our discussion here https://github.com/nuwave/lighthouse/issues/1476, if you are interested.

    Thanks



  • Thanks for the feedback. The only issue is, Quasar is API/ backend agnostic. So, writing in the docs on how to put the API parts together would be outside its realm of responsibility.

    Out of curiosity though, what docs on the Nuxt site did you find, which helped you with getting a GraphQL client together?

    Scott



  • It doesn’t have a step by step guide but it has this https://typescript.nuxtjs.org/, which made possible this post https://www.codegram.com/blog/nuxt-typescript-apollo-a-bumpy-road/ and also other developers that do real-world applications developed this further until it reached a point where it could be usable.

    You can be the first framework that uses Vue for SSR to have a guide on how to integrate this stack for developers(Typescript codegen apollo). This will ensure that quasar may become a standard in the industry if you take out the pain from this process.
    Also, Vue 3 is coming with typescript and that will be a game-changer and help Vue to be more testable, easier to read for others that review your code.

    Also, my question is:

    Did the quasar team ever wonder why there are so many nuxtjs examples on youtube, but very few quasar tutorials?

    Thanks, @s-molinari for the follow-up



  • help Vue to be more testable

    That’s not what TypeScript is for. 🙂

    Did the quasar team ever wonder why there are so many nuxtjs examples on youtube, but very few quasar tutorials?

    It’s because Evan You was promoting Nuxt in the earlier days of Nuxt as an SSR alternative. And maybe, only minimally, because of them offering and promoting TypeScript support.

    I’ll be for sure doing more for @quasar/app-extension-apollo once Vue2 and Quasar 2 comes around. 🙂

    Scott



  • @wolfiton said in Honest opinion and what can be improved in the docs:

    It doesn’t have a step by step guide but it has this https://typescript.nuxtjs.org/, which made possible this post https://www.codegram.com/blog/nuxt-typescript-apollo-a-bumpy-road/ and also other developers that do real-world applications developed this further until it reached a point where it could be usable.

    You can be the first framework that uses Vue for SSR to have a guide on how to integrate this stack for developers(Typescript codegen apollo). This will ensure that quasar may become a standard in the industry if you take out the pain from this process.
    Also, Vue 3 is coming with typescript and that will be a game-changer and help Vue to be more testable, easier to read for others that review your code.

    Also, my question is:

    Did the quasar team ever wonder why there are so many nuxtjs examples on youtube, but very few quasar tutorials?

    Thanks, @s-molinari for the follow-up

    We can all agree that class-based applications are easier to test with jest than function-based ones.

    Nuxt has a lot of modules and very detailed documentation when it comes to auth and middleware. Also when you first open their page you feel some sort of familiarity.

    Another big advantage is the possibility to have just some pages static and the rest rendered with ssr.

    So if you want to change this opinion then releasing a step by step tutorial created by the team of quasar with tests will certainly help change people’s views about what quasar can offer.

    Also showcasing big companies that use quasar could be another good option to make it more popular.

    It is good if you can improve that package and also integrating those stacks directly(typescript support codegen apollo unfetch) will certainly make it very useful.

    PS: Quasar Team: Please take into account that jwt is old and should the replaced by paseto as state here https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-to-paseto



  • We can all agree that class-based applications are easier to test with jest than function-based ones.

    we can, but do we must? that’s different…

    Also showcasing big companies that use quasar could be another good option to make it more popular.

    Honestly? Get any framework in history, backed by “big company” and you will see a bloated, commitee agreed, all-having monster. Frameworks/libs/technologies such as Vue, Quasar are created in spite of those “big companies” monstrosities. Do you think that Google/Facebook backed Quasar would be such elegant and well designed? Think again, this time with those history examples.

    PS: Quasar Team: Please take into account that jwt is old and should the replaced by paseto as state here

    paseto will be old, too. As any other “security” technology. The “security” part you are talking about is strongly orthogonal to Quasar/Vue from architectural point of view. Therefore, choosing “one, and one only” security integration at the framework level would be just “stupid”. Yet, the Quasar and Vue are “wise”, “well thought”, “elegant”, because they allow different integrations. Those integations are at different level of abstractions. For example you could argue, that there is one and only valid video player. Any of those “currently” best “security” technologies just comes and goes.



  • We can all agree that class-based applications are easier to test with jest than function-based ones.

    Um, no. We can’t agree. A class in JavaScript is a function. 🙂

    Thank you for your other feedback.

    PS: Quasar Team: Please take into account that jwt is old and should the replaced by paseto as state here https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-to-paseto

    Um, JWT is far from old or rather “dated”. It’s still a solid standard. It just has to be integrated and used properly to be secure. Also, as qyloxy points out, Quasar has nothing directly to do with JWTs or PASETOs or how you authenticate users. That decision is up to you as the developer. So, there is no purpose in asking the Quasar dev’s to take PASETOs into account.

    Scott



  • Letting the developer choose about things related to security is wrong because a lot of developers don’t understand even security headers. So creating a best practice for security is a must in any framework, the so-called freedom for developers is not a good idea when experienced people from the web security field(10 or more years of experience), are telling everyone: “Your security policies are outdated and you should follow the best practices or else risk: losing data or worse get sued by your users”.
    Also please read this line very carefully "Platform-Agnostic SEcurity TOkens (PASETOs) ".

    @qyloxe, you misunderstood what I said here: “Also showcasing big companies that use quasar could be another good option to make it more popular.”
    What I meant is that companies like Airbnb, PayPal, Stripe, etc big names to use the framework not to change it nobody wants a second angular 1 experience.

    Thanks for the follow-ups @s-molinari @qyloxe



  • Letting the developer choose about things related to security is wrong because a lot of developers don’t understand even security headers. So creating a best practice for security is a must in any framework,

    You seem to be missing the point. Quasar doesn’t deal with the connectivity to the backend. Thus, it can’t “offer best practices” for connectivity to the backend. There are too many choices to cover. Whatever choice a dev makes, they then have to understand what it takes to make it secure and understand best practices. There are tons of resources out there on the subject. More than we could ever produce well in our docs. So, please stop thinking we should be doing more than we already do, because where Quasar should be “secure”, we do everything possible. Even write up stuff in the docs. https://quasar.dev/security/dos-and-donts

    Scott


Log in to reply