Project structure?

[Fraasi]

I would definitely use node, express, react, react-router & mongoDB as a database, mlab even has a 500mb free, if thats enough for this kind of project.
TypeScript maybe, would propably make it too hard for many beginners to contribute.

To get things rolling, I'd just use create react app to get a nice start up set & the benefit of live reload when editing.

Looking at the existing site it is not clear why do we need a backend? Can't we get all the video info and links from youtube's api?

As this is github, we could have it build to docs folder to have it live on the net as this site is being build :smile:

[vimkat]

I'm totally with you on this! Node, Express and React are also on my list. I'm not quite sure about MongoDB... From what I've heard, Mongo is not that great when it comes to highly relational content (which, in my opinion, we would have) so maybe a more "traditional" database would be better suited here? I've seen some nice stuff over at "Coding Garden with CJ". It would be great to get @gruselhaus's opinion on this, since he is a lot more involved with databases on a regular basis.

I don't think that TypeScript would be that hard to get used to since it's basically JS with some nice stuff on top. The overall development experience would be a lot nicer though. But that's the discussion "Type System or Not?"... 🙃

Yes! create-react-app would be my choice as well! It makes it really easy to get started with React development. Would you mind taking a look at this and share your opinion?

In theory: Yes, kind of... The video title, description, etc. would be available through the YouTube API. However, there's no way of nicely parsing the description to get it to look like we have it on the current website. Moreover, contributions from the community should also be included here. All in all, a database would make life a lot easier. If you dive deeper into the inner workings of Jekyll (folder _jekyll in the main repo) you'll find some really "ugly" workarounds and hacks that are a pain to maintain. Jekyll was designed to power static sites and I tried to force it to work with dynamic content - more or less successfully, depending on where you look.

As this is github, we could have it build to docs folder to have it live on the net as this site is being build 😄

What do you mean by this exactly? Could you please clarify that? :smile:

[Fraasi]

In the github repository settings there's a choice to run your 'github pages' from the docs folder. So we could build the code every now and then to docs folder and have the unfinished site live on net, wether it's working or not, to let everybody see what it looks like right this moment. :bowtie: -This is of course only for static sites, if we have a backend server code running somewhere, this propably wouldn't work.

As for the database, I have no idea what kind of data we are dealing with and very little experience in databases, so whatever you think is best is fine by me. Although I have used mongoDB and mlab in one project and liked them. But I'll leave this and 'Entity-Relationship-Model' to the people who know what they're doing.

To type or not to type? The codebase is propably going to grow to the bigger side, so might as well type it to keep it more under control. We can't have those 'thisdots' running around unsupervised. :cop:

Separate frontend and backend?

• Yes.

REST or GraphQL?

• I've heard only good things about graphql, so graphql, if possible. Might as well learn that also.

possibility to focus on one thing at the time

• Not sure what you mean by this. But in general, yes, it would be nice to focus on one thing at a time :grin:

backend API could be used in challenges

• How? What are you thinking here?

frontend devs don't have to care about database queries, etc.

• Not sure what you are planning here, but separation of all things is usually a good thing. That's what I like about react, having all those different components.

[gruselhaus]

@Fraasi In my view, a relationship database is best. Ok, I'm very much influenced by my daily work environment, but I think the SQL language is still the easiest to read and very logical.

[Fraasi]

@gruselhaus Yea, let's just go with SQL, so we can start building something. At least there's one in the team who knows about databases. Anyway I don't think we're going to have the most complex system ever seen 😄
I made a little repo with create-react-app with typescript support to experiment with things. code, live from the docs folder.
Maybe someone could take a look at the src-folder to see if things are organized enough. I have no experience building a site like this so I have a hard time seeing what is needed until I actually run in to the problem.
Maybe need to have a separate folders for 'server' & 'frontend' in the src-folder?

Seems like the front end isn't going to be too much of a hassle with react. Only the backend and where/how to get the data to render in react.

[vimkat]

Thank you @Fraasi! I'll take a closer look at it! Separate folders are definitely necessary. I'm not sure if we should even go with separate repositories? :thinking: Thoughts? Yes, the most work (at first) will be on the backend. Creating the infrastructure, API, etc. The frontend ist "just" porting what we have currently into a React context and swapping out Jekyll for API calls.

[Fraasi]

@nilsweb if I got this right: we're not going to call the database(DB) straight from the front end(FE), but have the FE call our server api and let the server communicate with the DB and then return the queried data back to the FE?
Shouldn't be too difficult, I actually made something like this with node, express and mongoDB about a year ago when I was going thru free code camps course. repo.

Only thing unclear for me is the whole database thing. Where to host it, what kind of data it is, how to query data from it, etc. By the way, are you planning on using some cloud service database or running it yourself on the server? Maybe we could make a temporary database somewhere with some sample data, so we could start playing around with calls to it?
Or do we need to plan out the whole infrastrucure before writing a single line of code?

Apparently monorepo is a thing, but I think it's better in this case to keep server side and front end on separate repositories, at least now in the beginning.

So that's a no on the rewrite of the site then, just port it to react. I'm not good at the design side of things, so that's ok by me. I'll just fiddle around with some components (that doesn't need database data) to see how react and typescript goes together in the meantime.

[vimkat]

Exactly! The frontend just communicates with the backend through our own API (REST or GraphQL) to achieve a layer of abstraction. The backend handles all database queries and final validations.

The database will probably hosted on some form of cloud server (Digital Ocean, Heroku, etc.) as well as the backend and frontend. I'm currently thinking of using Docker for managing all those instances since it allows us to keep them separated by themselves but still compose them together into one application. We should at least come up with how our database should look like before writing too much code. There will be some changes to how the data is related to itself compared to what's going on with Jekyll to make maintenance a little bit easier in the long run.

I think there won't be too much changes on the frontend at first (apart from bugfixes... 🙃 - check the issue page of main repo) so we can move to the new system quickly. The initial goal is: Nothing (or not too much) changes for the end user. After that we can add new UI features (searching, filtering, featured challenges, etc.) incrementally ("release early and often").

One thing to keep in mind: You don't need to use TypeScript for everything if you're not comfortable with it. We can add it where it makes sense and leave it where it would get too complicated. Let's wait for what you'll find out during testing and then make a final decision. :+1:

[Fraasi]

We should at least come up with how our database should look like before writing too much code.

I think our database should look more like a Bob Ross painting:evergreen_tree: than 'I refactor that later'-code :rainbow:
😸

We can add it where it makes sense and leave it where it would get too complicated.

I'll keep that in mind. So far no typescript needed, I already started on the header. Propaby need to get that react-router going next to get the links working. Oh well, one step at a time.

It would be nice to have others (are there others?) also comment on our choice of frameworks/libraries or ideas in general, or is it up to you and we can consider at least react settled?

[vimkat]

I think our database should look more like a Bob Ross painting🌲 than 'I refactor that later'-code 🌈 😸

Yes! Let's do it that way! 🚂

Apart from me and you there's also @gruselhaus who want's to work on this project. Maybe @shiffman could mention it in the next stream? There might be others that want to help too? 🤔

[Fraasi]

Alrighty then. We work with what we got. No worries, if @gruselhaus can work the intricacies of the mysterious databases, we can make this work. I think @shiffman is going to lose his train whistles trying to react his code around typescript :smile:
I'll see what I can do with 'porting to the front end' - little by little, while everybody's looking the other way and talking about 'how' to do things.
I'm sure you correct my mistakes along the way.

[gagangaur]

Hey I too would love to contribute to this project so from where are we starting to get all these things done by the way.

[Fraasi]

Hello @gagangaur, welcome to the project!
The backend repository is here - Not much happening there yet.
And the frontend repository here - We already started to lay the groundwork there, so check the issues page.

@nilsweb maybe you could put the links to repos in the readme for easy access to new people who stumble here?

[gagangaur]

Hey @Fraasi can you help me out in figuring like what would it be actually looking like by the end like i am talking about this whole front-end stuff like there is nothing listed about the actual looks of the website so please can you elaborate that so that we can work upon those things.

[Fraasi]

@gagangaur Well, apparently the coding train website grew too big, so it has to be rewritten to support all the new passengers 😄