Feature request for FOG 1.6.x - Break out API engine from WebUI

[george1421]

This may be a bit further out there because it will take a lot of work but rewrite the API engine to be standalone. Well standalone in the since that you separate the API engine from the web gui. Then rewrite the web gui to use the api engine for imaging. This would give you the ability to strengthen the API engine as well as decouple the web gui from the actual imaging process. This would let you update the web gui without impacting imaging. FOG could then use a common web framework like laravel or others. This would pull the FOG Developers out of the web ui design and let them focus their time on the API and imaging. Also strenghening the API engine would also allow third party groups to build their own interfaces like in dotNet or whatever.

[Sebastian Roth]

@george1421 While the API is not completely separated from the web UI yet I think Tom has worked hard to separate things in 1.6.x. While I see your point of freeing developer time on the UI design I think it would be a huge thing to ask in 1.6.x already.Most of the UI for 1.6.x is ready to go and there is no need to redo all that now.

Surely a topic @Tom-Elliott needs to throw his thoughts in as well!

[Tom Elliott]

@Sebastian-Roth I have to agree. While you’re right that the UI could have a benefit from being separated, I am not too familiar with specifically separated API logic would work. If we force the UI to call the api, but the admin doesn’t install the API, the UI won’t work. So if we truly wanted to separate the logic, the UI should be explicitly on its own, and functioning.

Not sure how useful that would actually be.

With the way it is now, the UI code calls the api, so could be used as a self documenting method of our API system. Especially as we we work to use the api for most eveything.

I think it makes more sense to keep the api with the UI.

Otherwise, we end up needing to host 2 configurations. One for UI and one for API.

I think it makes it much more complicated. That said, I do think we should pull the html bits from the fogcore code and push for a proper “Templating” system. This would mean UI has a default we provide, but also expose the UI code so others could create their own templates. This will take a long time.

[george1421]

@Tom-Elliott Well I think we are all thinking along the same lines and FOG 1.6.x release may be a bit soon if ever.

I would say still isolating the API from the web ui is a good step. This will do a few things, like previously mentioned about using an official web framework, plus it will strengthen the API, since the web ui will HAVE to communicate with the API to get anything done. This will then force the API to be robust and complete (not implying that the API is deficient now). I see having 2 apache host configuration (web sites) is actually a good thing so we don’t need to do that API redirection stuff as well as moving the API to a non-http port will give us better control of what/who can access the API via firewall rules (if needed).

Separating the two maybe a more conceptual idea than a practical one in the end. But if we don’t at least discuss it, nothing will change.

[Sebastian Roth]

@george1421 What’s the benefit of moving the API to a new HTTP port (virtual host config)? People are using the API with external tools already and moving to a non standard port will break all that - not that they cannot change things but I just can’t see why. Sorry if this is a dumb question.

[george1421]

@Sebastian-Roth Well I really don’t know if its a problem or not, but by moving it to a different port you can then control (from an iptables standpoint) who can reach that api port. You can’t do that if its sitting on the main https port. Again I don’t know if its wanted or needed, but I see many web based applications servers do this then put a load balancer/reverse proxy in front of it. Also within apache then you can setup different directory permissions on the api than the web gui. Moving to a separate port is a lesser value point than separating the web gui from the API engine. Where the api engine become in its self its own web site if its on a different port.

[Wayne Workman]

The API and UI could be separated while still using the same port. The virtualhost config would look something like this:

<VirtualHost *:80>
        ServerName dev.localhost
        DocumentRoot /home/projects/smk/cms
        ErrorLog /var/log/apache2/smk-cms-error.log
</VirtualHost>

<VirtualHost *:80>
        ServerName my-project.localhost
        DocumentRoot /home/projects/smk/deploy
        ErrorLog /var/log/apache2/smk-deploy-error.log
</VirtualHost>

Reference:
https://stackoverflow.com/questions/6069892/different-virtualhosts-with-the-same-port

If this separation were done, I would think the installer could ask you if you want to install the API (defaulting to yes) and ask if you want to install the UI (defaulting to yes). This would allow the admin to break stuff apart.

I also think the database portion should be broken out, and the installer should ask if you want to install that or not (defaulting to yes).

There should be installation arguments for these things too.

Also, not wanting to delay 1.6 as noted by others. I would like to see this separation in a later release. As George has noted, if these things are separated it becomes easier to work on each one independently, meaning the learning curve to contribute is lower. Particularly with using popular frameworks.

Just my 2 cents.