Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Sasha Shpota
    @Shpota

    Ok, tonight I'll bring more detailed descriptions and make first steps (I am in GMT+2).

    I am also planning to translate README to different languages. I'll handle Ukrainian, Russian and, if I manage to, German.
    If you have a desire to translate it to any other language I will gladly accept them. Just add a translated README to the ./.github/ folder, for instance ./.github/README_de.md for German. Later I'll link all together so that a reader will be able to navigate from one language to another.

    Cara Sue
    @carasue
    I will translate it to Chinese
    Sasha Shpota
    @Shpota
    That sounds great! Thanks!
    Cara Sue
    @carasue
    done translate Chinese
    Cara Sue
    @carasue
    Time zone in Beijing, China (GMT+8)
    Sasha Shpota
    @Shpota
    Thank you very much @carasue! I will merge your changes tonight.
    Jakob
    @Jakob-em
    @Shpota I can help with the german translation
    We could use custom npm run commands in the package.json to avoid multiple Dockerfile for the different frontend options
    Sasha Shpota
    @Shpota
    @Jakob-em that sounds great!
    Jakob
    @Jakob-em
    What do you guys think about adding Authentication to the backend and frontend as this is a common feature for full stack applications. Therefore it would be good to provide the needed code for the quick start of a new project.
    Sasha Shpota
    @Shpota
    I think it is a useful feature. At the same time, I think there is a lot what to do which is more important. So I would postpone it until must-have features are done.
    Jakob
    @Jakob-em
    Yeah sure just wanted to ask for your opinion
    Sasha Shpota
    @Shpota
    @carasue I have merged your translation and added a clickable header section. Thank you!
    Jakob
    @Jakob-em
    Quick question: RUN npm install && npm run build --prod This line is from the Dockerfile. Why is the prod flag needed. I don't think that this makes any difference for the react build
    Sasha Shpota
    @Shpota
    You are right. I confused it with Angular build where this flag is used.
    Jakob
    @Jakob-em
    Yeah angular definitely needs it for production builds, but not as an argument to npm run build, because it would not get passed down to ng build which would result in a non production build
    Jakob
    @Jakob-em
    How do you think should we handle the different database initialization scripts for angular/react/vue ?
    Sasha Shpota
    @Shpota
    I am not sure I understand your question. Right now React has nothing to do with database initialization scripts. It is done by mounting a volume to a container via docker-compose (check templates/docker-compose.yml).
        volumes:
          - ./init-db.js:/docker-entrypoint-initdb.d/init.js
    .js extension is a probably confusing, but it has nothing to do with the front end. It is just that MongDB uses JS as a query language.
    Jakob
    @Jakob-em
    Yeah i saw that, but the script loads the entries for the UI demo, and if a user uses angular it would be cool if the api/technologies endpoint returns angular and not react :smile:
    Sasha Shpota
    @Shpota
    But it would do that in any way. The REST endpoint /api/technologies is implemented on the server (Go) side. Changing the front end framework won't affect the server side.
    Am I missing something?
    Jakob
    @Jakob-em
    Sure I understand that, but my concern regards the content of the database as the technologies endpoint should return the used technologies for the project and if the frontend react/angular/vue can be chosen while generating the project, the content of the database (demo initialization) must also differ
    Sasha Shpota
    @Shpota
    Ah, now I get you :) I would say, it is not an issue. This endpoint serves as an example for the user so that they can figure out how to implement similar changes. What we can do is simply add two more entries to the file.
    Jakob
    @Jakob-em
    Okay agree, sorry for not expressing this more clearly
    Sasha Shpota
    @Shpota
    No worries :-)
    Jakob
    @Jakob-em
    I just finished the angular template project, but without the changes to the generator (which you described earlier) my changes don't make much sense. Should I nevertheless open a pull request?
    Sasha Shpota
    @Shpota
    That's cool! If you don't regenerate the static files (static/generated.go) your changes are harmless after merge. I would suggest you to create a PR.
    Sasha Shpota
    @Shpota
    I won't be able to check your code today. I will do that tomorrow (I guess close to evening). Would that be fine?
    Jakob
    @Jakob-em
    Cool, no problem
    Inna Shpota
    @shpotainna
    I'm trying to add Vue templates :)
    Cara Sue
    @carasue
    I note nobody is working on the cli now(is any?), I am going to work on it

    I note nobody is working on the cli now(is any?), I am going to work on it

    I notice

    Sasha Shpota
    @Shpota
    @carasue 👍🏼
    Sasha Shpota
    @Shpota
    I didn't have time yesterday to complete changes of codegen.Generate(). But we can agree that we can change its signature to Generate(projectName, framework string) where framework would be one of "angular", "react", "vue". What do you think?
    Cara Sue
    @carasue
    @Shpota thus I do not have to handle the Generate() function, and leave it to u, is that right?
    Sasha Shpota
    @Shpota
    Well, I would not use a third party library to handle CLI, at least for now.
    The current CLI interface is only 16 lines of code. Adding --vue, --react and --angular would not make it much complex.
    At the same time, adding a third party lib to a Go app which is meant to be used by other developers has its implications. Apart from having to manage the dependency and it's transitive dependencies it might be that some of the dependencies require low level tools such as gcc to compile, etc (I am not sure though if https://github.com/urfave/cli requires them).
    My suggestion would be to implement it without a lib and only if the solution gets too complex use a third party tool.
    What do you think?
    Cara Sue
    @carasue
    @Shpota ok, u r right
    Cara Sue
    @carasue
    Done add arg to cli for frontend
    Sasha Shpota
    @Shpota
    Thank you! I'll review all PRs tonight.
    Cara Sue
    @carasue
    Do u think supporting Redis by default is good idea. I mean Go + React + MongoDB + Redis
    For me, a Redis is almost necessary in a project. What do u think?
    Cara Sue
    @carasue
    And should we use Trello to collaborate?
    project board is not that good to use
    I do not have the permission to edit it
    Cara Sue
    @carasue
    it also supports Github plugin
    Sasha Shpota
    @Shpota

    Do u think supporting Redis by default is good idea.

    I think supporting Redis might be an option. Though I don't think it should be by default.
    In what way do you think we can apply it in projects generated by Goxygen?
    Redis is often introduced to a web project when there is a need to cache something and all the other approaches do not lead to performance improvements. But this usually happens on later stages of a project and always require careful assessment.

    Jakob
    @Jakob-em
    I think it would add more value to add alternative databases to choose from for example an sql db instead of mongoDB
    Sasha Shpota
    @Shpota
    I agree with you. Also I've got several comments to add support for TypeScript.