UltraRangers / gauntlet

Gauntlet is a Typescript server template to kick-off your development fast 🔥🔥🔥
https://gauntlet-demo.herokuapp.com
MIT License
3 stars 0 forks source link

Demo Site Setup #15

Closed john20xdoe closed 6 years ago

john20xdoe commented 6 years ago

Heroku

Postgres

Github

john20xdoe commented 6 years ago

@cedrickmandocdoc @jmaicaaan @dach020 , I'll be requesting your email addresses again later so that I can invite you as collaborators to the Heroku account for the demo app

jmaicaaan commented 6 years ago

Mine is johnmichaelubas.santos@gmail.com. I'm working on the next branch which includes a few changes on the structure.. again. I'll be finalizing it over the weekend and help setup this demo.

I still need to work with the client side. Just finished with the server right now

jmaicaaan commented 6 years ago

Hi @john20xdoe, in the next/develop branch I've setup the application for demo.

However, since I'm not yet able to view the credentials provided by the heroku. I've added under config/server/ormconfig.heroku.json a config file that needs to be change according to the provided credentials. Kindly change it accordingly if you may. I've added already the procfile which will be needed by heroku to run the app. Also, please set the environment in the heroku as NODE_ENV=heroku so that it will use the ormconfig.heroku.json throughout the app.

Regards

ghost commented 6 years ago

@john20xdoe my email cedrickmandocdoc@gmail.com. Do we need to create a group chat? I feel like I don't know what is going on haha.

jmaicaaan commented 6 years ago

I did create a new branch with a new structure to keep moving then which is in the said branch. I copied some things from different branches including your database pr and client structure with a different structure one. Feel free to check it out.

I closed some issues and moved it into that branch. It seems like the issues are not currently moving and progressing so I decided to close it out and make a new start

john20xdoe commented 6 years ago

Sent you invites as collaborators. You can set the demo branch to deploy here: https://dashboard.heroku.com/apps/gauntlet-demo/deploy/github

Note the branch will need db credentials. I think you need to add env variables there and then set the values here: https://dashboard.heroku.com/apps/gauntlet-demo/settings (see the Config Vars section) I've already added NODE_ENV=heroku there.

The postgres credentials can be found here: https://data.heroku.com/datastores/dc1a2b30-e0e7-4e83-bf7f-a4dfc434cf8c#administration

john20xdoe commented 6 years ago

@cedrickmandocdoc I may not be able to stay online for group chat hahaha. Don't worry, just need the credentials above and the branch to be set in the heroku settings, and it will auto-deploy for every push/merge into that branch. @jmaicaaan I have set the env variables in Heroku's Config Variables. https://dashboard.heroku.com/apps/gauntlet-demo/settings The variable names are: DB_HOST DB_PORT DB_NAME DB_USER DB_PASSWORD and DATABASE_URL (this one is the url starting with postgres://) You can now add these to the ormconfig.heroku.json file.

jmaicaaan commented 6 years ago

Please excuse my commits as I've test/push a lot because of the trial and error due auto-deploy and unit testing 😄 Our auto-deploy I believe is now working, here's the link for it. Currently, I've used the next/develop branch to perform it.

One error found is about the styles.scss -> @import '~@angular/material/prebuilt-themes/indigo-pink.css';. I can't get this one to work even I've updated the webpack configuration. I'll be opening an issue and you guys might try it up 👍

Also, if you guys can look up on the said branch and wonder if we can make it as our new starting point so we could progress and not even stuck with the structures again. Cheers 🥂

Plans for the future:

.. And then afterwards we could easily scale this one up. Like setting a new technology which could be just in breeze ⚡️

john20xdoe commented 6 years ago

Great job, @jmaicaaan ! I wasn't able to try this here at home since I don't have Typescript yet (Planning to install it after installing Visual Studio, which takes quite a while to download).

We are already implementing semver right? Maybe we can add the version (auto-added or embedded?) in the UI so that we can see later auto-deploys if they reflect in the demo site. The version will be directly linked to the Milestone name. Also, I realized we may need to rename next/develop later as release branch, though this is nothing major because our purpose only is to setup a demo site first, not yet official releases.

As for the future plans, we can add them to Github Milestones. So far do you have other additions for v1.0 (aside from the folder structure, which we can move to next version milestone)? So that we can move forward the next/develop branch (as v1.0) as the new working baseline for master, before resuming the revisions.

john20xdoe commented 6 years ago

Closing as so far no more remaining tasks for detting up demo site. The other matters are/can be created as new Issues.

jmaicaaan commented 6 years ago

Hi, right now I'm still not good on moving this one up to 1.0.0. It is not yet that good and ready to be up there. Let me get a few hits first on it and I'll bump you guys if we're ready for 1.0.0.

You may wonder why I'm not yet sure. It is because I feel like there's still some changes needed to be made before going to be stable. The client side hasn't been likely touch compared with the server. Has only been tested with a single api endpoint.

The idea of adding the version to the client side which is from the package.json would be cool. Adding it to the right side bottom or to every requests we made to api it will add it to the request headers. :smile:

jmaicaaan commented 6 years ago

Also, I would like to hear some thoughts about our current code or structures from the rest of you guys. Prolly you still have thoughts on it. Happy to hear it 🙆‍♂️

john20xdoe commented 6 years ago

Ah I see (I've not yet really delved into the code yet so I wasn't aware of the state of completion). Sure, that's ok, no rush. =)

Given the range of TODOs, I think I'll rename the milestone from 1.0.0 to 0.1.0 (and move up from there, 0.x.0, etc before going 1.0.0 later). We can allocate any current or new issues or TODOs to each milestone so that we can verify our progress. (The technique is not to see how much progress % accomplished, but to see how much more is remaining to be done.)

I'll also check the current code later and give my two cents once I resolve the troubles in my local PC.

ghost commented 6 years ago

Hi, this is my feedback for the next/develop branch.

The structure is good, but I am not fully convinced. For what I can see, there are featured modules (user, roles), common and entities inside the server folder. I am ok with the featured modules but the database module outside is not probably good. On my mind, I imagine that we only we have one module outside and it is our application module. Then our application module consists of different modules based on our needs. So we are building here like a server application right? But then not all server api will have a database interaction like pdf generation, download files and etc. So having this in mind we can never assure that all server application needs a database always. Then we can conclude that database is a module only inside the application and not outside.

So for I can see here, the database is tightly coupled in our app. Imagine if I am going to develop server that doesn't need too much db then I will restructre this to remove database and it is hard since our entities, repository, migrations and seeds are not in one place. Also I can see that featured modules always have a repository, but there are some that doesn't need it. Though we can just remove it here, but the structure is somehow broken, because if we encounter featured modules that don't have a repository. Then the definitions of featured modules will grow (something like, featured modules sometimes have a repository sometimes haven't). This break strict definition of our functionality.

For me the database should be a module that can be imported (this is supported here) and remove easily That is why before I created the database module in one folder. So we can easily removed it if I want.

Just a recap here, in this scenario our app requires db but not all applications. So I am proposing a database module that is not tightly coupled.

For the common folder, I am good with that but it is also good if it is a module.

For the summary I am imagining something like this, for both client and server

We have application module. then inside are just MODULES that the app requires.

Flow: Core module is imported once in app (to be singleton), though in nest all modules are singleton Common module is imported only in featured modules, depends if need it or not. Featured module is imported in app, to expose outside.

jmaicaaan commented 6 years ago

I'll try to update the milestone later to have an ideal view on what we are expecting for the 0.x version.

Sure, that would be great to have. I do expect there will be no further installation needed in your case. Also, can you try the docker on your machine? Seems like on my machine it is taking so long the process of installation of docker. Let me know some updates with your installation 🙌

jmaicaaan commented 6 years ago

Hi ced, can you provide a tree view or a screenshot on your proposed structure? Please open an issue and attach there a tree view or screenshot so we could view it. Let's stop on this thread already about structures 🙆‍♂️