Directus: Explain which repository is the main repository?

[AntiCZ]

Hello, I am new in world of Directus. I can feel this is the very power tool and I would like to use in projects. For now I just warm up with small pull requests. But I understand this is open-source and open-source does not mean It is free. I have found several bugs and I know make a Issue is nice but make pull request is better.

So my question is about Repos. Directus/directus is just for clone and run. But I am confused about directus/api and directus/app. What is the main develop repo? I have found Vue.js sources (interfaces) in directus/api. This is confused me. I thought directus/api is PHP and directus/app is Vue.js.

Sorry for my English. I hope it is understandable.

[vzool]

Same issue here, I want to make PRs for this great idea.
But, I'm confused too 😕

[shealavington]

If you're looking for the product that's "ready to go", you're looking for the directus repository, clone and it's ready to go. If you're looking to have multiple tenants running multiple API's, but you'd like them all to be accessed through a single APP, then you can put the APP in one location and API's in multiple locations, but access the API endpoints all through your one APP.

If you're looking to make any PR's, you'll want to make them respectively; in the APP repository if you'd like to modify the frontend, or the API repository if you'd like to modify the API.

To modify the frontend, I highly recommend importing the 'app' through the "vue ui", which gives you access to hot-reloading of the frontend, and if you'd like to modify the API, docker is a quick way to load up the API in a container.

Hopefully this clears up some confusion? Also, for questions like this, it's probably best if you join the slack rather than opening an issue: https://slack.getdirectus.com 😄

[vzool]

Aha, I thought it was using submodule to combine all these stuff together in Suite version. Something is missing in API version, I noticed that there is no any customs directory in the API.
There should be Hooks, Filters and many other things made specifically for the API and this directory does not exists in API repository. Why is that? 😥

[rijkvanzanten]

I noticed that there is no any customs directory in the API.

This one @vzool? https://github.com/directus/directus/tree/master/public/extensions/custom 🙂

[vzool]

Hum 🤔, if there is a PR will modify and add files/directory to extensions/custom, API Core and its composer.json in the same time. How can I do this while every single part in different corner? 😆

[rijkvanzanten]

How can I do this while every single part in different corner?

I'm pretty sure all those files are in the same corner directus/api 😄

[benhaynes]

I have added a little more info about the App/API/Suite here. Next I'll be add/updating a contributor section...

[vzool]

@benhaynes OK, you mentioned that you just combine all these packages together in Suite without any "unique code". 🤔
But, I noticed there is inconsistency between these two repositories directus/api & directus/directus.
For instance, this place in API is out of sync for 6 months when compared to this one. 😕
And this repository directus/directus is not for Read-Only as a mirror, it does accept PR all the time.
So, I think @AntiCZ question still remains solid to the ground! 👮Which repository is the main one? 🤓

[rijkvanzanten]

For instance, this place in API is out of sync for 6 months when compared to this one

The code should be the exact same, as the API is literally copied 1-to-1 to the directus/directus repo in a new commit 🤔

And this repository directus/directus is not for Read-Only as a mirror, it does accept PR all the time.

Fair! @benhaynes we should look into how to make the repo a read-only mirror

Which repository is the main one?

directus/app for the app, directus/api for the API (and the extensions). Those two can be used individually. directus/directus is "just" a combined version of the build branches of the two main repos provided as a convenience.

[benhaynes]

We can make the repo read-only, but we'll probably have to "undo" that each time we want to release new versions. I'll archive it now (readonly) and we can test with 7.0.5 today.

[shealavington]

@vzool I expect they look "inconsistent" because there's a full version commit on the full-suite, pretty much weekly (Why is why it says 7 days ago). Although the files are, from what I just looked at, the same.

[rijkvanzanten]

wow wait, archiving is something else

[benhaynes]

So to make a repo readonly, we need to "archive" it. GitHub says this is more for:

repository isn’t actively developed anymore and you don’t want to accept additional contributions

This also doesn't allow for issues, etc. So i don't think we want to do this. Perhaps we just say something in the README?

[rijkvanzanten]

because there's a full version commit on the full-suite

Which allows you to run git pull origin master to upgrade your Directus installation 🤔

[shealavington]

Yesterday, Github put a new "Issue Move" beta tool into operation, so issues in the full-build repo shouldn't be an issue.

[benhaynes]

Exactly. I wish they did it last week... when I manually migrated all the v6 in directus/directus to a legacy repo! :/

But yes, will be really helpful for moving tickets to where they belong!

[rijkvanzanten]

I think the conclusion here is that we either look into how to make the repo "properly" read only and add a note to the readme for now?

[vzool]

This is a good move. 😃
Consistency always matters, a change of one char means a change for all the others. 🤓
But, there is a better solution. 🤔
I suggest, if you just make this directus/directus repository as an interactive building script only to download and compile for the user what he/she needs, anyone can clone it and complete the producers as normal with a few extra steps, this will be so awesome. 😍

Something like this:

> directus install
----------------------------------------------------
Which version you want to download:
----------------------------------------------------
1- Directus Suite (App & API).
2- Directus App (Vue Application only / Front-End).
3- Directus API (Core).
----------------------------------------------------
Select between(1, 2, 3): 

Thanks for this great idea folks 😘

[benhaynes]

I like that! But we'd lose the zip/tar ability for shared servers... and our precious ⭐️ count on directus/directus 😉

[rijkvanzanten]

But we'd lose the zip/tar ability for shared servers...

We'd have a build branch on directus/directus which would still release to a zip.

and our precious ⭐️ count on directus/directus 😉

The interactive building script will still be hosted on that repo 😄

[benhaynes]

Ahh, that makes more sense!

[benhaynes]

How complicated is this to build?

[vzool]

I like that! But we'd lose the zip/tar ability for shared servers... and our precious ⭐️ count on directus.directus ;)

I see, then you have two options here as I think:

• Option 1: Create a new branch installer , delete anything in it then push it to the repo and make it as the main and primary branch for the repo. So, you can start fresh again. And for the shared servers host last 10 versions as a maximum and keep track for it when you do a release. Finally add "If you like our products, don't forget to star us"

• Option 2: Create a new repo directus/installer.

I prefer the second option 😆and I like this build branch idea @rijkvanzanten but try to keep everything up-to-date 🙏🤓

[vzool]

How complicated is this to build?

Not so much if you found the right tools. I suggest to use laravel-zero. It is really easy and give us a nice and colorful command line in php 😍
Even though, it can compile anything into Phar format. 🤓

[rijkvanzanten]

but try to keep everything up-to-date 🙏🤓

Ho! Build branches are up to date. Weekly release! 😄

[shealavington]

IMO: I think an installer creates unneeded complexity. I've not had issues just downloading the repo I needed. I mean, it's not a bad idea, but I'd still expect repositories for the API and app and it would just make for more work to maintain another repo. 🤔

[vzool]

You still need to maintain the new branch as well as you do with the new repo,
this is prone to error and I feel it is a bad practice too. 🙈
I think if there are more than two branches in the same repo with different purposes, that is an indicator and a call for a new repo. I suggest to minimize the surface of error 🤓

[benhaynes]

A few more updates, but this should help clarify things a bit more:

https://docs.directus.io/contributing.html#repositories

[vzool]

I think if you clarify how you do compile anything into directus/directus. So, any crazy bash guy can transform that into lovely code. 🤓

[benhaynes]

Haha, ask and you shall receive! I'd love to hear your thoughts on this @vzool !

https://docs.directus.io/deploying-versions.html

The only thing that was updated (yesterday) was something to do with keeping the .gitignore files so that logs aren't tracked. @rijkvanzanten did that make it into the Doc?

[AntiCZ]

Thanks, guys :) I think is more clear to me.

My theses:

• directory: ./public/admin/ is directus/app
• evrything else is directus/api

Am I right?

[benhaynes]

That's correct, @anticz!

[vzool]

Thanks, guys :) I think is more clear to me.

My theses:

• directory: ./public/admin/ is directus/app
• evrything else is directus/api

Am I right?

@benhaynes No, I don't think so. My previous setup was easy and obvious which the version is this commit ab5a935, the structure of directories for directus/directus after commit 1c3fe10 has been changed dramatically without any notice. Before that I can setup a new app in seconds. But, now I'm facing many issues and this is one of them:

😕

[rijkvanzanten]

directories for directus/directus after that commit has been changed dramatically

Yes, as we released the next major version of the platform, which is a breaking change (as indicated by the major version number increase). The directory structure has been the same ever since, and is not going to change in a breaking way until the next major version release (which as of right now is nowhere on the horizon).

without any notice

I don't really agree.. We've been Tweeting about it, writing Medium articles about it, done public releases ever since alpha 1, launched a release candidate on this repo, and announced it on Slack on multiple occasions.

But, now I'm facing many issues and this is one of them:

This is because you're trying to use Directus 7 with a Directus 6 installation. v7 is a complete rewrite of the platform and isn't compatible with the v6 internal database architecture

[vzool]

Yes, as we released the next major version ...

Aha I see

I don't really agree.. We've been Tweeting about it ...

I just joined your loop lately 🙈

This is because you're trying to use Directus 7 with a Directus 6 installation ...

Strange, I just follow the steps in the docs, is it up-to-date 🤔

[vzool]

@rijkvanzanten I did give it another try hoping that I did installed the wrong version and it does install anything correct as the setup told me "API Successfully Installed", even I revised the database and it looks everything intact I guess.

But, when I tried to login the process fails with chunk of errors:

Hope these screenshots helps 🙂

[rijkvanzanten]

@vzool That looks very similar to https://github.com/directus/directus/issues/2224. I think whatever server you're using is not sending along the Authorization header to PHP. That explains why your user can login, but why every subsequent request is failing.

@WellingGuzman Do you think it's an idea to by default use the access_token query param instead of the Authorization header? It seems like there's more and more people who have issues with the auth header.

[vzool]

Aha, I did this testing on a Shared Hosting. Which they don't have options to change Apache settings. 🙈

[benhaynes]

Thanks @rijkvanzanten!

If using a query param is an option that would potentially solve all of these related issues, I'd say it's 100% worth it. Is there a downside?

@WellingGuzman 🔔

[wellingguzman]

The problem with having the token in the URL is that it will be logged (access_log, for example) and could get cached, or invalidate the cache on the API when the token change, meaning the url change (something that might be seen as an unexpected behavior).

It would be ideal though, but maybe this could be an option in the app? I feel the only drawback for the header in the moment is the bug #2224 that we haven't found a way to solve yet, while in the other hand they are more disadvantages using the query string.

Again the most important thing here is that we at least give them the option to use query string, so when someone install Directus but don't have a way to "fix" the Authorization problem, at least they can get it up and running, while all the request are made using Ajax, this may not be a problem.

[vzool]

The problem with having the token in the URL is that it will be logged (access_log, for example) ...

Sure it does, I suggest to notify the user about this when enabled this option.

"WARNING: Your Authentication token will be logged to access_log!!!"

invalidate the cache on the API when the token change, meaning the url change (something that might be seen as an unexpected behavior) ...

I guess if you add an extra random field with random value with every request, something like this:

https://example.com/api/?access_token=Token&t=<Time-In-Micro-Seconds>

Then, you will compete any cache mechanism.

[benhaynes]

OK, so I've added a bit more context to the "Deploying Versions" Docs page: https://github.com/directus/docs/commit/d38e260ce1f757db8f001cd3be55f648de5196fd

Also, the new README file for each directory has an intro paragraph that I think helps clarify our three main repos.

Directus is an open-source suite of software for managing content in projects of any size. Instances of the Directus API allow you to easily connect SQL database content anywhere (websites, native apps, wearables, IoT devices, kiosks, etc) while the Directus App allows non-technical users to intuitively manage that content. You can easily install a build of the full Directus Suite which includes the App, API, and all dependencies.

I''m going to close this one since I'm hoping the delineation is a bit clearer now... but I am happy to re-open if there are other suggestions to help new users understand the architecture.