First steps

[gabrielcsapo]

Just wanted to see where we can go from here @echopoint @plunkettscott @jlxip

[jlxip]

Are we going to store the data in a DB? Or how are we going to do it?

You can copy as much code from UltraGit as you want if it can help you.

[gabrielcsapo]

@jlxip I assume we are going to store information in a DB. Github has an interested way of having federated control at the application level https://enterprise.github.com/features which means they are constantly listening for data and synchronizing it between nodes. Interesting this can be done using node-git-server as seen here https://github.com/kubenstein/starbucket fairly easily.

[plunkettscott]

Github Enterprise does a lot of things well. How in-depth are you wanting to go with this? Are you wanting to allow searching the repositories like Github does?

Scott

[jlxip]

Github Enterprise? I was seeing this project as if no money were related. I don't think this is a startup.

[gabrielcsapo]

@plunkettscott I was just looking at examples of well established ideations of this, I think it should be designed with expansion in mind rather than creating it over and over again.

@jlxip definitely not a startup, just using it as a reference project with well established direction and material.

[echopoint]

Keep it simple and extendable. Take a page from fossil's book. Up front we we just need the basics to manage the repos and user access, possibly issue tracking. Can't see much more than that up front.

[gabrielcsapo]

@echopoint I am up for that. Any technology decisions? sqlite? I want to keep the dependency tree as small as possible as to avoid any c++ dependencies that could impair the platform from being deployed on any device that could run node.

[echopoint]

Avoiding C/C++ dependencies kills almost all dbs unless they have a js implementation of their client protocol implemented. I would make the database piece a simple model that would need to be implemented no matter what the backend would be. Then we can just keep adding extensions for different db's, etc, via a model plugin that handles that db or even lower but there isn't really much need for much lower level than that interface. This way it's transparent to the ui and the rest of the system as to what db is being used in the model. Using such an interface you could also ditch the db altogether and store the records however you want and it wouldn't matter, even as json on the fs and it would still work appropriately.

[gabrielcsapo]

@echopoint that makes sense. SQLite would be a good initial DB implementation for the ORM. Mongo has a fully Javascript implementation library so that could be another choice as well.

[echopoint]

oh dear, please no orm, haha... just an expectation of the interface that faces the app is enough. orms are a huge mess of franken spaghetti 😬

[gabrielcsapo]

@echopoint as I see! Okay haha no ORM 😂

[gabrielcsapo]

@echopoint thoughts on first steps? Should we come up with a list of features we want to see first?

[echopoint]

Yes, we should decide what's needed up front and strip that list down into tasks. 😄 So far we have :

• [ ] basic site design and layout
• [ ] user creation and management
• [ ] user repo management
• [ ] administration controls
• [x] app framework skeleton

[gabrielcsapo]

• [ ] repo meta data
  • [ ] issues
  • [ ] pages
  • [ ] access (private or public)
• [ ] search (this would depend on access control)
• [ ] backup (would need a data format to contain database information as well as repo data)

[gabrielcsapo]

@echopoint I will have some time this weekend to get an MVP done to have something to discuss more specifically about if that works?

[gabrielcsapo]

@echopoint for right now each view can be stateful via the url so for example

/:name/repos

could be easily rendered using template strings

function renderUserRepos(user) {
   const repos = await User.getRepos(user);
   return `
      <ul>
        ${repos.map((repo) => {
          return `<li> ${repo.name} </li>`
        }).join('\n')}
      </ul>
    `;
}

Again this is just really quick example of what I think can be done with no UI framework, but bringing react and such in would have added benefits for being able to test these views.

[echopoint]

I have a router in the app framework locally that can handle that kind of route just fine. So no worries. Let me finish the part I was working on and I'll push the bare bones up. I didn't create any form of template processing for it at all for views / renders. Though if you want to use react, then go for it.

var server = App.create("https://localhost:7000");
server.get('/api/:ver/', async function(conn, ver) {
    conn.content = "Get request: " + conn.method + " :: " + conn.uri + "<br/>\n" 
                 + util.inspect(conn.query);
    return 200;
});
server.start();

[gabrielcsapo]

@echopoint depends on what you want to do, we can make it work and refine later. You rock, can't wait to see what you have!

[echopoint]

well I needed the fw and I don't exactly like express, but don't hate it either.. and for views / ui, I just didn't do anything because that always differs. depending on the project. I like working on the server side more anyway, though I have no issue with react. I opted for my own fw before just didn't know if we could use it here or not because not sure what everyone is comfortable with.

[echopoint]

btw, if we use this thing, I didn't allow regex in the routing. call me lazy. Though, I like cleaner and easier to read interfaces that are self descriptive more often than not. 🙈

[gabrielcsapo]

@echopoint sounds good to me! Certain routes we might need to have regex for or we might to dynamically generate the routes and their handlers. For example if we add a user foo then we could procedurally generate:

• /foo/profile
• /foo/repo
• /foo/settings

No need for regex at that point.

[echopoint]

• /:user/profile
• /:user/repo
• /:user/settings

This does the same thing, but captures the name in :user and sends it to the handler with the request. i.e. /:user/profile would call handler(conn, 'foo') or handler(conn) with conn.params.user = 'foo'.. And if we need regex in the handler route uri, then I'll add it. just didn't want to deal with it at that point in time 🐙

[gabrielcsapo]

Yeah I totally understand, I am saying if we didn't want to implement regex, we could use dynamically created routes. 🦑

[gabrielcsapo]

@echopoint do you want ownership of this repo so we can move the trello kanban to github projects?

[echopoint]

No need.. That trello was for my reference 😃 If we use the fw, then I'll worry about that. Right now I'm just slowly reapplying pieces back to it that I was working on earlier and rechecking it.. Basically I made it because I was bored, but it may be a good idea.

[gabrielcsapo]

@echopoint I like it! The DX in the examples in server.js looks really nice. The reason I am not a fan of express is the fact that you can set priority in the middleware chain by default. https://github.com/krakenjs/kraken-js fixes this (I work at PayPal on the NodeInfra team) and it is pleasant, but if you can do that without leveraging express I would be super happy to use that as a dependency.

[gabrielcsapo]

side note, whatever we make, please let's make it nicer than bitbucket...Github is so simple compared to Bitbucket and Gitlab.

[echopoint]

Well, that's a matter of time. It's already that far without leveraging express 🤐

[gabrielcsapo]

@echopoint awesome!

[echopoint]

@gabrielcsapo modules are in, let me know if that fits for you on them.

[gabrielcsapo]

@echopoint I am good on anything, we can refine when everything gets in

[gabrielcsapo]

@echopoint do you want to open a PR or do you want me to?

[echopoint]

talking about the fw? I'll finish the last couple of changes I was in the middle of and push it up.

[gabrielcsapo]

@echopoint 🙌 awesome!

[echopoint]

We should start thinking about an org for our stuffs. Starting to get quite the collection 😆

[gabrielcsapo]

@echopoint we can definitely move it to an org, do you want to do that?

[echopoint]

sure. we need a name for it. 📌

[gabrielcsapo]

@echopoint true true what about 🚀https://www.npmjs.com/package/ghan which is a name of a famous train 🚂 that would be awesome! I don't know I am bad at names that took me 40 minutes

[echopoint]

Only reason I wouldn't jump on that is the association to an in service train. Don't know how much they will care, as it's meant to be an homage. What about allegiant? That's the only alternative I have atm.

[gabrielcsapo]

who is that is a cool name!

[echopoint]

@gabrielcsapo ok, allegiant it is.. made and you're a co-owner 🌠 I'll close the pr and add the fw as a package for allegiant.

[gabrielcsapo]

You rock! So excited for this man!

[echopoint]

@gabrielcsapo created an org on github to collect all repos in for npm.. I figured this was the better way: allegiant-js. You're also you're co owner, as soon as you accept. 👏

[gabrielcsapo]

@echopoint accepted, are you going to add the allegiant framework there?

[echopoint]

Yes and splitting out the libs appropriately.

[echopoint]

@gabrielcsapo core is up.. that's the most basic core module needed, hence core. Still things to do, but that can come with time, since full docs are still needed, and activating coverage on most of the other modules. If you need to make a change, and the build passes travis feel free to commit. I've been under the weather the last 2 days, so taking the rest of the night off and tomorrow mostly off.

[gabrielcsapo]

I have also been DOA @echopoint I am enjoying some time off before I start a new job so anything new is slowly but surely making it on my todo list. If you need help with core, I can start closing out issues if you open them up!

[echopoint]

Already fixed the issues that cropped up from splitting the modules out as they were being posted. So far it's working fine. Since I can switch between these and my local original, without any issues at all, then it's definitely right.

[gabrielcsapo]

Miss everyone, hope you are all well, thoughts on making this a thing again?

[echopoint]

no problems from this end, just need to define the need and go from there