• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved
    Feature Request
    4
    7
    682
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • george1421G
      george1421 Moderator
      last edited by

      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.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      1 Reply Last reply Reply Quote 1
      • S
        Sebastian Roth Moderator
        last edited by

        @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!

        Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

        Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

        Tom ElliottT 1 Reply Last reply Reply Quote 0
        • Tom ElliottT
          Tom Elliott @Sebastian Roth
          last edited by

          @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.

          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

          Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

          Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

          george1421G 1 Reply Last reply Reply Quote 0
          • george1421G
            george1421 Moderator @Tom Elliott
            last edited by

            @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.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

            1 Reply Last reply Reply Quote 1
            • S
              Sebastian Roth Moderator
              last edited by

              @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.

              Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

              Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

              george1421G 1 Reply Last reply Reply Quote 0
              • george1421G
                george1421 Moderator @Sebastian Roth
                last edited by

                @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.

                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                1 Reply Last reply Reply Quote 0
                • Wayne WorkmanW
                  Wayne Workman
                  last edited by 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.

                  Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
                  Daily Clean Installation Results:
                  https://fogtesting.fogproject.us/
                  FOG Reporting:
                  https://fog-external-reporting-results.fogproject.us/

                  1 Reply Last reply Reply Quote 0
                  • 1 / 1
                  • First post
                    Last post

                  249

                  Online

                  12.0k

                  Users

                  17.3k

                  Topics

                  155.2k

                  Posts
                  Copyright © 2012-2024 FOG Project