Nuxt Front End Conversion

[jrtechs]

Refactor code to use a template engine.

[petermorgandev]

Did you have a particular template engine in mind?

[jrtechs]

Not at the moment. I was initially thinking about a backend templating engine however, @ct-martin convinced me that we should probably use a front-end templating engine. What are your thoughts?

[petermorgandev]

I have used Pug on a project before. Like anything, there were some things that I liked and didn't like about it. It is pretty easy to implement though. If you don't have a particular preference for which engine you use, I could probably implement Pug fairly quickly.

[ct-martin]

Hi @PeterMorganGH !

I started trying to convert it to Nuxt today. Biggest problems are that (1) some of the pseudo-templating wasn't consistent and (2) the JS is all global scope. Regardless of what is used for this, some cleanup will be needed.

I'll be reporting back in a couple days on how Nuxt goes; don't let me stop you though if you want to take a go at Pug.

[petermorgandev]

@ct-martin It sounds like there are 2 different goals here. The first goal would be to use a template engine like Pug to simplify the .html files found in the /public. This is a fairly straightforward process. The second goal would be to use Nuxt (or Vue by itself) to recreate the front end experience - replacing the html files in /public. This would obviously require more work.

Any thoughts on this?

Related: I do see specific areas for improvement in the JavaScript portion of the project. Most notably, newer syntax could be utilized as well as async/await functions instead of callbacks. I have a branch on my fork where I started refactoring a lot of the files - though admittedly, I think I broke something and I haven't figured out what just yet.

[ct-martin]

@PeterMorganGH I would say (from my point of view) that Nuxt is a different way of generating the HTML in /public. Part of the reason I think Nuxt is worthwhile to try to do is because of how much of the UI is already generated from JavaScript. The advantage of Nuxt over Pug is that it's also a JS framework so it can be utilized to do really nice things with Webpack and scoping/hot-swapping JS. The disadvantage of Nuxt compared to Pug is that it is more complicated to retrofit and some of the JS refactoring (particularly for scope) has to be dealt with now rather than incrementally later. I don't think one is necessarily better than the other per say and I think there's a lot of overlap in what will be done. I'd like to try to get Nuxt to work but it's pretty undetermined right now if that will work cleanly so I'm not dead set on it. I have my WIP here if you want to look: https://github.com/ct-martin/github-graphs/tree/frontend-refactor

I'd be interested in collaborating on the JS refactoring if you're up for that. I'm not going to be doing any more on this tonight but I'll see anything you post in this thread tomorrow.

[petermorgandev]

@ct-martin I would be happy to work on the refactor. I took a look at the branch you linked and started with a small change to the about page. I have used Vue before, but not with the Nuxt framework. I don't think that will be a problem though. With the amount of progress that you have already made, I don't see a point in implementing Pug to the main repo.

@jrtechs The discussion this issue has brought up is making me think that this issue could be renamed to something like "Nuxt Front End Conversion" if that is the way you want to move forward. Once you start getting into something like Nuxt, you're dealing with something much more complex than just a "template engine".

Not to go too far down the rabbit hole, but if the project is moving towards using Nuxt , I am not sure how much work the current Node app will actually be doing. From my understanding of the Node portion, is is a proxy to the GitHub API with caching and authentication. That functionality might be able to be integrated directly into Nuxt - I'm not sure.

[jrtechs]

@PeterMorganGH I initially wanted this to be solely a front end application. However, if you don't have GitHub API credentials they limit how many unauthenticated requests you can make. I think it was around 50/hour which is barely enough to make a single friends graph. We sort of need to keep the Github API in the backend so we can keep our credentials private. Plus, in the future with the caching, I want to make this slightly more efficient.

[petermorgandev]

@jrtechs Thank you for providing additional context and renaming this issue. I see now that the "backend" Node app is still necessary. From my new perspective, it sounds to me like one potential way to move forward is to:

1. Decouple the back end from the front end
2. Rewrite the back end to be more of a stand-alone API proxy
3. Refactor the front end using Nuxt - which gets its data from the back end API proxy

Thoughts?

[jrtechs]

@PeterMorganGH that would be great! The content in the "public" folder can be hosted on any web server. I'm not that familiar with Nuxt but, whatever would be the cleanest for development would be ideal. If we do decouple the two, it would make it possible for people developing locally on the frontend to just point their API setting to the backend already running at github-graphs.com

If we do decouple the two things into different node applications, I want to implement #14 so that it would be easy for people to develop with and get onboarded into the project. Going into the spring, I'm looking at getting around 3-6 people from RIT to work on this project with varying skill levels and backgrounds.

[petermorgandev]

@jrtechs I'll see what I can do on the API rework this weekend.

[ct-martin]

@PeterMorganGH when you're working on the API rewrite could you make it so the API can be on a different subdomain from the front-end? This would help me out in doing a hosting trick so I don't make my VPS sad trying to compile Nuxt (again...)

Edit: Sorry, just realized I missed part of the discussion. For my needs right now all I need is the ability to change domain in calls to the API; the rest works fine for what I'm trying to do right now. Also, for what it's worth, Nuxt will generate a 404.html fallback for calls that the hosting part of the back-end should be able to point to (also used in dynamic routing; this can be handled later but wanted to document).

[petermorgandev]

@ct-martin I saw that @jrtechs was doing some work on the API yesterday and today to make it perform better. It seems like no more work has been done since a few hours ago, so hopefully any work I do won't cause any conflicts.

I'm trying to think about the best way to deal with the potential hosting issue. There are a couple ways one could go about it:

• Create a separate repository for the front end and make the current repository specifically for the backend.
• Move all of the files in the current repository into a "server" folder and merge in the "client" folder containing the front end code.
• Something else I haven't thought of yet...

Thoughts @jrtechs @ct-martin ???