Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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.
    Jakob
    @Jakob-em
    Concerning the react project ?
    Sasha Shpota
    @Shpota
    Yes, at this point there is only React.
    Sasha Shpota
    @Shpota

    I have implemented this part.

    1. Changes in codegen.Generate() and templates structure.
      codegen.Generate() should be able to figure out which framework to use depending on the input parameters.

    Please take a look at the PR: Shpota/goxygen#32

    Jakob
    @Jakob-em
    Done :thumbsup:
    Sasha Shpota
    @Shpota
    Thank you! I'll apply the changes tomorrow.
    Sasha Shpota
    @Shpota
    I am working on the CLI implementation for the --frontend option. These are breaking changes and I'm going to merge them only after I check and test everything precisely. I have not included the regenerated static/generated.go file yet.
    Here is the PR: Shpota/goxygen#40
    It would be great if somebody could take a look at it and say what they think.
    Jakob
    @Jakob-em
    What about creating the generated.go file as part of the CI workflow?
    For example every time a commit is tagged with a version, the generated.go file could be generated and a new github release should be created.
    Sasha Shpota
    @Shpota
    I generally like this idea. The only concern I have is security. I am not sure how it is like with GitHub Actions, but there was time when anybody could simply run echo $ACCOUNT_SECRET in Travis and get write access to an account :)
    But it is certainly something that requires improvement. An alternative solution would be to manage templates in a separate repository and fetch them via network on the client side.
    Sasha Shpota
    @Shpota
    I have just published Goxygen v0.2.0. Thank you for your contributions!
    https://github.com/Shpota/goxygen/releases/tag/v0.2.0
    Douglas Souza
    @douglas-DS
    i've opened right now a pull request for a translation to pt-br of README file
    Lox3ur
    @cgaspart
    Hi all, when i try go get -u github.com/shpota/goxygen i have this message: # github.com/shpota/goxygen/codegen ../go/src/github.com/shpota/goxygen/codegen/codegen.go:26:13: undefined: strings.ReplaceAll
    Anthony Anonde
    @tonymj76
    hello everyone am new here so please be kind lol... am trying to build a web app with revel +vuejs wasn't easy but it worked at last... then i tried with Nuxtjs due to SEO... but i have not been able to do that with Revel... so my question is Goxygen is great but can it work with nuxtjs?
    Jakob
    @Jakob-em
    @cgaspart