Where communities thrive


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

    Hi,

    As some of you asked and offered help, let me share my plans on developing the project.

    Apart from general improvements such as test coverage, bug fixes, the next milestone would be support of other popular SPA frameworks.

    To achieve this some architectural changes are needed. At the moment, Goxygen takes files from the templates folder and creates a project structure by these templates filling in placeholders. This can't work the same way after adding Vue and Angular as the system would have to pick templates specific to a concrete SPA framework.

    I have created a Kanban Project on GitHub to track tasks related to adding new SPA frameworks: https://github.com/Shpota/goxygen/projects/1/. I will soon fill in the projects with tasks.

    On a high level I see it like this:
    The user should be able to run goxygen passing --vue, --react or --angular as an argument.

    go run github.com/shpota/goxygen init --vue my-app

    The system should also allow running the command in an old way. This way it should default to react.

    This will require the following changes:

    1. Changes in cli/cli.go to accepts --vue, --react and --angular as an option. As a result, it should invoke codegen.Generate() passing the selected front end framework and the project name. Eg. codegen.Generate("react", "my-new-app").
    2. Changes in codegen.Generate() and templates structure.
      Templates now have to specify the framework. Instead of a single webapp folder there should be three angular.webapp, react.webappand vue.webapp and codegen.Generate() shoyuld be able to figure out which one to use depending on the input parameters. This might also require introducing different Dockerfiles.
    3. Move React templates from webapp to react.webapp.
    4. Add Angular templates to angular.webapp. The structure of components should repeat the one which is implemented for React (ef. there should be a tech component that makes a REST call). The generated application should offer the same UI as in React (CSS can be reused). The app should have two profiles with different REST API endpoints for development and production.
    5. Add Vue templates to vue.webapp following the rules from the previous step. The app can use axios as for REST calls (if Vue doesn't have an embedded HTTP client).

    I'll soon transfer these options to tasks on the project board https://github.com/Shpota/goxygen/projects/1/.

    Of course, these are only drafts. Actual implementation might require some other changes or different architectural approaches.

    If you have some other ideas or have the willingness to help feel free to write in this chat and we can discuss the details.

    Thanks,
    Sasha.

    Cara Sue
    @carasue
    I'd like to help with the Vue enhancement
    Mathias Sebuuma
    @mattb2401
    Would like to help on the cli and angular support
    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